David Miller wrote:
quoted text
> No, that is crap.  I didn't create the ->select_tx_queue() callback so
> that each and every damn multiqueue driver will override the generic
> TX hash function in order to try and make the TX hashing match the RX
> hashing.
>
> That's not what it's for.
>
> The callback exists for things like wireless where the queues have
> a meaning other than flow seperation.
>
> We (specifically Herbert Xu and myself) know that for routing and
> firewalling applications matching the TX queue to the same hashing
> namespace of the RX multiqueueing is desirable for best performance.
>
> But we will do that generically by allowing the driver on the receive
> side to record the RX hash used (or alternatively, if the exact RSS
> hash isn't obtainable, the RX queue index itself) and on TX we will
> use this information to select the TX queue properly.
>   

Ok, I'll resend without the select_queue stuff. But you should really
document the above explanation. The only documentation we found was
"Devices or device layers can set this to control the queue selection
performed by dev_pick_tx()." in the git-log...

Brice

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/