Re: [patch net-next-2.6] net: comment rx_handler results

["Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>]

Le 05/03/2011 16:37, Jiri Pirko a écrit :
> Sat, Mar 05, 2011 at 04:27:52PM CET, nicolas.2p.debian@gmail.com wrote:
>> Le 05/03/2011 16:13, Jiri Pirko a écrit :
>>>
>>> Signed-off-by: Jiri Pirko<jpirko@redhat.com>
>>> ---
>>>   include/linux/netdevice.h |   12 ++++++++----
>>>   1 files changed, 8 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>>> index 48a9638..26e03f9 100644
>>> --- a/include/linux/netdevice.h
>>> +++ b/include/linux/netdevice.h
>>> @@ -391,10 +391,14 @@ enum gro_result {
>>>   typedef enum gro_result gro_result_t;
>>>
>>>   enum rx_handler_result {
>>> -	RX_HANDLER_CONSUMED,
>>> -	RX_HANDLER_ANOTHER,
>>> -	RX_HANDLER_EXACT,
>>> -	RX_HANDLER_PASS,
>>> +	RX_HANDLER_CONSUMED,	/* skb was consumed by rx_handler,
>>> +				   do not process it further. */
>>> +	RX_HANDLER_ANOTHER,	/* Do another round in receive path.
>>> +				   This is indicated in case skb->dev
>>> +				   was changed by rx_handler */
>>> +	RX_HANDLER_EXACT,	/* Force exact delivery, no wildcard */
>>> +	RX_HANDLER_PASS,	/* Do nothing, pass the skb as if
>>> +				   no rx_handler was called */
>>
>> Changing skb->dev should always cause another_round.
>
> Not if you reinject the skb.
>
>>
>> So, RX_HANDLER_ANOTHER could be removed and replaced with a test for
>> skb->dev change, with RX_HANDER_EXACT and RX_HANDLER_PASS.
>
> That was there before. Needs extra variable and I think this way, via
> results the code is much easier to read.
>
>>
>>> +	RX_HANDLER_CONSUMED,	/* skb was consumed by rx_handler,
>>> +				   do not process it further. */
>>> +	RX_HANDLER_EXACT,	/* Force exact delivery, no wildcard */
>>> +	RX_HANDLER_PASS,	/* Do normal (wildcard and exact) delivery */
>>
>> And any rx_handler returning RX_HANDLER_EXACT should cause exact
>> delivery, even if possible next rx_handlers return RX_HANDLER_PASS.
>
> When rx_handler returns RX_HANDLER_EXACT, there will bo no other call to
> any rx_handler (that is the case only when RX_HANDLER_ANOTHER is
> returned)

I agree, but we clearly need a kernel-doc that explain in more detail the expected behavior of every 
return values.

Some examples, showing some normal and some stacking setups, would help, I think. One more follow-up 
patch...

Reviewed-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>

	Nicolas.