netdev - Re: UDP ordering when using multiple rx queue

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] [day] [month] [year] [list]

Date:	Wed, 11 Jul 2012 16:50:27 -0600
From:	Chris Friesen <chris.friesen@...band.com>
To:	Jean-Michel Hautbois <jhautbois@...il.com>
CC:	netdev <netdev@...r.kernel.org>
Subject: Re: UDP ordering when using multiple rx queue

On 07/11/2012 01:53 AM, Jean-Michel Hautbois wrote:
> On receiver side, I need to get the packets ordered, or the
> application will consider the packets are late (and then, lost).
> (Yes, the application is badly written on that specific part, but it
> is not mine :)).

Not the first such app I've seen.

> Several tests lead to a simple conclusion : when the NIC has only one
> RX queue, everything is ok (like be2net for instance), but when it has
> more than one RX queue, then I can have "lost packets".
> This is the case for bnx2x or mlx4 for instance.

This depends on the hardware.  The Intel NICs for example (and others, 
I'm just most familiar with them) support multiple queues but they do 
hardware hashing of "flows" such that a given flow will be routed to a 
specific queue and thus stay in order.

> Here are my questions :
> - Is it possible to force a driver to use only one rx queue, even if
> it can use more without reloading the driver (and this is feasible
> only when a parameter exists for that !) ?

This depends on the driver, but generally I would expect this to be a 
module parameter.

> - Is it possible to "force" the network stack to give the packets on
> the correct order (I would say no, as this is not specified in the
> protocol) ?

No, it's up to the hardware/driver.


> My only bet is the first one (forcing one rx queue).
> The last and desperate solution would be rewriting the application,
> not easy to make it accepted.

Depending on the hardware/driver you may be able to enable flow hashing.

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