netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [RFC PATCH 00/04]: VLAN vs. packet socket inconsistencies
Date: Wed, 09 Jul 2008 00:30:04 +0200	[thread overview]
Message-ID: <4873EA6C.40408@trash.net> (raw)
In-Reply-To: <20080708.151233.259338088.davem@davemloft.net>

David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Tue, 08 Jul 2008 12:14:51 +0200
>>
>> - packet socket auxdata is only available for non-mmaped sockets.
>>    For mmaped sockets the only place to store the data is in
>>    struct tpacket_hdr, but that would break compatibility. Not sure
>>    what to do about this case.
>>     
> The mmap socket limitation is pretty serious.  It's the only
> thing holding me back from just applying these patches right now.
>
> I think we should make a new version of the tpacket_hdr structure
> anyways, in order to make it more compat-friendly.  It currently
> has "unsigned long" members and other crap.
>
> We can design this thing to be extensible quite easily, by simply
> giving it an "offset" field.  My suggestion is:
>
> 1) sed 's/tpacket_hdr/tpacket_hdr_old/'
>
> 2) Create packet socket option PACKET_NEW_TPHDR which enables
>    use of a new tpacket_hdr layout.
>
> 3) Make new tpacket_hdr which has the VLAN tag stuff as well
>    as an 'offset' field so that we can add more stuff later
>    in a backwards compat way.
>
> 4) New new tpacket_hdr layout when PACKET_NEW_TPHDR has been
>    set.

That sounds good. Userspace needs to know about the size of
the tpacket_hdr before setting the ring parameters so it can
size the ring frames appropriately for the largest packet size
it wants to receive. This means the offset field in the
tpacket_hdr is redundant, so I'll just add a getsockopt
option for getting the size. Unless we want to be able to
include only a partial tpacket_hdr, but I don't think that
would be very useful.



  reply	other threads:[~2008-07-08 22:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-08 10:14 [RFC PATCH 00/04]: VLAN vs. packet socket inconsistencies Patrick McHardy
2008-07-08 10:15 ` [RFC PATCH 01/04]: vlan: Don't store VLAN tag in cb Patrick McHardy
2008-07-08 10:16 ` [RFC PATCH 02/04]: vlan: deliver packets received with VLAN acceleration to network taps Patrick McHardy
2008-07-08 10:16 ` [RFC PATCH 03/04]: packet: Store VLAN tag in auxillary data Patrick McHardy
2008-07-08 10:21   ` Patrick McHardy
2008-07-08 10:17 ` [RFC PATCH 04/04]: libpcap: reconstruct VLAN header from auxdata Patrick McHardy
2008-07-08 22:12 ` [RFC PATCH 00/04]: VLAN vs. packet socket inconsistencies David Miller
2008-07-08 22:30   ` Patrick McHardy [this message]
2008-07-08 22:35     ` David Miller
2008-07-08 22:38       ` David Miller
2008-07-08 22:48         ` Patrick McHardy

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=4873EA6C.40408@trash.net \
    --to=kaber@trash.net \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    /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).