[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110523140048.777fb378@nehalam>
Date: Mon, 23 May 2011 14:00:48 -0700
From: Stephen Hemminger <shemminger@...ux-foundation.org>
To: Ben Greear <greearb@...delatech.com>
Cc: Nicolas de Pesloüan <nicolas.2p.debian@...il.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
David Miller <davem@...emloft.net>,
Jiri Pirko <jpirko@...hat.com>,
Changli Gao <xiaosuo@...il.com>, netdev@...r.kernel.org,
kaber@...sh.net, fubar@...ibm.com, eric.dumazet@...il.com,
andy@...yhouse.net, Jesse Gross <jesse@...ira.com>
Subject: Re: [PATCH 1/3] vlan: Do not support clearing VLAN_FLAG_REORDER_HDR
> Well, yes..unless perhaps when the REORDER_HDR flag is enabled.
>
> As for when the tag is added/removed, as long as we don't end up doing
> a remove and then an add (in software), and as long as the pkt is correct
> going to user-space, it doesn't matter to me.
>
> It would be lame to remove it in software and then re-add it,
> unless absolutely required for some reason.
IMHO the REORDER_HDR flag was a design mistake. It means supporting
two different API's for the application. For a packet capture application
it means the format of the packet will be different based on how
the VLAN was created. And the vlan was created outside the application.
If there was a requirement to support both formats, then it should
be a property of the AF_PACKET socket. The application can then do
an setsockopt() to control the format of the data. The issue is
for things like mmap/AF_PACKET the re-inserted form will be slower
since data has to be copied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists