From: Chaoyong He <chaoyong.he@corigine.com>
To: Stephen Hemminger <stephen@networkplumber.org>
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 06:31:31 +0000 [thread overview]
Message-ID: <SJ0PR13MB55453B9988160E175AD4978F9E649@SJ0PR13MB5545.namprd13.prod.outlook.com> (raw)
In-Reply-To: <20220810212451.35f8b0ad@hermes.local>
> -----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!
next prev parent reply other threads:[~2022-08-11 6:31 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 [this message]
2022-08-11 15:07 ` Stephen Hemminger
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=SJ0PR13MB55453B9988160E175AD4978F9E649@SJ0PR13MB5545.namprd13.prod.outlook.com \
--to=chaoyong.he@corigine.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=niklas.soderlund@corigine.com \
--cc=stephen@networkplumber.org \
/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).