DPDK usage discussions
 help / color / Atom feed
* [dpdk-users] rte_flow multiple queues in same rule's action set
@ 2019-08-02 23:01 Arvind Narayanan
  2019-08-05  8:11 ` Adrien Mazarguil
  0 siblings, 1 reply; 3+ messages in thread
From: Arvind Narayanan @ 2019-08-02 23:01 UTC (permalink / raw)
  To: users

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-users] rte_flow multiple queues in same rule's action set
  2019-08-02 23:01 [dpdk-users] rte_flow multiple queues in same rule's action set Arvind Narayanan
@ 2019-08-05  8:11 ` Adrien Mazarguil
  2019-08-05 23:22   ` Arvind Narayanan
  0 siblings, 1 reply; 3+ messages in thread
From: Adrien Mazarguil @ 2019-08-05  8:11 UTC (permalink / raw)
  To: Arvind Narayanan; +Cc: users

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-users] rte_flow multiple queues in same rule's action set
  2019-08-05  8:11 ` Adrien Mazarguil
@ 2019-08-05 23:22   ` Arvind Narayanan
  0 siblings, 0 replies; 3+ messages in thread
From: Arvind Narayanan @ 2019-08-05 23:22 UTC (permalink / raw)
  To: Adrien Mazarguil; +Cc: users

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-02 23:01 [dpdk-users] rte_flow multiple queues in same rule's action set Arvind Narayanan
2019-08-05  8:11 ` Adrien Mazarguil
2019-08-05 23:22   ` Arvind Narayanan

DPDK usage discussions

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/users/0 users/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 users users/ http://inbox.dpdk.org/users \
		users@dpdk.org
	public-inbox-index users


Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.users


AGPL code for this site: git clone https://public-inbox.org/ public-inbox