Date: Fri, 23 Aug 2013 09:12:57 -0400 From: Harika Tandra <htandra@gloriad.org> To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Cc: Juli Mallett <jmallett@FreeBSD.org>, Andre Oppermann <andre@freebsd.org> Subject: Re: Netmap ixgbe stripping Vlan tags Message-ID: <EDB2CF64-2241-486E-8B10-F8977EF88048@gloriad.org> In-Reply-To: <5217494C.6060302@freebsd.org> References: <FC9BCAD9-5D16-4E70-A9C5-FA9D9A22B84C@gloriad.org> <521708E8.4000105@freebsd.org> <CACVs6=_Er_rmOcKz2UdT-98JPZktmE7q4smZUOhA9Fn-z%2B8yCw@mail.gmail.com> <5217494C.6060302@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <andre@freebsd.org> wrote: > On 23.08.2013 09:13, Juli Mallett wrote: >> On Fri, Aug 23, 2013 at 12:02 AM, Andre Oppermann <andre@freebsd.org = <mailto:andre@freebsd.org>> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EDB2CF64-2241-486E-8B10-F8977EF88048>