netdev - RE: gianfar select_queue bogosity (was Re: ixgbe warning)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Dec 2009 11:34:23 +0530
From:	"Kumar Gopalpet-B05799" <B05799@...escale.com>
To:	"David Miller" <davem@...emloft.net>, <krkumar2@...ibm.com>
Cc:	<yinghai@...nel.org>, <e1000-devel@...ts.sourceforge.net>,
	<netdev@...r.kernel.org>, <netdev-owner@...r.kernel.org>,
	<avorontsov@...mvista.com>, <galak@...nel.crashing.org>
Subject: RE: gianfar select_queue bogosity (was Re: ixgbe warning)

 

>-----Original Message-----
>From: David Miller [mailto:davem@...emloft.net] 
>Sent: Thursday, December 24, 2009 10:42 AM
>To: krkumar2@...ibm.com
>Cc: yinghai@...nel.org; e1000-devel@...ts.sourceforge.net; 
>netdev@...r.kernel.org; netdev-owner@...r.kernel.org; 
>avorontsov@...mvista.com; Kumar Gopalpet-B05799; 
>galak@...nel.crashing.org
>Subject: gianfar select_queue bogosity (was Re: ixgbe warning)
>
>From: Krishna Kumar2 <krkumar2@...ibm.com>
>Date: Wed, 23 Dec 2009 12:57:26 +0530
>
>> Also, I was looking at other providers of select_queue and found:
>> 
>> u16 gfar_select_queue(struct net_device *dev, struct sk_buff *skb) {
>>         return skb_get_queue_mapping(skb); }
>> 
>> How can this be correct (driver supports upto 8 txq's). Unless txq=0 
>> for xmits of all locally generated packets is fine.
>
>This must be fixed.  As you note the queue mapping is only set 
>for forwarding/bridging cases.
>

Yes, the queue_mapping is set for forwarding/bridginh applications.

>There is zero reason for this driver to have it's own 
>select_queue function, so the fix seems to simply remove this 
>thing altogether.
>
What if I want to maintaing a 1-1 mapping b/w the Rx/Tx queues.
For eg., I want a packet received on queue-1 on eth0 to be forwarded on
to queue-1 on eth1.

Is there some way where we can handle both kinds of applications i.e.,
forwarding/bridging and
locally  generated packets.

>Some gianfar developer please prepare such a patch, thanks.

If you want gfar_select_queue( ) function to be removed for now, I will
do that.
But, I would also want to maintain the above explained scenario to be
handled for forwarding/bridging applications.

Please provide your inputs

--

Thanks
Sandeep
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html