<div dir="ltr">>RSS should be implemented in hardware. So it shouldn't be causing added<br>>latency. What device are you using.



<div>My error; aggregate performance is the same. H/W RSS is fine.<br><br>>Packet direction to queue in HW is done with rte_flow (if your NIC supports it)<br>><a href="https://doc.dpdk.org/guides/prog_guide/rte_flow.html" rel="noreferrer" target="_blank">https://doc.dpdk.org/guides/prog_guide/rte_flow.html</a><br>Thank you! That was not on my radar for some reason. Much appreciated.<br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 18, 2022 at 5:14 PM Stephen Hemminger <<a href="mailto:stephen@networkplumber.org">stephen@networkplumber.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 18 Dec 2022 16:41:13 -0500<br>
fwefew 4t4tg <<a href="mailto:7532yahoo@gmail.com" target="_blank">7532yahoo@gmail.com</a>> wrote:<br>
<br>
> I am aware of RSS; I coded it and have gotten it to work between machines.<br>
> <br>
> However, the elapsed time per packet increases from <100ns/packet RSS-OFF<br>
> to 700-800ns RSS-ON in my test setup.<br>
> <br>
> In my scenario I have hardcoded routing between TXQs on client machines and<br>
> RXQs on the server machines.<br>
<br>
Packet direction to queue in HW is done with rte_flow (if your NIC supports it)<br>
<a href="https://doc.dpdk.org/guides/prog_guide/rte_flow.html" rel="noreferrer" target="_blank">https://doc.dpdk.org/guides/prog_guide/rte_flow.html</a><br>
<br>
RSS should be implemented in hardware. So it shouldn't be causing added<br>
latency. What device are you using.<br>
</blockquote></div>