lkml.org 
[lkml]   [2007]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it
David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon, 05 Nov 2007 19:00:19 +0100
>
>> This looks like a rather expensive operation for the unlikely case
>> that packets will be received by a packet socket. IMO it should only
>> be reconstructed if actually needed, by af_packet itself.
>
> Completely agreed. We should not do this by default when %99
> of the networking stack simply does not care about this.


I think there is one more case that matters, which is briding
from a device with VLAN stripping for a VLAN not configured
locally. The tag will be stripped and will be lost for forwarded
packets. But I'm not exactly sure this really can be configured
(time for bed so I'll check tommorrow).

>> As we discussed some time back storing the VLAN tag in the CB on
>> TX clashes with other users of the CB like qdiscs, so we need a
>> new field in the skb for this anyway.
>
> Someone will have to find a way to remove some other fields in
> sk_buff before I'm going to allow more space to be eaten up
> by this completely fringe case feature.


We have a two byte hole after tc_verd where we could fit this in.
But I'm pretty sure we also could reuse some other fields on input,
like queue_mapping or maybe even destructor for unowned skbs.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-11-06 01:23    [W:0.142 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site