From: Ed Czeck <ed.czeck@atomicrules.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>
Cc: dev@dpdk.org, Shepard Siegel <shepard.siegel@atomicrules.com>,
John Miller <john.miller@atomicrules.com>
Subject: Re: [PATCH 2/3] net/ark: remove RQ pacing firmware from PMD
Date: Tue, 10 Oct 2023 10:50:33 -0400 [thread overview]
Message-ID: <CALZ3Gug_097C=XdZij6uHviuuMJFea-weTJ=FiyBHB9dm8JrbA@mail.gmail.com> (raw)
In-Reply-To: <59b9f084-1743-41ba-86ea-82ad02b2c66f@amd.com>
[-- Attachment #1: Type: text/plain, Size: 5037 bytes --]
On Tue, Oct 10, 2023 at 9:51 AM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
> On 10/5/2023 9:52 PM, Ed Czeck wrote:
> > features and function have been removed from FPGA firmware
> >
>
> I am always a little confused how you manage the deployment, if a
> customer requires RQ pacing, how you manage it, at least should it be
> documented in driver documentation that RQ pacing supported before
> v23.11, or something like that?
> If this doesn't make sense for your deployment model, scratch it, this
> is just a reminder if it is useful.
Our deployment needs to balance the DPDK release, our FPGA firmware, our
(not yet
published) DPDKpatches and external FPGA-IP firmware from AMD (Xilinx) and
Intel
(Altera). We have safety code to ensure that these fall into a valid
alignment. We also
try to maintain SW/FPGA compatibility and evolve without breaking things
unnecessarily.
Our releases follow DPDK's and we update other tools as they are released.
For RQ pacing, it was an internal feature needed for older Xilinx PCIE IP,
with a
narrow exposure via our PMD. The Xilinx IP no longer requires this module,
our
firmware no longer includes it, and the PMD can drop. It was not user
controllable
nor an advertised feature.
>
>
> > Signed-off-by: Ed Czeck <ed.czeck@atomicrules.com>
> > ---
> > drivers/net/ark/ark_ethdev.c | 62 ++++++++------------------------
> > drivers/net/ark/ark_global.h | 3 --
> > drivers/net/ark/ark_rqp.c | 70 ------------------------------------
> > drivers/net/ark/ark_rqp.h | 58 ------------------------------
> > drivers/net/ark/meson.build | 1 -
> > 5 files changed, 15 insertions(+), 179 deletions(-)
> > delete mode 100644 drivers/net/ark/ark_rqp.c
> > delete mode 100644 drivers/net/ark/ark_rqp.h
> >
> > diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
> > index 90d3c8abe6..306121ba31 100644
> > --- a/drivers/net/ark/ark_ethdev.c
> > +++ b/drivers/net/ark/ark_ethdev.c
> > @@ -17,7 +17,6 @@
> > #include "ark_mpu.h"
> > #include "ark_ddm.h"
> > #include "ark_udm.h"
> > -#include "ark_rqp.h"
> > #include "ark_pktdir.h"
> > #include "ark_pktgen.h"
> > #include "ark_pktchkr.h"
> > @@ -107,36 +106,32 @@ static const struct rte_pci_id pci_id_ark_map[] =
{
> > * This structure is used to statically define the capabilities
> > * of supported devices.
> > * Capabilities:
> > - * rqpacing -
> > - * Some HW variants require that PCIe read-requests be correctly
throttled.
> > - * This is called "rqpacing" and has to do with credit and flow control
> > - * on certain Arkville implementations.
> > + * isvf -- defined for function id that are virtual
> > */
> > struct ark_caps {
> > - bool rqpacing;
> > bool isvf;
> > };
> > struct ark_dev_caps {
> > uint32_t device_id;
> > struct ark_caps caps;
> > };
> > -#define SET_DEV_CAPS(id, rqp, vf) \
> > - {id, {.rqpacing = rqp, .isvf = vf} }
> > +#define SET_DEV_CAPS(id, vf) \
> > + {id, {.isvf = vf} }
> >
> > static const struct ark_dev_caps
> > ark_device_caps[] = {
> > - SET_DEV_CAPS(0x100d, true, false),
> > - SET_DEV_CAPS(0x100e, true, false),
> > - SET_DEV_CAPS(0x100f, true, false),
> > - SET_DEV_CAPS(0x1010, false, false),
> > - SET_DEV_CAPS(0x1017, true, false),
> > - SET_DEV_CAPS(0x1018, true, false),
> > - SET_DEV_CAPS(0x1019, true, false),
> > - SET_DEV_CAPS(0x101a, true, false),
> > - SET_DEV_CAPS(0x101b, true, false),
> > - SET_DEV_CAPS(0x101c, true, true),
> > - SET_DEV_CAPS(0x101e, false, false),
> > - SET_DEV_CAPS(0x101f, false, false),
> > + SET_DEV_CAPS(0x100d, false),
> > + SET_DEV_CAPS(0x100e, false),
> > + SET_DEV_CAPS(0x100f, false),
> > + SET_DEV_CAPS(0x1010, false),
> > + SET_DEV_CAPS(0x1017, false),
> > + SET_DEV_CAPS(0x1018, false),
> > + SET_DEV_CAPS(0x1019, false),
> > + SET_DEV_CAPS(0x101a, false),
> > + SET_DEV_CAPS(0x101b, false),
> > + SET_DEV_CAPS(0x101c, true),
> > + SET_DEV_CAPS(0x101e, false),
> > + SET_DEV_CAPS(0x101f, false),
> > {.device_id = 0,}
> > };
> >
> > @@ -301,9 +296,6 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
> > int port_count = 1;
> > int p;
> > uint16_t num_queues;
> > - bool rqpacing = false;
> > -
> > - ark->eth_dev = dev;
> >
>
> Above "ark->eth_dev" assignment doesn't look directly related with RQ
> pacing, I just want to double check if it is removed intentionally?
This change is in error. Thanks for catching it. New patch to follow.
>
>
[-- Attachment #2: Type: text/html, Size: 6522 bytes --]
next prev parent reply other threads:[~2023-10-10 14:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 20:52 [PATCH 1/3] net/ark: support for single function with multiple port Ed Czeck
2023-10-05 20:52 ` [PATCH 2/3] net/ark: remove RQ pacing firmware from PMD Ed Czeck
2023-10-10 13:51 ` Ferruh Yigit
2023-10-10 14:50 ` Ed Czeck [this message]
2023-10-10 16:08 ` [PATCH v2 " Ed Czeck
2023-10-10 16:37 ` Ferruh Yigit
2023-10-05 20:52 ` [PATCH 3/3] net/ark: support for large dataroom in FPGA Ed Czeck
2023-10-10 20:42 ` [PATCH v2 1/3] net/ark: support for single function with multiple port Ed Czeck
2023-10-10 20:42 ` [PATCH v2 2/3] net/ark: remove RQ pacing firmware from PMD Ed Czeck
2023-10-10 20:42 ` [PATCH v2 3/3] net/ark: support for large dataroom in FPGA Ed Czeck
2023-10-11 11:28 ` [PATCH v2 1/3] net/ark: support for single function with multiple port Ferruh Yigit
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='CALZ3Gug_097C=XdZij6uHviuuMJFea-weTJ=FiyBHB9dm8JrbA@mail.gmail.com' \
--to=ed.czeck@atomicrules.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=john.miller@atomicrules.com \
--cc=shepard.siegel@atomicrules.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).