Netmap ixgbe stripping Vlan tags

[Juli Mallett]

On Fri, Aug 23, 2013 at 12:02 AM, Andre Oppermann <andre at freebsd.org> wrote:

> On 23.08.2013 00:36, Harika Tandra wrote:
>
>> Hi all,
>>
>> 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.
>>
>> 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.
>>
>
> 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.
>

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.


> 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.
>

It also helps (slightly) reduce overhead in packet processing where you
just want to move data from card to host as fast as possible.


> 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.


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.  (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], 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.)

Thanks,
Juli.