From: Stephen Hemminger <stephen@networkplumber.org>
To: Chaoyong He <chaoyong.he@corigine.com>
Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Niklas Soderlund <niklas.soderlund@corigine.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [PATCH v5 07/12] net/nfp: add flower ctrl VNIC related logics
Date: Thu, 11 Aug 2022 08:07:49 -0700 [thread overview]
Message-ID: <20220811080749.5bdf2c8d@hermes.local> (raw)
In-Reply-To: <SJ0PR13MB55453B9988160E175AD4978F9E649@SJ0PR13MB5545.namprd13.prod.outlook.com>
On Thu, 11 Aug 2022 06:31:31 +0000
Chaoyong He <chaoyong.he@corigine.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger <stephen@networkplumber.org>
> > Sent: Thursday, August 11, 2022 12:25 PM
> > To: Chaoyong He <chaoyong.he@corigine.com>
> > Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>; Niklas
> > Soderlund <niklas.soderlund@corigine.com>; dev@dpdk.org
> > Subject: Re: [PATCH v5 07/12] net/nfp: add flower ctrl VNIC related logics
> >
> > On Thu, 11 Aug 2022 01:26:49 +0000
> > Chaoyong He <chaoyong.he@corigine.com> wrote:
> >
> > > > > The 'port_id' is the 'Device [external] port identifier', which
> > > > > related with the 'rte_ethdev_devices[]' I think.
> > > > > Here the ethdev we created is not exposed to the user and is not
> > > > > in the
> > > > 'rte_ethdev_devices[]'
> > > > > array, so it can't be invoked by the user at all.
> > > > > And we invoke this ethdev through a pointer in the `struct
> > > > > nfp_net_hw`, so I think there should no conflict with other ones
> > > > > in the
> > > > system.
> > > >
> > > > DPDK already has a port ownership framework to deal with internal
> > > > ethernet device ports. Why was this not used?
> > >
> > > Sorry I have no knowledge about this framework before. Any document
> > > link or logic about this framework will be greatly appreciated. Thanks!
> >
> > It is part of ethdev https://doc.dpdk.org/api/rte__ethdev_8h.html
> >
> > See rte_eth_dev_owner_new, rte_eth_dev_owner_set, etc
> > https://doc.dpdk.org/api/rte__ethdev_8h.html#ad6817cc801bf0faa566f52d3
> > 82214457
>
> Thank you very much!
>
> If the app uses the rte_eth_dev_owner_* APIs to check the ownership first, it does can
> protect the internal ethdev ports.
> But right now, the ovs-dpdk seems don't use these APIs at all, and it can use 'port_id' to
> get any ethdev port in rte_ethdev_devices[] array.
> So maybe it's a good idea to keep our original logic and keep an eye on this area, once
> the ovs-dpdk use the rte_eth_dev_owner_* APIs, we'll update the logic here accordingly.
>
> Thanks again!
Once device is owned by something, then it is no longer show in the FOREACH and other
iterators; so ovs-dpdk should be ok. This mechanism is how bonding, failsafe, and netvsc
drivers handle sub devices. Therefore OVS should be smart enough to handle it.
next prev parent reply other threads:[~2022-08-11 15:07 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-05 6:32 [PATCH v5 00/12] preparation for the rte_flow offload of nfp PMD Chaoyong He
2022-08-05 6:32 ` [PATCH v5 01/12] net/nfp: move app specific attributes to own struct Chaoyong He
2022-08-05 10:49 ` Andrew Rybchenko
2022-08-05 6:32 ` [PATCH v5 02/12] net/nfp: simplify initialization and remove dead code Chaoyong He
2022-08-05 6:32 ` [PATCH v5 03/12] net/nfp: move app specific init logic to own function Chaoyong He
2022-08-05 10:53 ` Andrew Rybchenko
2022-08-05 6:32 ` [PATCH v5 04/12] net/nfp: add initial flower firmware support Chaoyong He
2022-08-05 11:00 ` Andrew Rybchenko
2022-08-05 6:32 ` [PATCH v5 05/12] net/nfp: add flower PF setup and mempool init logic Chaoyong He
2022-08-05 12:49 ` Andrew Rybchenko
2022-08-05 6:32 ` [PATCH v5 06/12] net/nfp: add flower PF related routines Chaoyong He
2022-08-05 12:55 ` Andrew Rybchenko
2022-08-05 6:32 ` [PATCH v5 07/12] net/nfp: add flower ctrl VNIC related logics Chaoyong He
2022-08-05 13:05 ` Andrew Rybchenko
2022-08-08 11:32 ` Chaoyong He
2022-08-08 14:45 ` Stephen Hemminger
2022-08-10 1:51 ` Chaoyong He
2022-08-10 19:39 ` Stephen Hemminger
2022-08-11 1:26 ` Chaoyong He
2022-08-11 4:24 ` Stephen Hemminger
2022-08-11 6:31 ` Chaoyong He
2022-08-11 15:07 ` Stephen Hemminger [this message]
2022-08-05 6:32 ` [PATCH v5 08/12] net/nfp: move common rxtx function for flower use Chaoyong He
2022-08-05 6:32 ` [PATCH v5 09/12] net/nfp: add flower ctrl VNIC rxtx logic Chaoyong He
2022-08-05 6:32 ` [PATCH v5 10/12] net/nfp: add flower representor framework Chaoyong He
2022-08-05 14:23 ` Andrew Rybchenko
2022-08-08 11:56 ` Chaoyong He
2022-08-05 6:32 ` [PATCH v5 11/12] net/nfp: move rxtx function to header file Chaoyong He
2022-08-05 6:32 ` [PATCH v5 12/12] net/nfp: add flower PF rxtx logic Chaoyong He
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=20220811080749.5bdf2c8d@hermes.local \
--to=stephen@networkplumber.org \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=chaoyong.he@corigine.com \
--cc=dev@dpdk.org \
--cc=niklas.soderlund@corigine.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).