All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: "Michał Mirosław" <mirqus@gmail.com>, "Jiri Pirko" <jpirko@redhat.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>,
	netdev@vger.kernel.org, davem@davemloft.net, kaber@trash.net,
	fubar@us.ibm.com, eric.dumazet@gmail.com, andy@greyhouse.net
Subject: Re: [RFC patch net-next-2.6] net: allow multiple rx_handler registration
Date: Fri, 01 Jul 2011 18:45:58 +0200	[thread overview]
Message-ID: <4E0DF9C6.703@gmail.com> (raw)
In-Reply-To: <BANLkTi=j03qATuV+a9OHnjcGsK6kB4zo6Q@mail.gmail.com>

Le 01/07/2011 17:01, Michał Mirosław a écrit :

>>> We could introduce a catch-all macvlan/vlan device that would take
>>> addresses/VLANs which are not covered by other configured
>>> macvlans/vlans. This would allow clearer configuration and would make
>>> the evaluation order explicit. As a bonus, this will give another
>>> device to put tcpdump on. ;-)
>>
>> 'Sounds like what I had in mind in
>> http://marc.info/?l=linux-netdev&m=130622112921245&w=2 .
>
> Almost. My idea assumes that eth0.any won't strip VLAN headers (so its
> just looks like a filtered eth0).

I originally thought unstripped packets should go to eth0.

But, if eth0.any get untagged packets, we face two problems:

1/ We need a way to retrieve the original tag.
2/ We need a way to force the tag on output (or we consider eth0.any a pure tcpdump device, which is 
less useful).

But if eth0.any get the exact same packets as those delivered to eth0, this seems useless.

Or maybe, eth0.any should get only packets that weren't delivered to any eth0.XXXX devices... and 
should be named eth0.unmatched instead of eth0.any :-)

Do we need eth0.untagged too (which would only get packets that were originally *not* tagged)?

eth0 - Get everything, untouched. (I know several people except tagged packets to be untagged here, 
but I disagree with this part. eth0 is the raw device and should deliver raw packets, possibly 
retagging packets that were untagged by hw-accel).
eth0.100 - Get VLAN 100 packet, untagged.
eth0.untagged - Get only non-tagged packets, untouched.
eth0.unmatched - Get only tagged packets, untouched.

	Nicolas.

  reply	other threads:[~2011-07-01 16:46 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-30 15:16 [RFC patch net-next-2.6] net: allow multiple rx_handler registration Jiri Pirko
2011-06-30 16:27 ` Stephen Hemminger
2011-06-30 17:22   ` Jiri Pirko
2011-06-30 17:29     ` Ben Greear
2011-06-30 17:32       ` Jiri Pirko
2011-07-01  6:36     ` Michał Mirosław
2011-07-01 14:57       ` Nicolas de Pesloüan
2011-07-01 15:00         ` Jiri Pirko
2011-07-01 15:01         ` Michał Mirosław
2011-07-01 16:45           ` Nicolas de Pesloüan [this message]
2011-07-01 16:49             ` Ben Greear
2011-07-01 16:58               ` Nicolas de Pesloüan
2011-07-01 17:08                 ` David Lamparter
2011-07-01 17:50             ` Michał Mirosław
2011-06-30 18:13 ` Ben Greear
2011-06-30 18:28   ` Jiri Pirko
2011-06-30 18:53     ` Ben Greear
2011-06-30 19:50 ` Nicolas de Pesloüan
2011-07-01  5:45   ` Jiri Pirko
2011-07-01 16:55     ` David Lamparter
2011-07-01 12:48 ` Jiri Pirko

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=4E0DF9C6.703@gmail.com \
    --to=nicolas.2p.debian@gmail.com \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=fubar@us.ibm.com \
    --cc=jpirko@redhat.com \
    --cc=kaber@trash.net \
    --cc=mirqus@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.