>-----Original Message----- >From: David Miller [mailto:da...@davemloft.net] >Sent: Thursday, December 24, 2009 10:42 AM >To: krkum...@in.ibm.com >Cc: ying...@kernel.org; e1000-devel@lists.sourceforge.net; >net...@vger.kernel.org; netdev-ow...@vger.kernel.org; >avoront...@ru.mvista.com; Kumar Gopalpet-B05799; >ga...@kernel.crashing.org >Subject: gianfar select_queue bogosity (was Re: ixgbe warning) > >From: Krishna Kumar2 <krkum...@in.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 ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
