From owner-freebsd-net@FreeBSD.ORG Fri Aug 23 13:13:05 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F0ACD904; Fri, 23 Aug 2013 13:13:04 +0000 (UTC) (envelope-from htandra@gloriad.org) Received: from mail.gloriad.org (mail.gloriad.org [160.36.208.244]) by mx1.freebsd.org (Postfix) with ESMTP id C2D81265C; Fri, 23 Aug 2013 13:13:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.gloriad.org (Postfix) with ESMTP id A6B9A17883E3; Fri, 23 Aug 2013 09:13:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.gloriad.org Received: from mail.gloriad.org ([127.0.0.1]) by localhost (mail.gloriad.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_bAcxBUi_wU; Fri, 23 Aug 2013 09:13:03 -0400 (EDT) Received: from harikadev.gloriad.utk.edu (harikadev.gloriad.utk.edu [160.36.208.154]) by mail.gloriad.org (Postfix) with ESMTPSA id 7AC0C17883D4; Fri, 23 Aug 2013 09:13:03 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9506DFFD-AF06-4AE3-A95F-CEA786AA254E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Netmap ixgbe stripping Vlan tags From: Harika Tandra In-Reply-To: <5217494C.6060302@freebsd.org> Date: Fri, 23 Aug 2013 09:12:57 -0400 Message-Id: References: <521708E8.4000105@freebsd.org> <5217494C.6060302@freebsd.org> To: "freebsd-net@freebsd.org" X-Mailer: Apple Mail (2.1508) Cc: Juli Mallett , Andre Oppermann X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Aug 2013 13:13:05 -0000 --Apple-Mail=_9506DFFD-AF06-4AE3-A95F-CEA786AA254E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I agree with Andre's statement=20 > A netmap consumer > typically doesn't expect packets be mangled at all, mostly likely = netmap is > expressly used to get the packet exactly as they were seen on the = wire. For my application I want to see the whole packet as is (as seen on the = wire).=20 I am sure it is important for many users who are interested in=20 using netmap for speedup of packet capture in network = security/monitoring applications. When I disable "vlanhwfilter" flag on the interface. It is behaving as = expected and is=20 not stripping the Vlan tags when placed in promiscuous mode. Netmap = seems to be ignoring=20 his setting or is resetting this option someplace (??). Any suggestion = on where in Netmap=20 code this maybe ? Thanks for all your help. Thanks, Harika. On Aug 23, 2013, at 7:36 AM, Andre Oppermann wrote: > On 23.08.2013 09:13, Juli Mallett wrote: >> On Fri, Aug 23, 2013 at 12:02 AM, Andre Oppermann > wrote: >>=20 >> On 23.08.2013 00:36, Harika Tandra wrote: >>=20 >> Hi all, >>=20 >> I am running Netmap with "intel 10G 82598EB" card in = promiscuous mode. >> While capturing packets via Netmap the driver is stripping off = Vlan tags. >> I tested my setup, I am able to see Vlan tags when the same = card is in promiscuous >> mode without Netmap. >>=20 >> This maybe due to the netmap related changes to the device = driver code. >> But I don't know much about drivers. I would appreciate any = help or pointer >> regarding this. >>=20 >>=20 >> This is standard behavior in FreeBSD drivers where the vlan header = is removed >> and the vlan tag is placed in an mbuf field. Together with netmap = it doesn't >> make sense of course and the driver should disable it when = switching to netmap >> mode. >>=20 >>=20 >> I think this runs counter to the netmap ethos some (as I understand = it.) In the same way that >> netmap doesn't enable promiscuous mode since you may be doing = non-promiscuous processing with >> netmap, it also should leave whether VLAN_HWFILTER (or whatever) is = enabled up to the program or the >> user in question. It would be nice if it could do the state = management for these things (to ensure >> the interface goes back to its original state if the program = crashes), but as yet it can't. There >> are lots of passive capture applications where you might not care = about having the VLAN tags intact >> and so would prefer to have them stripped. If there's a bug here, = it's that packet metadata is lost >> going into netmap entirely, not that the VLAN tags aren't in the = frame. >=20 > I don't think vlan tag removal and promiscuous mode are comparable. = The former > mangles the packet whereas the latter determines which packets are = deliverd in > the first place. Running netmap w/o promiscuous mode makes a lot of = sense when > you only want to receive packets destined for this host. A netmap = consumer > typically doesn't expect packets be mangled at all, mostly likely = netmap is > expressly used to get the packet exactly as they were seen on the = wire. >=20 >> The general usefulness of hardware vlan tag stripping/insertion is = debatable as >> it doesn't gain much, if anything, and was intended for an = entirely different >> purpose, namely to help the windows kernel over its total lack of = vlan awareness. >>=20 >>=20 >> It also helps (slightly) reduce overhead in packet processing where = you just want to move data from >> card to host as fast as possible. >=20 > There isn't much of a difference really. Whether you do m_adj(m, -14) = or m_adj(m, -18) > is the same. Parsing the tag out of the header is about the same as = putting it in and > reading it from the mbuf pkthdr. The main overhead of passing it to = the per-vlan ifnet > is the same. On the way out the same applies. Prepending 14 vs. 18 = bytes for the > ethernet header isn't more overhead than what each driver has to do to = for the vlan > insertion descriptor setup. >=20 >> It can be argued that in FreeBSD hardware vlan tag insert/removal = is an unnecessary >> misfeature and only complicates things. Especially in the context = of multi-vlan >> stacking. Doing it in software would be in fact just as fast = remove a bit of code >> from the drivers. >>=20 >> Are you sure? While that may hold up for ixgbe (though I'd say it = doesn't, at least without packets >> going straight into cache so there's no penalty for accessing parts = of the packet you don't care >> about, again looking at the netmap case really) it doesn't hold up = for low-powered network >> processors with very fast offload engines. >=20 > The stack has to look at the ethernet header anyway to determine what = kind of > packet it is. The 4 additional bytes of vlan tag are in the same = cache line. > In the low-powered network processors with fast packet engines you try = not to > touch the packet on the CPU at all. Even things like NAT are done in = the engine. > So you are limited to the capabilities of the hardware to retain full = speed. >=20 > > (NB: I'd rather see it gone; I think it's an annoying >> complication when writing network drivers [which have way too many = fiddly bits; I was bound to >> dislike some aspect of 'tools not policy' eventually, I guess], >=20 > Fully agreed here. It only complicates things for no real benefit. = The way our > stack works makes it totally unnecessary actually. >=20 > > or if it stays I'd rather see it be >> a mandatory option on hardware where there's no penalty for using it. = Some hardware's performance >> falls off spectacularly with this kind of offloading enabled, losing = whatever gains stripping >> unnecessary data provided.) >=20 > Having two path's makes things only more complicated. While some NICs = support > QinQ stacking nowadays it makes integration into the stack yet more = complex. > I'd rather have it removed and do the magic in ether_input() at once = and same > for all. Much less chance for bugs or surprising differences in = behavior. > Also allows for arbitrary deep QinQ stacking as has become all the = rage in > metro ethernet. >=20 > --=20 > Andre >=20 --Apple-Mail=_9506DFFD-AF06-4AE3-A95F-CEA786AA254E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJSF1/ZAAoJEOFgjpnyJx85E/MH/24Vp/aQG8pAkqnnX6aRsrIf tMYXoq28VPQs6jPmxIEet5eQWG6rO7gEAJvJa0h0euqlvnrhmjAZPrighCOJBn6o 1uuBXTclxOQyrfCH+6Pdvt62B93iKtFeS5BhVpV/F2d0C5Rdg5nhIcUG7oa79Njj cNvtdqZ3eQPSnIOie6HQZ5HjTvrYOAB1XMAHCKjKCuS6NILJ37REWDoJF6vqxTYJ mHpgoom8osBoMh2LK+FxBEqd9jwIvpEAIkZUdZlCZmAWyCeJwE13ZYuInX8X7SdF T0md7wtA/qC1/gvVENH+D35xnCcY/uTCnhkyTdw7VU9SgTydG7e/ym9g/lAVXKo= =03E5 -----END PGP SIGNATURE----- --Apple-Mail=_9506DFFD-AF06-4AE3-A95F-CEA786AA254E--