From: Thomas Monjalon <thomas@monjalon.net>
To: Chaoyong He <chaoyong.he@corigine.com>,
David Marchand <david.marchand@redhat.com>,
Ian Stokes <ian.stokes@intel.com>,
dev@dpdk.org
Cc: oss-drivers <oss-drivers@corigine.com>,
Niklas Soderlund <niklas.soderlund@corigine.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Ferruh Yigit <ferruh.yigit@xilinx.com>
Subject: Re: [PATCH v8 05/12] net/nfp: add flower PF setup logic
Date: Wed, 14 Sep 2022 11:20:03 +0200 [thread overview]
Message-ID: <4087621.1IzOArtZ34@thomas> (raw)
In-Reply-To: <cfa0073a-db00-54ee-4934-d9a47954465f@xilinx.com>
09/09/2022 14:13, Ferruh Yigit:
> On 9/9/2022 3:36 AM, Chaoyong He wrote:
> >> On 9/8/2022 9:44 AM, Chaoyong He wrote:
> >>> Adds the vNIC initialization logic for the flower PF vNIC. The flower
> >>> firmware exposes this vNIC for the purposes of fallback traffic in the
> >>> switchdev use-case.
> >>>
> >>> Adds minimal dev_ops for this PF device. Because the device is being
> >>> exposed externally to DPDK it should also be configured using DPDK
> >>> helpers like rte_eth_configure(). For these helpers to work the flower
> >>> logic needs to implements a minimal set of dev_ops.
> >>>
> >>> Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
> >>> Reviewed-by: Niklas Söderlund <niklas.soderlund@corigine.com>
> >>> ---
> >>> drivers/net/nfp/flower/nfp_flower.c | 398
> >> ++++++++++++++++++++++++-
> >>> drivers/net/nfp/flower/nfp_flower.h | 6 +
> >>> drivers/net/nfp/flower/nfp_flower_ovs_compat.h | 37 +++
> >>
> >> Can you please detail why OVS specific header is required? Having application
> >> specific code in PMD can be sign of some design issue, that is why can you
> >> please explain more what it does?
> >>
> >
> > Basically, there exist two layers polling mode to move a pkt from firmware to OVS.
> >
> > When our card using flower application firmware receive pkt and find the pkt can't be offloaded,
> > it will record the input port in a place of the pkt, we call it metadata.
> >
> > There exist a rte_ring for each representor port.
> >
> > We use the pf device as a multiplexer, which keeps polling pkts from the firmware.
> > Based on the metadata, it will enqueue the pkt into the rte_ring of the corresponding representor port.
> >
> > On the OVS side, it will keeps try to dequeue the pkt from the rte_ring of the representor port.
> > Once it gets the pkt, the OVS will go its logic and treat the pkt as `struct dp_packet`.
> >
> > So we copy the definition of `struct dp_packet` from OVS to prevent the coredump caused by memory read/write out of range.
> >
> > Another possible way is defining a big enough mbuf_priv_len using macro to prevent this structure definition from OVS.
> > Is this the right way?
> >
>
> Thanks for clarification.
>
> PMD is creating a mempool to hold 'struct dp_packet', that is why it is
> duplicating OvS 'struct dp_packet' struct definition to DPDK.
>
> But many PMDs are used with OvS, why only nfp need to duplicate the
> struct or create OvS specific mempool?
> Having application specific code in driver looks wrong anyway.
+1 to be application agnostic
next prev parent reply other threads:[~2022-09-14 9:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 8:44 [PATCH v8 00/12] preparation for the rte_flow offload of nfp PMD Chaoyong He
2022-09-08 8:44 ` [PATCH v8 01/12] net/nfp: move app specific attributes to own struct Chaoyong He
2022-09-08 16:24 ` Ferruh Yigit
2022-09-09 1:49 ` Chaoyong He
2022-09-09 5:43 ` Chaoyong He
2022-09-09 12:13 ` Ferruh Yigit
2022-09-08 8:44 ` [PATCH v8 02/12] net/nfp: simplify initialization and remove dead code Chaoyong He
2022-09-08 8:44 ` [PATCH v8 03/12] net/nfp: move app specific init logic to own function Chaoyong He
2022-09-08 8:44 ` [PATCH v8 04/12] net/nfp: add initial flower firmware support Chaoyong He
2022-09-08 16:24 ` Ferruh Yigit
2022-09-08 8:44 ` [PATCH v8 05/12] net/nfp: add flower PF setup logic Chaoyong He
2022-09-08 16:24 ` Ferruh Yigit
2022-09-09 2:36 ` Chaoyong He
2022-09-09 12:13 ` Ferruh Yigit
2022-09-14 9:20 ` Thomas Monjalon [this message]
2022-09-09 12:19 ` Ferruh Yigit
2022-09-13 6:51 ` Chaoyong He
2022-09-13 9:08 ` Ferruh Yigit
2022-09-14 1:23 ` Chaoyong He
2022-09-14 9:25 ` Thomas Monjalon
2022-09-08 8:44 ` [PATCH v8 06/12] net/nfp: add flower PF related routines Chaoyong He
2022-09-08 8:44 ` [PATCH v8 07/12] net/nfp: add flower ctrl VNIC related logics Chaoyong He
2022-09-08 8:44 ` [PATCH v8 08/12] net/nfp: move common rxtx function for flower use Chaoyong He
2022-09-08 8:44 ` [PATCH v8 09/12] net/nfp: add flower ctrl VNIC rxtx logic Chaoyong He
2022-09-08 8:45 ` [PATCH v8 10/12] net/nfp: add flower representor framework Chaoyong He
2022-09-08 8:45 ` [PATCH v8 11/12] net/nfp: move rxtx function to header file Chaoyong He
2022-09-08 8:45 ` [PATCH v8 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=4087621.1IzOArtZ34@thomas \
--to=thomas@monjalon.net \
--cc=chaoyong.he@corigine.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@xilinx.com \
--cc=ian.stokes@intel.com \
--cc=niklas.soderlund@corigine.com \
--cc=oss-drivers@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).