All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Jack Min <jackmin@nvidia.com>
Cc: Ori Kam <orika@nvidia.com>, Ferruh Yigit <ferruh.yigit@intel.com>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	dev@dpdk.org
Subject: Re: [RFC 2/2] ethdev: queue-based flow aged report
Date: Tue, 31 May 2022 14:57:23 +0200	[thread overview]
Message-ID: <4188686.ejJDZkT8p0@thomas> (raw)
In-Reply-To: <9f20256d-002d-e5d5-d4aa-a4c84deab79f@nvidia.com>

31/05/2022 13:06, Jack Min:
> On 5/31/22 00:42, Thomas Monjalon wrote:
> > 07/04/2022 07:30, Xiaoyu Min:
> >> + * If queue-based flow rule management is used and port configured with
> >> + * flag RTE_FLOW_PORT_FLAG_STRICT_QUEUE, RTE_ETH_EVENT_FLOW_AGED event
> >> + * is triggered with ret_param set to the corresponding flow queue when
> >> + * a flow queue detects new aged-out flows.
> > 
> > Are you sure it is a good idea to use ret_param for such data?
> 
> Well, it seems the only way to add queue information without add/change 
> APIs.
> 
> > ret_param of an event is supposed to be used by the driver
> > to get a confirmation from the application.
> >
> > If the application needs extra info of an event,
> > it is better to do a separate query like rte_flow_get_aged_flows().
> 
> Ok, since the *ret_param* is supposed to be used by driver, then the 
> above approach is not a good idea.
> 
> So we need a new API, something like rte_flow_get_aged_event_queues(), 
> which will return
> 
> all flow queues which has the aged flows, right?

Yes, a new function seems required.




  reply	other threads:[~2022-05-31 12:57 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-07  5:30 [RFC 0/2] queue-based flow aged report Xiaoyu Min
2022-04-07  5:30 ` [RFC 1/2] ethdev: port flags for pre-configuration flow hints Xiaoyu Min
2022-04-07 11:27   ` Ori Kam
2022-04-07 13:01     ` Jack Min
2022-04-07 15:04   ` Stephen Hemminger
2022-04-08  2:35     ` Jack Min
2022-05-30 16:46   ` Thomas Monjalon
2022-05-31 10:47     ` Jack Min
2022-04-07  5:30 ` [RFC 2/2] ethdev: queue-based flow aged report Xiaoyu Min
2022-05-30 16:42   ` Thomas Monjalon
2022-05-31 11:06     ` Jack Min
2022-05-31 12:57       ` Thomas Monjalon [this message]
2022-06-01  7:39 ` [RFC 0/2] " Xiaoyu Min
2022-06-01  7:39   ` [RFC v2 1/2] ethdev: port flags for pre-configuration flow hints Xiaoyu Min
2022-06-01  9:03     ` Ori Kam
2022-06-01 18:20     ` Andrew Rybchenko
2022-06-02  5:50       ` Ori Kam
2022-06-02  9:38       ` Jack Min
2022-06-01  7:39   ` [RFC v2 2/2] ethdev: queue-based flow aged report Xiaoyu Min
2022-06-01 18:21     ` Andrew Rybchenko
2022-06-02  6:10       ` Ori Kam
2022-06-02 10:23         ` Jack Min
2022-06-06  9:47           ` Ori Kam
2022-06-02  9:39       ` Jack Min

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4188686.ejJDZkT8p0@thomas \
    --to=thomas@monjalon.net \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jackmin@nvidia.com \
    --cc=orika@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.