Subject: Re: [PATCH 1/3] vlan: Do not support clearing VLAN_FLAG_REORDER_HDR

From: [email-masked] (Eric W. Biederman)
Date: Tue, 24 May 2011 00:56:08 -0700

David Miller <[email-masked]> writes:

> From: [email-masked] (Eric W. Biederman)
> Date: Mon, 23 May 2011 15:05:54 -0700
>
>> 3) What do we do with pf_packet and vlan hardware acceleration when
>>    dumping not the vlan interface but the interface below the vlan
>>    interface?
>> 
>>    Do we provide an option to keep the vlan header?  Should that option
>>    be on by default?
>> 
>
> The vlan_tci in the V2 pf_packet auxdata was intended for this
> purpose.
>
> So no matter what variant of behavior is occurring, apps can properly
> reconstitute the VLAN header if they inspect the vlan_tci in the
> auxdata.

It sucks a little bit to deal with that but that is fair.

> The only thing that seems to be missing is an indication that a VLAN
> tag was present at all, ie. vlan_tx_tag_present(), in this manner an
> application could then differentiate between no VLAN header and a VLAN
> tag of zero.

Good point.

I had seen that we were putting the data there but I missed the fact
that we deleted the indicator.  That makes packets not destined for a
vlan but that just have priority bits set hard to detect.  Especially
if the priority bits are 0.

Would it cause many problems if we added used tp_status to hold a flag
indicating the presence of a vlan header?

We also have an issue that the socket filter doesn't have access to any
of the vlan information at present.

Eric