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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 11 Jul 2012 09:53:44 +0200
From:	Jean-Michel Hautbois <jhautbois@...il.com>
To:	netdev <netdev@...r.kernel.org>
Subject: UDP ordering when using multiple rx queue

Hi list,

I am doing some experiments on several NICs and I have an issue with
my application.
This is a sending of raw data packets which consists of bursts each
1/30s of 784 times 4000 bytes UDP packets.
The packets are one a wired link, no switch or anything, so there is
no chance of reordering or drop between the sender and receiver.

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 :)).

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.

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 !) ?
- 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) ?

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.

Thanks !
JM
--
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

Powered by blists - more mailing lists