From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: Jiri Pirko <jpirko@redhat.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Stephen Hemminger <shemminger@vyatta.com>,
Jay Vosburgh <fubar@us.ibm.com>,
Patrick Mc Hardy <kaber@trash.net>,
Eric Dumazet <eric.dumazet@gmail.com>,
Andy Gospodarek <andy@greyhouse.net>
Subject: Re: Possible regression in __netif_receive_skb() between 2.6.38-rc7 and net-next-2.6
Date: Sun, 06 Mar 2011 14:08:33 +0100 [thread overview]
Message-ID: <4D738751.6050209@gmail.com> (raw)
In-Reply-To: <20110305220938.GK8573@psychotron.redhat.com>
Le 05/03/2011 23:09, Jiri Pirko a écrit :
> Sat, Mar 05, 2011 at 10:30:33PM CET, nicolas.2p.debian@gmail.com wrote:
>> Hi,
>>
>> Comparing __netif_receive_skb() between 2.6.38-rc7 and net-next-2.6,
>> I noticed an important difference: The ptype_base loop used to
>> deliver to orig_dev and this is not true anymore.
>
> I believe this is adressed by submitted patch " net: allow handlers to
> be processed for orig_dev"
I wonder whether we should address it that way (which is the former way to address it).
There are still a difference between ptype_all and ptype_base delivery:
- For ptype_all, we deliver to every device crossed while walking the rx_handler path (inside the
another_round loop). (And there is no way to force exact match delivery).
- For ptype_base, we deliver to the lowest device (orig_dev) and to the highest (skb->dev) and we
can ask for exact match delivery.
This sounds very inconsistent. The only difference between ptype_all and ptype_base is the fact that
ptype->type is NULL (wildcard) for the first and not NULL (a particular protocol) for the second.
I think we should:
1/ deliver to both ptype_all and ptype_base while walking the rx_handler path, but only exact match
(ptype->dev == skb->dev).
2/ deliver to both ptype_all and ptype_base at the end of __netif_receive_skb(), but only wildcard
match (ptype->dev == NULL), skipping this part if the last rx_handler returned RX_HANDLER_EXACT.
Nicolas.
>> Imagine the following simple setup:
>>
>> eth0 -> bond0
>>
>> - A packet handler registered on eth0, with ptype->type == NULL will
>> receive the packet, because it will be delivered in the ptype_all
>> loop, which is inside the another_round loop.
>> - The same packet handler, registered on eth0, but with ptype->type
>> != NULL won't receive the packet, because the ptype_base loop doesn't
>> deliver to orig_dev anymore.
>>
>> I think this can lead to a regression for user space: an application
>> using af_packet to listen to eth0 will receive the packet flow if the
>> registered protocol is NULL, but won't receive anything if the
>> registered protocol is not NULL.
>>
>> Can someone confirm?
>>
>> Nicolas.
>
next prev parent reply other threads:[~2011-03-06 13:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-05 21:30 Possible regression in __netif_receive_skb() between 2.6.38-rc7 and net-next-2.6 Nicolas de Pesloüan
2011-03-05 22:09 ` Jiri Pirko
2011-03-06 13:08 ` Nicolas de Pesloüan [this message]
2011-03-06 13:25 ` [PATCH net-next-2.6] net: harmonize the call to ptype_all and ptype_base handlers Nicolas de Pesloüan
2011-03-07 10:03 ` Jiri Pirko
2011-03-07 20:41 ` Nicolas de Pesloüan
2011-03-07 21:12 ` 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=4D738751.6050209@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=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.