[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 at 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