[dpdk-users] rte_flow multiple queues in same rule's action set

[dpdk-users] rte_flow multiple queues in same rule's action set

[Arvind Narayanan]

Hi,

In rte_flow docs, there is an example (Table 11.28) where the action
set consists of 4 actions:

1. queue(index=5)
2. VOID
3. queue(index=3)
4. END
The docs further say such a rule effectively duplicates the traffic to
both queue 3 and 5. Does this mean "two different mbufs" exist for the
same incoming packet, or does it mean it only duplicates the mbuf
references?

Any clarification is appreciated.

Thanks,
Arvind

Re: [dpdk-users] rte_flow multiple queues in same rule's action set

[Adrien Mazarguil]

On Fri, Aug 02, 2019 at 06:01:49PM -0500, Arvind Narayanan wrote:
> Hi,
> 
> In rte_flow docs, there is an example (Table 11.28) where the action
> set consists of 4 actions:
> 
> 1. queue(index=5)
> 2. VOID
> 3. queue(index=3)
> 4. END
> The docs further say such a rule effectively duplicates the traffic to
> both queue 3 and 5. Does this mean "two different mbufs" exist for the
> same incoming packet, or does it mean it only duplicates the mbuf
> references?
> 
> Any clarification is appreciated.

Beware I'm not aware of any driver properly supporting this at the moment,
so specifying QUEUE twice should usually result in an error, but I think
some drivers don't quite expect it and will silently ignore one of them
(that's a bug).

In any case you're right, it's unspecified and we should fix that.
There are 3 options:

1. Separate mbufs are returned. That was the original unwritten assumption
   (see below).

2. Separate mbufs are returned, but one of them is a clone so they actually
   share data and RTE_MBUF_CLONED() returns true for one of them.

3. The same mbuf pointer is returned, in which case at the very least, mbuf
   refcount should be 2 not to break rte_pktmbuf_free().

In practice drivers can normally not return the same mbuf from two distinct
Rx queues at the same time since Rx mbufs are allocated independently for
each Rx queue. Mbufs are preallocated during setup and replaced while doing
Rx, right before returning them to the application to avoid starvation.

I do not think DPDK applications are ready for 2 and 3 yet. Also due to the
above, doing so would require extra work on the PMD side.

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-users] rte_flow multiple queues in same rule's action set

[Arvind Narayanan]

On Mon, Aug 5, 2019 at 3:11 AM Adrien Mazarguil
<adrien.mazarguil@6wind.com> wrote:
>
> On Fri, Aug 02, 2019 at 06:01:49PM -0500, Arvind Narayanan wrote:
> > Hi,
> >
> > In rte_flow docs, there is an example (Table 11.28) where the action
> > set consists of 4 actions:
> >
> > 1. queue(index=5)
> > 2. VOID
> > 3. queue(index=3)
> > 4. END
> > The docs further say such a rule effectively duplicates the traffic to
> > both queue 3 and 5. Does this mean "two different mbufs" exist for the
> > same incoming packet, or does it mean it only duplicates the mbuf
> > references?
> >
> > Any clarification is appreciated.
>
> Beware I'm not aware of any driver properly supporting this at the moment,
> so specifying QUEUE twice should usually result in an error, but I think
> some drivers don't quite expect it and will silently ignore one of them
> (that's a bug).
>
> In any case you're right, it's unspecified and we should fix that.
> There are 3 options:
>
> 1. Separate mbufs are returned. That was the original unwritten assumption
>    (see below).
>
> 2. Separate mbufs are returned, but one of them is a clone so they actually
>    share data and RTE_MBUF_CLONED() returns true for one of them.
>
> 3. The same mbuf pointer is returned, in which case at the very least, mbuf
>    refcount should be 2 not to break rte_pktmbuf_free().
>
> In practice drivers can normally not return the same mbuf from two distinct
> Rx queues at the same time since Rx mbufs are allocated independently for
> each Rx queue. Mbufs are preallocated during setup and replaced while doing
> Rx, right before returning them to the application to avoid starvation.
>
> I do not think DPDK applications are ready for 2 and 3 yet. Also due to the
> above, doing so would require extra work on the PMD side.
>

Makes perfect sense. Thanks Adrien!

Arvind

> --
> Adrien Mazarguil
> 6WIND