DPDK-dev Archive on lore.kernel.org
 help / color / Atom feed
From: Andrey Vesnovaty <andrey.vesnovaty@gmail.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: Thomas Monjalon <thomas@monjalon.net>, dpdk-dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC v2 0/1] add flow action context API
Date: Wed, 1 Jul 2020 12:24:28 +0300
Message-ID: <CAOwx9StRmG6xU+YyEb0fr9pVouDPi6B6-g8gRJrVP3NyLr5-1Q@mail.gmail.com> (raw)
In-Reply-To: <CALBAE1NOzb4WKVdkS2a299eK_zE2j6aMsaQ2Crn+B-Q=uWz2Lw@mail.gmail.com>

On Tue, Jun 30, 2020 at 12:52 PM Jerin Jacob <jerinjacobk@gmail.com> wrote:

> On Mon, Jun 29, 2020 at 3:52 PM Andrey Vesnovaty
> <andrey.vesnovaty@gmail.com> wrote:
> >
> >
> >
> > On Sun, Jun 28, 2020 at 4:42 PM Jerin Jacob <jerinjacobk@gmail.com>
> wrote:
> >>
> >> On Sun, Jun 28, 2020 at 2:14 PM Andrey Vesnovaty
> >> <andrey.vesnovaty@gmail.com> wrote:
> >> >
> >> > Hi
> >> >
> >> > On Fri, Jun 26, 2020 at 2:44 PM Jerin Jacob <jerinjacobk@gmail.com>
> wrote:
> >> >>
> >> >> On Sat, Jun 20, 2020 at 7:02 PM Andrey Vesnovaty
> >> >> <andrey.vesnovaty@gmail.com> wrote:
> >> >> >
> >> >> > Hi, and thanks a lot for your RFC v1 comments.
> >> >> >
> >> >> > RFC v2 emphasize the intent for sharing the flow action:
> >> >> > * The term 'action context' was unclear and replaced with
> >> >> >    'shared action'.
> >> >> > * RFC v2 subject became 'add flow shared action API'.
> >> >> > * all proposed APIs renamed according the above.
> >> >> >
> >> >> > The new shared action is an independent entity decoupled from any
> flow
> >> >> > while any flow can reuse such an action. Please go over the RFC
> >> >> > description, it was almost entirely rewritten.
> >> >> >
> >> >> > @Jerin Jacob:
> >> >> > Thanks again for your comments, it made me admit that v1
> description was
> >> >> > incomplete & unclear.  I hope v2 will be better at least in terms
> of
> >> >> > clarity.
> >> >>
> >> >> The public API and its usage is very clear. Thanks for this RFC.
> >> >
> >> >
> >> > My pleasure.
> >> >>
> >> >>
> >> >> I think, RFC v2 still not addressing the concern raised in the
> >> >> http://mails.dpdk.org/archives/dev/2020-June/169296.html.
> >> >>
> >> >> Since MLX hardware has an HW based shared object it is fine to have
> >> >> public API based on that level of abstraction.
> >> >> But at the PMD driver level we need to choose the correct abstraction
> >> >> to support all PMD and support shared object scheme if possible.
> >> >>
> >> >> I purpose to introduce something below or similar
> >> >>             int (*action_update)
> >> >>                 (struct rte_eth_dev *,
> >> >>                   struct rte_flow *flow,
> >> >>                  const struct rte_flow_action [],
> >> >>                  struct rte_flow_error *);
> >> >
> >> > Where this callback suppose to belong (struct rte_flow_ops)?
> >>
> >> Yes.
> >>
> >> > How should it be implemented by PMD?
> >>
> >> See below,
> >>
> >> > Is it about shared action and if "yes" why there is 'flow' argument?
> >>
> >> flow holds the "pattern" and "action" data as PMD specific handle.
> >> So PMD, implementation can just change that action if it gets the PMD
> >> specific handle.
> >>
> >>
> >> >>
> >> >>
> >> >> in addition to: shared_action_create, shared_action_destroy,
> >> >> shared_action_update, shared_action_query
> >> >>
> >> >> Have generic implementation of above, if action_update callback is
> not
> >> >> NULL.
> >> >
> >> > "is not NULL" -> "is NULL"?
> >>
> >> Yes. When it is NULL.
> >
> >
> > Jerin, few clarifications regarding generic implementation of shared
> action:
> > Based on this conversation I'm assuming that generic implementation
> supposed to be something like:
> > For each flow using some shared action:
> > call ops-> action_update()
> > If the assumption above correct:
> > 1. taking into account that shared_action_update() is atomic, how can
> this deal with partial success: some flows may fail validation - should it:
> >   1.1.lock all flows
> >   1.2.validate all flows
> >   1.3.update all flows
> >   1.4. unlock
>
> Yes.
>
This kind of locking in addition to shared session management requires
locking of each flow_create/flow_destroy in addition to action_uodate
callback implementation even if there are no shared actions at all. In
other words it imposes an overhead on all PMDs that don't support shared
action natively.

