From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: atl1 warn_on_slowpath help Date: Wed, 29 Oct 2008 14:09:08 +0100 Message-ID: <49086074.3080208@trash.net> References: <20081029071549.GA4861@ff.dom.local> <49081AE4.9040301@trash.net> <49083825.3000601@trash.net> <20081029130313.GA7256@ff.dom.local> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Jay Cliburn , netdev@vger.kernel.org To: Jarek Poplawski Return-path: Received: from stinky.trash.net ([213.144.137.162]:65530 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753062AbYJ2NJL (ORCPT ); Wed, 29 Oct 2008 09:09:11 -0400 In-Reply-To: <20081029130313.GA7256@ff.dom.local> Sender: netdev-owner@vger.kernel.org List-ID: 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.