From owner-freebsd-net@FreeBSD.ORG Fri Jan 2 18:46:45 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34557325 for ; Fri, 2 Jan 2015 18:46:45 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0000B1DED for ; Fri, 2 Jan 2015 18:46:44 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kq14so24132513pab.26 for ; Fri, 02 Jan 2015 10:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=Silk36QcxSx0j/twMK8Upjmt/s1Wd1ABKZJdlhxAg8E=; b=xvgG4WC7pnclWZKrHhw0h0qMRZz+RazlyALNYqJyQi9Gkn6O6y0krApiHfOsh0mQcj /MV8APc19ozlv89WDTHsB6TtBsMvQIxkxAFfl9Zb0YSZ4U0qpZIIbPx1PYLk6L4MLlxk MDkOvVpIsyLLmv+rRac6ZGGlR5I00VXUV8EOziZvHrIyvyJECC2G9FioCVEAJuQ/FIh+ G7v3A1DeMpJ0Q3DsYgk9bXGezACu/vwyPRC8CuoRB+44Pcg/sbHcgCMgdVBqo35Wn73c JNBvNc1Ah58qA5Y/FTCdhv+5uiuChc+iVE0GvFE7XI8j9Uiskh3NtIiykQ56hjnR1wy1 Cg4Q== X-Received: by 10.66.117.199 with SMTP id kg7mr85609792pab.92.1420224404458; Fri, 02 Jan 2015 10:46:44 -0800 (PST) Received: from ox ([24.6.44.228]) by mx.google.com with ESMTPSA id ig1sm47198495pbc.41.2015.01.02.10.46.42 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 02 Jan 2015 10:46:43 -0800 (PST) Sender: Navdeep Parhar Date: Fri, 2 Jan 2015 10:46:40 -0800 From: Navdeep Parhar To: "Alexander V. Chernikov" Subject: Re: cxgbe and netmap Message-ID: <20150102184640.GB28813@ox> Mail-Followup-To: "Alexander V. Chernikov" , "freebsd-net@freebsd.org" References: <54A6BFFE.5080103@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54A6BFFE.5080103@yandex-team.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-net@freebsd.org" 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: Fri, 02 Jan 2015 18:46:45 -0000 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 driver's netmap support in whatever direction the users want it to go. Regards, Navdeep