>
> > 2. action_update callback is PMD specific & if it's unsupported there is
> no support for shared action any way
>
> Yes.
>
> > Please address the issues above
>
> >
> >> >
> >> >>
> >> >> So that, it can work all PMDs and to
> >> >> avoid the duplication of "complex" shared session management code.
> >> >
> >> > Do you mean shared action in use by multiple flows by "shared
> session"?
> >>
> >> Yes.
> >
> > Common 'shared session' management code:
> > - can be reduced to atomic usage counter
> > - maintaining list of flow using shared action expected to impact
> performance & not necessary for all PMD specific implementations
> > Access to other shared resources hard to generalize because:
> > - for some PMDs mutual exclusion is HW feature & no need to protect it
> in SW
> > - for others there may be multiple resources & access to each one
> protected by different mechanism
>
> The general callback you can assume, it supports only action_update
> based callback.
> If PMD has mutual exclusion HW feature then it can override the
> function pointers.
>
>
>
> > An observation related to action_update callback:
> > If replaced (updated) action was shared then the flow won't be
> influenced any more by updates or removed shared action.
>

  reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20  9:18 [dpdk-dev] [RFC] " Andrey Vesnovaty
2020-06-03 10:02 ` Thomas Monjalon
2020-06-04 11:12   ` Andrey Vesnovaty
2020-06-04 17:23     ` Thomas Monjalon
2020-06-05  8:30       ` Bruce Richardson
2020-06-05  8:33         ` Thomas Monjalon
2020-06-03 10:53 ` Jerin Jacob
2020-06-04 11:25   ` Andrey Vesnovaty
2020-06-04 12:36     ` Jerin Jacob
2020-06-04 15:57       ` Andrey Vesnovaty
2020-06-09 16:01         ` Jerin Jacob
2020-06-20 13:32           ` [dpdk-dev] [RFC v2 0/1] " Andrey Vesnovaty
2020-06-22 15:22             ` Thomas Monjalon
2020-06-22 17:09               ` Andrey Vesnovaty
2020-06-26 11:44             ` Jerin Jacob
2020-06-28  8:44               ` Andrey Vesnovaty
2020-06-28 13:42                 ` Jerin Jacob
2020-06-29 10:22                   ` Andrey Vesnovaty
2020-06-30  9:52                     ` Jerin Jacob
2020-07-01  9:24                       ` Andrey Vesnovaty [this message]
2020-07-01 10:34                         ` Jerin Jacob
2020-06-20 13:32           ` [dpdk-dev] [RFC v2 1/1] add flow shared action API Andrey Vesnovaty
2020-07-02  0:24             ` Stephen Hemminger
2020-07-02  7:20               ` Ori Kam
2020-07-02  8:06                 ` Andrey Vesnovaty

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=CAOwx9StRmG6xU+YyEb0fr9pVouDPi6B6-g8gRJrVP3NyLr5-1Q@mail.gmail.com \
    --to=andrey.vesnovaty@gmail.com \
    --cc=dev@dpdk.org \
    --cc=jerinjacobk@gmail.com \
    --cc=thomas@monjalon.net \
    /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

DPDK-dev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dpdk-dev/0 dpdk-dev/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 dpdk-dev dpdk-dev/ https://lore.kernel.org/dpdk-dev \
		dev@dpdk.org
	public-inbox-index dpdk-dev

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.dpdk.dev


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