On Mon, Aug 5, 2019 at 3:11 AM Adrien Mazarguil <[email protected]> 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
