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 12:04:57 +0530
From:	Krishna Kumar2 <krkumar2@...ibm.com>
To:	"Kumar Gopalpet-B05799" <B05799@...escale.com>
Cc:	avorontsov@...mvista.com, "David Miller" <davem@...emloft.net>,
	e1000-devel@...ts.sourceforge.net, galak@...nel.crashing.org,
	netdev@...r.kernel.org, yinghai@...nel.org
Subject: RE: gianfar select_queue bogosity (was Re: ixgbe warning)

"Kumar Gopalpet-B05799" <B05799@...escale.com> wrote on 12/24/2009 11:34:23
AM:

>
> >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

Your requirement will be met if you remove select_queue handler.
dev_pick_tx() calls skb_tx_hash() and since rx is recorded, it
uses txq#=rxq# automatically. This also handles both locally
generated packets and forwarding/bridging - locally generated
packets will execute the optimized path (sk_tx_queue_recorded)
after the first time txq is selected.

Thanks,

- KK

--
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