Re: atl1 warn_on_slowpath help

[Patrick McHardy <kaber@trash.net>]

Jarek Poplawski wrote:
> On Wed, Oct 29, 2008 at 11:17:09AM +0100, Patrick McHardy wrote:
>> The __vlan_hwaccel_rx function only does the device lookup and
>> stores it in the cb. The remaining processing is done in a new
>> function that is invoked by netif_receive_skb(), in the proper
>> context. Unfortunatly this needs vlan-specific handling in
>> netif_receive_skb().
>>
> 
> Unfortunately I'm not up-to-date with vlans and especially this
> nit_deliver problem, but here is a little doubt: since this is
> probably for stable, and skb->cb is rather tricky, I wonder why
> vlan_group_get_device() couldn't be used directly in
> vlan_hwaccel_do_receive()?

Because it needs the VLAN group, and that has to be passed
around somehow (=> skb->cb). So we might as well look up the
device immediately.

Its trivial to verify that the use of skb->cb is fine, the
only codepath besides the one leading to vlan_hwaccel_do_receive
immediately is through netif_rx.

> BTW: if we call netif_nit_deliver() from vlan_hwaccel_do_receive()
> from netif_receive_skb() this comment about bypassing looks a bit
> confusing to me:
> 
> /*
>  *     netif_nit_deliver - deliver received packets to network taps
>  *     @skb: buffer
>  *
>  *     This function is used to deliver incoming packets to network
>  *     taps. It should be used when the normal netif_receive_skb path
>  *     is bypassed, for example because of VLAN acceleration.
>  */

Agreed, this could be improved.

> As a matter of fact without this patch it's not so apparent why
> netif_receive_skb() can't happen after netif_nit_deliver() in
> __vlan_hwaccel_rx() too.

I don't understand what you're saying.