[dpdk-users] Hairpin with rte_flow?

[dpdk-users] Hairpin with rte_flow?

[Cliff Burdick]

Does anyone know if it's possible to do a hairpin mode using rte_flow? For
example, if I send a packet to 10.1.1.1, in tx queue 0, but I also have a
flow rule to send 10.1.1.1 to rx queue 1, is there a way to get the nic to
do that without sending the actual packet out? Mellanox appears to support
a hairpin mode, but it doesn't look like it's through dpdk.

Re: [dpdk-users] Hairpin with rte_flow?

[Adrien Mazarguil]

On Fri, Oct 19, 2018 at 11:25:42AM -1000, Cliff Burdick wrote:
> Does anyone know if it's possible to do a hairpin mode using rte_flow? For
> example, if I send a packet to 10.1.1.1, in tx queue 0, but I also have a
> flow rule to send 10.1.1.1 to rx queue 1, is there a way to get the nic to
> do that without sending the actual packet out? Mellanox appears to support
> a hairpin mode, but it doesn't look like it's through dpdk.

Hairpin on the *same* port cannot be expressed through rte_flow yet. On the
other hand something similar can be achieved using a port representor.

Assuming port 3 is VF and port 4 its representor, with testpmd you could do:

 flow create 3 transfer egress pattern eth / ipv4 dst is 10.1.1.1 / end
     actions port_id id 4 / end
 flow create 3 ingress pattern eth / ipv4 dst is 10.1.1.1 / end
     actions queue index 1 / end

The first rule requests the device to actively route matching egress traffic
from port 3 through the representor (port 4). Since traffic received by a
representor should be fed back to its associated VF, that traffic should be
received on port 3.

The second rule is not mandatory, however without it RSS might otherwise
dispatch it to a different queue.

Question is which drivers implement this use case. While I'm aware mlx5
supports PF/VF/representor redirections, I don't know if a VF can feed its
own representor like that. A true hairpin action is missing anyway.

-- 
Adrien Mazarguil
6WIND