From: Patrick McHardy <kaber@trash.net>
To: David Miller <davem@davemloft.net>
Cc: djohnson+linux-kernel@sw.starentnetworks.com,
jes@trained-monkey.org, mchan@broadcom.com,
ram.vepa@neterion.com, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, bguo@sw.starentnetworks.com
Subject: Re: [PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it
Date: Tue, 06 Nov 2007 01:21:09 +0100 [thread overview]
Message-ID: <472FB375.1020802@trash.net> (raw)
In-Reply-To: <20071105.151544.175839612.davem@davemloft.net>
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.
next prev parent reply other threads:[~2007-11-06 0:21 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-31 18:43 expected behavior of PF_PACKET on NETIF_F_HW_VLAN_RX device? Dave Johnson
2007-10-31 19:33 ` Stephen Hemminger
2007-11-01 1:06 ` Ben Greear
2007-11-01 1:10 ` David Miller
2007-11-01 1:23 ` Stephen Hemminger
2007-11-01 1:31 ` Ben Greear
2007-11-01 4:50 ` David Miller
2007-11-01 15:04 ` Ben Greear
2007-11-01 21:35 ` David Miller
2007-11-01 21:36 ` Dave Johnson
2007-11-01 21:48 ` Rick Jones
2007-11-01 21:59 ` David Miller
2007-11-01 22:04 ` Rick Jones
2007-11-01 22:07 ` David Miller
2007-11-01 23:26 ` Rick Jones
2007-11-05 17:46 ` [PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it Dave Johnson
2007-11-05 18:00 ` Patrick McHardy
2007-11-05 23:15 ` David Miller
2007-11-06 0:21 ` Patrick McHardy [this message]
2007-11-06 0:35 ` David Miller
2007-11-06 18:03 ` Krzysztof Halasa
2007-11-06 18:56 ` Ben Greear
2007-11-06 20:08 ` Krzysztof Halasa
2007-11-06 23:55 ` Patrick McHardy
2007-11-05 17:47 ` [PATCH 2/2] " Dave Johnson
2007-11-06 2:39 ` Ramkrishna Vepa
2007-11-06 18:28 ` Ramkrishna Vepa
2007-11-06 18:34 ` Dave Johnson
2007-11-01 21:58 ` expected behavior of PF_PACKET on NETIF_F_HW_VLAN_RX device? David Miller
2007-11-02 18:08 ` Dave Johnson
2007-11-02 21:20 ` David Miller
2007-11-02 21:52 ` Michael Chan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=472FB375.1020802@trash.net \
--to=kaber@trash.net \
--cc=bguo@sw.starentnetworks.com \
--cc=davem@davemloft.net \
--cc=djohnson+linux-kernel@sw.starentnetworks.com \
--cc=jes@trained-monkey.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=ram.vepa@neterion.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).