From owner-freebsd-net@FreeBSD.ORG Sat Jan 3 12:24:31 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02A0DE20 for ; Sat, 3 Jan 2015 12:24:31 +0000 (UTC) Received: from forward-corp1f.mail.yandex.net (forward-corp1f.mail.yandex.net [95.108.130.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0FCE64CCF for ; Sat, 3 Jan 2015 12:24:30 +0000 (UTC) Received: from smtpcorp1m.mail.yandex.net (smtpcorp1m.mail.yandex.net [77.88.61.150]) by forward-corp1f.mail.yandex.net (Yandex) with ESMTP id 62B3D24202D4 for ; Sat, 3 Jan 2015 15:24:26 +0300 (MSK) Received: from smtpcorp1m.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp1m.mail.yandex.net (Yandex) with ESMTP id 1DB392CA0302 for ; Sat, 3 Jan 2015 15:24:26 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:401:222:4dff:fe50:cd2f]) by smtpcorp1m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id WgZbGMMq1k-OQlSEC5v; Sat, 3 Jan 2015 15:24:26 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1420287866; bh=BxXcP37dS0PGdTeu2fvVnF6bnwDi0WgE3fgkA0Ig5OM=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=udTt7OmURyvkgzbOumFACVm1FI4cuurjmNFgPPOfv2+UOuCIvG9FkXj3/oixx6bB6 sIgjzbA5rA2w1efPiWcUFzkJdpf/aV7TjSPv+mZLDvThh8MOWvVmrHYcXe4oYF/AP8 djwMP2sioTQlaxbJjoFgw4OpvMw/knu0G2U5NTq8= Authentication-Results: smtpcorp1m.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <54A7DF3C.7090905@yandex-team.ru> Date: Sat, 03 Jan 2015 15:23:24 +0300 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: Re: cxgbe and netmap References: <54A6BFFE.5080103@yandex-team.ru> <20150102184640.GB28813@ox> In-Reply-To: <20150102184640.GB28813@ox> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 12:24:31 -0000 On 02.01.2015 21:46, Navdeep Parhar wrote: > On Fri, Jan 02, 2015 at 06:57:50PM +0300, Alexander V. Chernikov wrote: >> Hello list! >> >> FreeBSD has netmap support for chelsio T5 cards, which is amazing. >> The great thing about implementation is that you can play with >> traffic-generating applications without affecting "main" OS interface, >> which has always been a problem for Intel cards. >> However, this approach (having additional netmap-only ifp) turns to be a >> bit problematic for netmap-based networking elements participating in >> routing. >> >> In Intel case you can configure all your interfaces, run routing daemon, >> run netmap application and punt all to-host traffic to kernel via host >> pipes. >> It looks like I can't do this using current implementation: mac >> addresses are different for main/netmap interfaces so I can't run >> routing daemon on main interface (or sub-interfaces). >> I also can't run routing daemon on top of ncxgbe* interface since it >> appears to ignore non-netmap-derived traffic.. >> >> Is it possible to make ncxgbe* interfaces behave more like ordinary ones? >> > Yes, I need to write a simple transmit and receive handler for the > non-netmap traffic on the ncxgbe/ncxl interfaces. This is a bit > complicated because the normal rx runs in a mode where 1 rx buffer does > not always equal 1 rx frame. > > Now that netmap is in GENERIC, it may be best to carve out a separate > cxgbe_netmap module that can be loaded by those who want to use netmap > on top of cxgbe/cxl hardware. So no more magic 'n' interfaces by > default (some people were caught by surprise at the sudden appearance of > the 'n' interfaces on HEAD), and fully functional 'n' interfaces as soon > as you load the additional module. > > What do you and other netmap users think? I'm open to taking this Having loadable netmap support would be great - this approach looks much more flexible. > driver's netmap support in whatever direction the users want it to go. > > Regards, > Navdeep