RE: [RFC 00/27] Add VDUSE support to Vhost library

2023-04-13 Thread Xia, Chenbo
> -Original Message-
> From: Morten Brørup 
> Sent: Thursday, April 13, 2023 3:41 AM
> To: Maxime Coquelin ; Ferruh Yigit
> ; dev@dpdk.org; david.march...@redhat.com; Xia,
> Chenbo ; m...@redhat.com; f...@redhat.com;
> jasow...@redhat.com; Liang, Cunming ; Xie, Yongji
> ; echau...@redhat.com; epere...@redhat.com;
> amore...@redhat.com
> Subject: RE: [RFC 00/27] Add VDUSE support to Vhost library
> 
> > From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
> > Sent: Wednesday, 12 April 2023 17.28
> >
> > Hi Ferruh,
> >
> > On 4/12/23 13:33, Ferruh Yigit wrote:
> > > On 3/31/2023 4:42 PM, Maxime Coquelin wrote:
> > >> This series introduces a new type of backend, VDUSE,
> > >> to the Vhost library.
> > >>
> > >> VDUSE stands for vDPA device in Userspace, it enables
> > >> implementing a Virtio device in userspace and have it
> > >> attached to the Kernel vDPA bus.
> > >>
> > >> Once attached to the vDPA bus, it can be used either by
> > >> Kernel Virtio drivers, like virtio-net in our case, via
> > >> the virtio-vdpa driver. Doing that, the device is visible
> > >> to the Kernel networking stack and is exposed to userspace
> > >> as a regular netdev.
> > >>
> > >> It can also be exposed to userspace thanks to the
> > >> vhost-vdpa driver, via a vhost-vdpa chardev that can be
> > >> passed to QEMU or Virtio-user PMD.
> > >>
> > >> While VDUSE support is already available in upstream
> > >> Kernel, a couple of patches are required to support
> > >> network device type:
> > >>
> > >> https://gitlab.com/mcoquelin/linux/-/tree/vduse_networking_poc
> > >>
> > >> In order to attach the created VDUSE device to the vDPA
> > >> bus, a recent iproute2 version containing the vdpa tool is
> > >> required.
> > >
> > > Hi Maxime,
> > >
> > > Is this a replacement to the existing DPDK vDPA framework? What is the
> > > plan for long term?
> > >
> >
> > No, this is not a replacement for DPDK vDPA framework.
> >
> > We (Red Hat) don't have plans to support DPDK vDPA framework in our
> > products, but there are still contribution to DPDK vDPA by several vDPA
> > hardware vendors (Intel, Nvidia, Xilinx), so I don't think it is going
> > to be deprecated soon.
> 
> Ferruh's question made me curious...
> 
> I don't know anything about VDUSE or vDPA, and don't use any of it, so
> consider me ignorant in this area.
> 
> Is VDUSE an alternative to the existing DPDK vDPA framework? What are the
> differences, e.g. in which cases would an application developer (or user)
> choose one or the other?

Maxime should give better explanation.. but let me just explain a bit.

Vendors have vDPA HW that support vDPA framework (most likely in their DPU/IPU
products). This work is introducing a way to emulate a SW vDPA device in
userspace (DPDK), and this SW vDPA device also supports vDPA framework.

So it's not an alternative to existing DPDK vDPA framework :)

Thanks,
Chenbo

> 
> And if it is a better alternative, perhaps the documentation should
> mention that it is recommended over DPDK vDPA. Just like we started
> recommending alternatives to the KNI driver, so we could phase it out and
> eventually get rid of it.
> 
> >
> > Regards,
> > Maxime



Re: [EXT] Re: [PATCH] kni: fix build with Linux 6.3

2023-04-13 Thread David Marchand
On Fri, Mar 24, 2023 at 4:04 AM Vamsi Krishna Attunuru
 wrote:
> > > So I think the dpdk commit e73831dc6c26 ("kni: support userspace VA")
> > > uselessly introduced call to this flag and we can remove it.
> > > Adding author and reviewers of this change.
> >
> > Alternatively, we could go with passing 0 in flags when FOLL_TOUCH is not
> > exported.
> > Something like:
>
> Yes, this flag is useless, I vaguely remember like I added it from v1(in that 
> patch series) itself along with multiple kernel version checks,
> but by looking at the internals neither of them would not need it.
>
> We could pass 0 in flags as suggested.

Ok, thanks for the confirmation Vamsi.
Ferruh, can you submit a v2?


-- 
David Marchand



Re: [PATCH v1 1/2] dts: fabric requirements

2023-04-13 Thread Juraj Linkeš
On Thu, Apr 13, 2023 at 8:50 AM Juraj Linkeš  wrote:
>
> On Wed, Apr 12, 2023 at 5:38 PM Honnappa Nagarahalli
>  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Thomas Monjalon 
> > > Sent: Wednesday, April 12, 2023 10:25 AM
> > > To: Juraj Linkeš 
> > > Cc: Wathsala Wathawana Vithanage ;
> > > jspew...@iol.unh.edu; pr...@iol.unh.edu; Honnappa Nagarahalli
> > > ; lijuan...@intel.com;
> > > bruce.richard...@intel.com; dev@dpdk.org
> > > Subject: Re: [PATCH v1 1/2] dts: fabric requirements
> > >
> > > 12/04/2023 15:42, Juraj Linkeš:
> > > > On Tue, Apr 11, 2023 at 4:48 PM Thomas Monjalon 
> > > wrote:
> > > > >
> > > > > 04/04/2023 13:51, Juraj Linkeš:
> > > > > > On Mon, Apr 3, 2023 at 5:18 PM Thomas Monjalon
> > >  wrote:
> > > > > >
> > > > > > > 03/04/2023 16:56, Juraj Linkeš:
> > > > > > > > On Mon, Apr 3, 2023 at 2:33 PM Thomas Monjalon
> > > > > > > > 
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > 03/04/2023 13:46, Juraj Linkeš:
> > > > > > > > > > Replace pexpect with Fabric.
> > > > > > > > >
> > > > > > > > > You should squash these lines with the move to Fabric.
> > > > > > > > >
> > > > > > > > > > Signed-off-by: Juraj Linkeš 
> > > > > > > > > > ---
> > > > > > > > > >  dts/poetry.lock| 553
> > > > > > > +++--
> > > > > > > > >
> > > > > > > > > Do we really need *all* these lines?
> > > > > > > > > I see a lot of lines about Windows and MacOSX which are not
> > > > > > > > > supported
> > > > > > > in
> > > > > > > > > DTS.
> > > > > > > > > It is so long that it looks impossible to review.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > This is a generated file and doesn't need to be reviewed.
> > > > > > >
> > > > > > > In general, I don't like storing generated files.
> > > > > > >
> > > > > >
> > > > > > Me neither, but this one is specifically designed to be stored in
> > > > > > a
> > > > > > repository:
> > > > > > https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock
> > > > > > -file-to-version-control
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > > I separated the
> > > > > > > > dependencies part so that the code part is easier to review.
> > > > > > > > If you
> > > > > > > want, I
> > > > > > > > can squash the two commits.
> > > > > > >
> > > > > > > What happens if we manually remove the useless lines?
> > > > > > >
> > > > > > >
> > > > > > The lock file is there so that everyone installs exactly the same
> > > > > > versions of dependencies. We can specify the versions of
> > > > > > dependencies in pyproject.toml, but we won't control the versions
> > > > > > of dependencies of dependencies this way. If we remove the changes
> > > > > > to the lock file, then we won't be storing tested versions,
> > > > > > everyone would be using slightly different versions and we may
> > > > > > potentially need to address versioning issues in the future - best 
> > > > > > to prevent
> > > that with a lock file.
> > > > >
> > > > > You didn't answer about removing the usuless lines, like unneeded 
> > > > > Windows
> > > support.
> > > > >
> > > >
> > > > Do you mean the list of files from macos and windows? I tried removing
> > > > those from mypy and testing it and it looks like it didn't have an
> > > > impact, but I don't know the inner workings of poetry and the lock
> > > > file to test it properly (i.e. to rule out any breakages). What would
> > > > be the reason for removing those? Seems like it has more downsides (we
> > > > could potentially break something and it's extra work) than updsides
> > > > (as this is a generated file, I don't really see any).
> > >
> > > Yes this is what I mean.
> > > Any other opinion?
> > >
> > If it is a generated file, there might be an expectation from the tool that 
> > the file is not changed. It would be good to understand this.
> >
> > Since it is a generated file, should we generate this during DTS run time 
> > rather than storing a generated file?
> >
>
> The file is not used during runtime, but rather when installing
> dependencies. It's supposed to be generated by maintainers (once every
> time dependencies change or need updating) who verify the versions
> defined in the generated lockfile so that everyone then uses the same
> versions from that point on, preventing issues arising from different
> users using different versions of dependencies. So it's maintainers
> giving this file to other people.
>
> Juraj

I looked into this some more and I have some extra stuff to explain.

There's another patch that updates and cleans up the dependencies:
http://patches.dpdk.org/project/dpdk/patch/20230331091355.1224059-1-juraj.lin...@pantheon.tech/
To do this patch, I updated my Poetry version to 1.2.0 and apparently,
then changed the file lists of packages. Before, they had that in a
separate section and in Poetry 1.2.0 they separated it into packages.

This led to this patch having a lot of unrelated changes (in unrelated
dependencies) brought on by the Po

RE: [RFC 00/27] Add VDUSE support to Vhost library

2023-04-13 Thread Morten Brørup
> From: Xia, Chenbo [mailto:chenbo@intel.com]
> Sent: Thursday, 13 April 2023 09.08
> 
> > From: Morten Brørup 
> > Sent: Thursday, April 13, 2023 3:41 AM
> >
> > > From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
> > > Sent: Wednesday, 12 April 2023 17.28
> > >
> > > Hi Ferruh,
> > >
> > > On 4/12/23 13:33, Ferruh Yigit wrote:
> > > > On 3/31/2023 4:42 PM, Maxime Coquelin wrote:
> > > >> This series introduces a new type of backend, VDUSE,
> > > >> to the Vhost library.
> > > >>
> > > >> VDUSE stands for vDPA device in Userspace, it enables
> > > >> implementing a Virtio device in userspace and have it
> > > >> attached to the Kernel vDPA bus.
> > > >>
> > > >> Once attached to the vDPA bus, it can be used either by
> > > >> Kernel Virtio drivers, like virtio-net in our case, via
> > > >> the virtio-vdpa driver. Doing that, the device is visible
> > > >> to the Kernel networking stack and is exposed to userspace
> > > >> as a regular netdev.
> > > >>
> > > >> It can also be exposed to userspace thanks to the
> > > >> vhost-vdpa driver, via a vhost-vdpa chardev that can be
> > > >> passed to QEMU or Virtio-user PMD.
> > > >>
> > > >> While VDUSE support is already available in upstream
> > > >> Kernel, a couple of patches are required to support
> > > >> network device type:
> > > >>
> > > >> https://gitlab.com/mcoquelin/linux/-/tree/vduse_networking_poc
> > > >>
> > > >> In order to attach the created VDUSE device to the vDPA
> > > >> bus, a recent iproute2 version containing the vdpa tool is
> > > >> required.
> > > >
> > > > Hi Maxime,
> > > >
> > > > Is this a replacement to the existing DPDK vDPA framework? What is the
> > > > plan for long term?
> > > >
> > >
> > > No, this is not a replacement for DPDK vDPA framework.
> > >
> > > We (Red Hat) don't have plans to support DPDK vDPA framework in our
> > > products, but there are still contribution to DPDK vDPA by several vDPA
> > > hardware vendors (Intel, Nvidia, Xilinx), so I don't think it is going
> > > to be deprecated soon.
> >
> > Ferruh's question made me curious...
> >
> > I don't know anything about VDUSE or vDPA, and don't use any of it, so
> > consider me ignorant in this area.
> >
> > Is VDUSE an alternative to the existing DPDK vDPA framework? What are the
> > differences, e.g. in which cases would an application developer (or user)
> > choose one or the other?
> 
> Maxime should give better explanation.. but let me just explain a bit.
> 
> Vendors have vDPA HW that support vDPA framework (most likely in their DPU/IPU
> products). This work is introducing a way to emulate a SW vDPA device in
> userspace (DPDK), and this SW vDPA device also supports vDPA framework.
> 
> So it's not an alternative to existing DPDK vDPA framework :)
> 
> Thanks,
> Chenbo

Not an alternative, then nothing further from me. :-)

> 
> >
> > And if it is a better alternative, perhaps the documentation should
> > mention that it is recommended over DPDK vDPA. Just like we started
> > recommending alternatives to the KNI driver, so we could phase it out and
> > eventually get rid of it.
> >
> > >
> > > Regards,
> > > Maxime



Re: [RFC 00/27] Add VDUSE support to Vhost library

2023-04-13 Thread Maxime Coquelin

Hi,

On 4/13/23 09:08, Xia, Chenbo wrote:

-Original Message-
From: Morten Brørup 
Sent: Thursday, April 13, 2023 3:41 AM
To: Maxime Coquelin ; Ferruh Yigit
; dev@dpdk.org; david.march...@redhat.com; Xia,
Chenbo ; m...@redhat.com; f...@redhat.com;
jasow...@redhat.com; Liang, Cunming ; Xie, Yongji
; echau...@redhat.com; epere...@redhat.com;
amore...@redhat.com
Subject: RE: [RFC 00/27] Add VDUSE support to Vhost library


From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
Sent: Wednesday, 12 April 2023 17.28

Hi Ferruh,

On 4/12/23 13:33, Ferruh Yigit wrote:

On 3/31/2023 4:42 PM, Maxime Coquelin wrote:

This series introduces a new type of backend, VDUSE,
to the Vhost library.

VDUSE stands for vDPA device in Userspace, it enables
implementing a Virtio device in userspace and have it
attached to the Kernel vDPA bus.

Once attached to the vDPA bus, it can be used either by
Kernel Virtio drivers, like virtio-net in our case, via
the virtio-vdpa driver. Doing that, the device is visible
to the Kernel networking stack and is exposed to userspace
as a regular netdev.

It can also be exposed to userspace thanks to the
vhost-vdpa driver, via a vhost-vdpa chardev that can be
passed to QEMU or Virtio-user PMD.

While VDUSE support is already available in upstream
Kernel, a couple of patches are required to support
network device type:

https://gitlab.com/mcoquelin/linux/-/tree/vduse_networking_poc

In order to attach the created VDUSE device to the vDPA
bus, a recent iproute2 version containing the vdpa tool is
required.


Hi Maxime,

Is this a replacement to the existing DPDK vDPA framework? What is the
plan for long term?



No, this is not a replacement for DPDK vDPA framework.

We (Red Hat) don't have plans to support DPDK vDPA framework in our
products, but there are still contribution to DPDK vDPA by several vDPA
hardware vendors (Intel, Nvidia, Xilinx), so I don't think it is going
to be deprecated soon.


Ferruh's question made me curious...

I don't know anything about VDUSE or vDPA, and don't use any of it, so
consider me ignorant in this area.

Is VDUSE an alternative to the existing DPDK vDPA framework? What are the
differences, e.g. in which cases would an application developer (or user)
choose one or the other?


Maxime should give better explanation.. but let me just explain a bit.

Vendors have vDPA HW that support vDPA framework (most likely in their DPU/IPU
products). This work is introducing a way to emulate a SW vDPA device in
userspace (DPDK), and this SW vDPA device also supports vDPA framework.

So it's not an alternative to existing DPDK vDPA framework :)


Correct.

When using DPDK vDPA, the datapath of a Vhost-user port is offloaded to
a compatible physical NIC (i.e. a NIC that implements Virtio rings
support), the control path remains the same as a regular Vhost-user
port, i.e. it provides a Vhost-user unix socket to the application (like
QEMU or DPDK Virtio-user PMD).

When using Kernel vDPA, the datapath is also offloaded to a vDPA
compatible device, and the control path is managed by the vDPA bus.
It can either be consumed by a Kernel Virtio device (here Virtio-net)
when using Virtio-vDPA. In this case the device is exposed as a regular
netdev and, in the case of Kubernetes, can be used as primary interfaces
for the pods.
Or it can be exposed to user-space via Vhost-vDPA, a chardev that can be
seen as an alternative to Vhost-user sockets. In this case it can for
example be used by QEMU or DPDK Virtio-user PMD. In Kubernetes, it can
be used as a secondary interface.

Now comes VDUSE. VDUSE is a Kernel vDPA device, but instead of being a
physical device where the Virtio datapath is offloaded, the Virtio
datapath is offloaded to a user-space application. With this series, a
DPDK application, like OVS-DPDK for instance, can create VDUSE device
and expose them either as regular netdev when binding them to Kernel
Virtio-net driver via Virtio-vDPA, or as Vhost-vDPA interface to be
consumed by another userspace appliation like QEMU or DPDK application
using Virtio-user PMD. With this solution, OVS-DPDK could serve both
primary and secondary interfaces of Kubernetes pods.

I hope it clarifies, I will add these information in the cover-letter
for next revisions. Let me know if anything is still unclear.

I did a presentation at last DPDK summit [0], maybe the diagrams will 
help to clarify furthermore.


Regards,
Maxime


Thanks,
Chenbo



And if it is a better alternative, perhaps the documentation should
mention that it is recommended over DPDK vDPA. Just like we started
recommending alternatives to the KNI driver, so we could phase it out and
eventually get rid of it.



Regards,
Maxime




[0]: 
https://static.sched.com/hosted_files/dpdkuserspace22/9f/Open%20DPDK%20to%20containers%20networking%20with%20VDUSE.pdf




RE: [PATCH] dmadev: add tracepoints

2023-04-13 Thread Morten Brørup
> From: fengchengwen [mailto:fengcheng...@huawei.com]
> Sent: Thursday, 13 April 2023 08.30
> 
> On 2023/4/12 19:00, Morten Brørup wrote:
> >> From: Chengwen Feng [mailto:fengcheng...@huawei.com]
> >> Sent: Wednesday, 12 April 2023 04.48
> >>
> >> Add tracepoints at important APIs for tracing support.
> >>
> >> Signed-off-by: Chengwen Feng 
> >> ---
> >
> 
> ...
> 
> >> +)
> >> +
> >> +RTE_TRACE_POINT(
> >> +  rte_dma_trace_stats_get,
> >
> > This should be a fast path trace point.
> > For reference, ethdev considers rte_eth_stats_get() a fast path function.
> 
> Emm, I think it should discuss more, and make it clear.
> 
> The cryptodev and dmadev trace-points both make 'rte_xxx_trace_stats_get' as a
> slow path function.

Then those stats tracepoints should be fixed, so they behave like ethdev.

> And it mainly refer to the fast path API (means if a API is fast path then
> make it as a fast-path trace-points).

Dataplane functions must obviously be RTE_TRACE_POINT_FP. But some 
non-dataplane functions must also be RTE_TRACE_POINT_FP.

> 
> But the ethdev trace-points treats 'calls in loop function(such as
> rte_eth_trace_stats_get/rte_eth_trace_link_get/...)'
> as fast path trace-points.

Yes. Such "grey area" functions must use FP trace. Please refer to the 
Techboard decision to treat them as FP trace [1].

[1]: http://inbox.dpdk.org/dev/2325762.trqCLbgVIZ@thomas/

The techboard made this decision when trace was introduced to ethdev, and it 
seems that it was not caught in review when trace was added to cryptodev.

PS: The trace point macro names are unfortunate... Since RTE_TRACE_POINT_FP is 
not only for Fast Path functions, they should have been named RTE_TRACE_POINT 
and RTE_TRACE_POINT_SLOW instead of RTE_TRACE_POINT_FP and RTE_TRACE_POINT. But 
it is too late to change now.

> 
> >
> >> +  RTE_TRACE_POINT_ARGS(int16_t dev_id, uint16_t vchan,
> >> +   struct rte_dma_stats *stats, int ret),
> >> +  rte_trace_point_emit_i16(dev_id);
> >> +  rte_trace_point_emit_u16(vchan);
> >> +  rte_trace_point_emit_u64(stats->submitted);
> >> +  rte_trace_point_emit_u64(stats->completed);
> >> +  rte_trace_point_emit_u64(stats->errors);
> >> +  rte_trace_point_emit_int(ret);
> >> +)
> >> +
> 
> ...
> 
> >> diff --git a/lib/dmadev/version.map b/lib/dmadev/version.map
> >> index 7031d6b335..4ee1b3f74a 100644
> >> --- a/lib/dmadev/version.map
> >> +++ b/lib/dmadev/version.map
> >> @@ -1,6 +1,16 @@
> >>  EXPERIMENTAL {
> >>global:
> >>
> >> +  # added in 23.07
> >> +  __rte_dma_trace_burst_capacity;
> >> +  __rte_dma_trace_completed;
> >> +  __rte_dma_trace_completed_status;
> >> +  __rte_dma_trace_copy;
> >> +  __rte_dma_trace_copy_sg;
> >> +  __rte_dma_trace_fill;
> >> +  __rte_dma_trace_submit;
> >> +
> >
> > Intuitively, I would suppose that the 23.07 functions should be listed after
> the 21.11 functions, not before.
> 
> +1, will fix in v2
> 
> >
> >> +  # added in 21.11
> >
> > Good catch.
> >
> >>rte_dma_close;
> >>rte_dma_configure;
> >>rte_dma_count_avail;
> >> --
> >> 2.17.1
> >
> >
> > .
> >


Re: [PATCH] dmadev: add tracepoints

2023-04-13 Thread Bruce Richardson
On Thu, Apr 13, 2023 at 11:44:38AM +0800, fengchengwen wrote:
> On 2023/4/12 17:52, Bruce Richardson wrote:
> > On Wed, Apr 12, 2023 at 02:48:08AM +, Chengwen Feng wrote:
> >> Add tracepoints at important APIs for tracing support.
> >>
> >> Signed-off-by: Chengwen Feng 
> >> ---
> >>  lib/dmadev/meson.build   |   2 +-
> >>  lib/dmadev/rte_dmadev.c  |  39 ++--
> >>  lib/dmadev/rte_dmadev.h  |  56 ---
> >>  lib/dmadev/rte_dmadev_trace.h| 133 +++
> >>  lib/dmadev/rte_dmadev_trace_fp.h | 113 +++
> >>  lib/dmadev/rte_dmadev_trace_points.c |  59 
> >>  lib/dmadev/version.map   |  10 ++
> >>  7 files changed, 391 insertions(+), 21 deletions(-)
> >>  create mode 100644 lib/dmadev/rte_dmadev_trace.h
> >>  create mode 100644 lib/dmadev/rte_dmadev_trace_fp.h
> >>  create mode 100644 lib/dmadev/rte_dmadev_trace_points.c
> >>
> > For completeness, do you have any numbers for the performance impact (if
> > any) to the DMA dataplane APIs with this tracing added?
> 
> No, because:
> 
> The dataplane trace points was disable default (unless the 
> RTE_ENABLE_TRACE_FP is set),
> so there will no trace-points code default.
> 
> So I think it will not impact performance default.
> 
Right, I'd missed that bit. Thanks.


[Bug 1189] rte_acl_classify returning mismatch result

2023-04-13 Thread bugzilla
https://bugs.dpdk.org/show_bug.cgi?id=1189

David Marchand (david.march...@redhat.com) changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED
 CC||david.march...@redhat.com

--- Comment #26 from David Marchand (david.march...@redhat.com) ---
Given the status of this architecture port, there is nothing more to do about
this report.
Closing as WONTFIX.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: [PATCH v6 00/26] Net/SPNIC: support SPNIC into DPDK 22.03

2023-04-13 Thread Ferruh Yigit
On 2/18/2022 9:30 AM, Yanling Song wrote:
> On Sun, 13 Feb 2022 19:07:09 +0100
> Thomas Monjalon  wrote:
> 
>> 12/02/2022 15:01, Yanling Song:
>>> On Fri, 21 Jan 2022 10:22:10 +
>>> Ferruh Yigit  wrote:
>>>   
 On 1/21/2022 9:27 AM, Yanling Song wrote:  
> On Wed, 19 Jan 2022 16:56:52 +
> Ferruh Yigit  wrote:
> 
>> On 12/30/2021 6:08 AM, Yanling Song wrote:
>>> The patchsets introduce SPNIC driver for Ramaxel's SPNxx
>>> serial NIC cards into DPDK 22.03. Ramaxel Memory Technology
>>> is a company which supply a lot of electric products:
>>> storage, communication, PCB... SPNxxx is a serial PCIE
>>> interface NIC cards: SPN110: 2 PORTs *25G
>>> SPN120: 4 PORTs *25G
>>> SPN130: 2 PORTs *100G
>>>
>>
>> Hi Yanling,
>>
>> As far as I can see hnic (from Huawei) and this spnic drivers
>> are alike, what is the relation between these two?  
>
> It is hard to create a brand new driver from scratch, so we
> referenced to hinic driver when developing spnic.  

 That is OK, but based on the familiarity of the code you may
 consider keeping the original code Copyright, I didn't
 investigate in that level but cc'ed hinic maintainers for info.
 Also cc'ed Hemant for guidance.  
>>
>> What is the percentage of familiarity in the code?
>>
> Scanned by tools: There are 0.8k similar code.
> 
>>> Sorry for late reponse since it was Spring Festival and I was in
>>> vacation, just back to work.
>>>
>>> Hemant gave the guidance already, but we do not want to keep another
>>> company's copyright in our code.
>>> How should we modify code so that the
>>> code meet DPDK's requirment and can be accepted with our copyright
>>> only?   
>>
>> If you don't want to keep a copyright, don't copy the code.
>>
> Got it. We will modify the code to meet the requirement of community
> and upstream it again. Since the change is great, I'm afraid that the
> new code maybe cannot meet the schedule of 22.03.
> 

Hi Yanling,

What is the status of the driver? Will there be a new version?



[PATCH] net/ice: DCF adds default RSS

2023-04-13 Thread Mingjin Ye
When dcf and iavf ports are used together, the default configuration of
ipv4[6] rss for dcf ports is lost.

This patch adds RSS configuration to the dcf port. Any kernel PF-enabled
default RSS will be disabled at initialization.

In addition, the default RSS will be configured based on
rte_eth_rss_conf->rss_hf. Currently supported default rss_type:
ipv4[6], ipv4[6]_udp, ipv4[6]_tcp, ipv4[6]_sctp.

Fixes: 79b1f7ab462d ("net/ice: support RSS RETA configuration in DCF mode")
Fixes: 7564d5509611 ("net/ice: add DCF hardware initialization")
Fixes: 3a6bfc37eaf4 ("net/ice: support QoS config VF bandwidth in DCF")
Fixes: 3220d865382c ("net/ice: init RSS during DCF start")
Cc: sta...@dpdk.org

Signed-off-by: Mingjin Ye 
---
 drivers/net/ice/ice_dcf.c| 259 ++-
 drivers/net/ice/ice_dcf.h|   4 +
 drivers/net/ice/ice_dcf_ethdev.c |  24 ++-
 3 files changed, 285 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ice/ice_dcf.c b/drivers/net/ice/ice_dcf.c
index 1c3d22ae0f..4575d831e1 100644
--- a/drivers/net/ice/ice_dcf.c
+++ b/drivers/net/ice/ice_dcf.c
@@ -36,6 +36,130 @@
(sizeof(struct virtchnl_vf_resource) +  \
IAVF_MAX_VF_VSI * sizeof(struct virtchnl_vsi_resource))
 
+#define FIELD_SELECTOR(proto_hdr_field) \
+   (1UL << ((proto_hdr_field) & PROTO_HDR_FIELD_MASK))
+#define BUFF_NOUSED0
+
+#define proto_hdr_eth { \
+   VIRTCHNL_PROTO_HDR_ETH, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_ETH_SRC) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_ETH_DST), {BUFF_NOUSED} }
+
+#define proto_hdr_svlan { \
+   VIRTCHNL_PROTO_HDR_S_VLAN, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_S_VLAN_ID), {BUFF_NOUSED} }
+
+#define proto_hdr_cvlan { \
+   VIRTCHNL_PROTO_HDR_C_VLAN, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_C_VLAN_ID), {BUFF_NOUSED} }
+
+#define proto_hdr_ipv4 { \
+   VIRTCHNL_PROTO_HDR_IPV4, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV4_SRC) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV4_DST), {BUFF_NOUSED} }
+
+#define proto_hdr_ipv4_with_prot { \
+   VIRTCHNL_PROTO_HDR_IPV4, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV4_SRC) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV4_DST) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV4_PROT), {BUFF_NOUSED} }
+
+#define proto_hdr_ipv6 { \
+   VIRTCHNL_PROTO_HDR_IPV6, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_SRC) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_DST), {BUFF_NOUSED} }
+
+#define proto_hdr_ipv6_frag { \
+   VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG_PKID), {BUFF_NOUSED} }
+
+#define proto_hdr_ipv6_with_prot { \
+   VIRTCHNL_PROTO_HDR_IPV6, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_SRC) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_DST) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PROT), {BUFF_NOUSED} }
+
+#define proto_hdr_udp { \
+   VIRTCHNL_PROTO_HDR_UDP, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_UDP_SRC_PORT) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_UDP_DST_PORT), {BUFF_NOUSED} }
+
+#define proto_hdr_tcp { \
+   VIRTCHNL_PROTO_HDR_TCP, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_TCP_SRC_PORT) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_TCP_DST_PORT), {BUFF_NOUSED} }
+
+#define proto_hdr_sctp { \
+   VIRTCHNL_PROTO_HDR_SCTP, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_SCTP_SRC_PORT) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_SCTP_DST_PORT), {BUFF_NOUSED} }
+
+#define proto_hdr_esp { \
+   VIRTCHNL_PROTO_HDR_ESP, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_ESP_SPI), {BUFF_NOUSED} }
+
+#define proto_hdr_ah { \
+   VIRTCHNL_PROTO_HDR_AH, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_AH_SPI), {BUFF_NOUSED} }
+
+#define proto_hdr_l2tpv3 { \
+   VIRTCHNL_PROTO_HDR_L2TPV3, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_L2TPV3_SESS_ID), {BUFF_NOUSED} }
+
+#define proto_hdr_pfcp { \
+   VIRTCHNL_PROTO_HDR_PFCP, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_PFCP_SEID), {BUFF_NOUSED} }
+
+#define proto_hdr_gtpc { \
+   VIRTCHNL_PROTO_HDR_GTPC, 0, {BUFF_NOUSED} }
+
+#define proto_hdr_ecpri { \
+   VIRTCHNL_PROTO_HDR_ECPRI, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_ECPRI_PC_RTC_ID), {BUFF_NOUSED} }
+
+#define proto_hdr_l2tpv2 { \
+   VIRTCHNL_PROTO_HDR_L2TPV2, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_L2TPV2_SESS_ID) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_L2TPV2_LEN_SESS_ID), {BUFF_NOUSED} }
+
+#define proto_hdr_ppp { \
+   VIRTCHNL_PROTO_HDR_PPP, 0, {BUFF_NOUSED} }
+
+#define TUNNEL_LEVEL_OUTER 0
+#define TUNNEL_LEVEL_INNER 1
+
+struct virtchnl_proto_hdrs ice_dcf_inner_ipv4_tmplt = {
+   TUNNEL_LEVEL_INNER, 1, {{proto_hdr_ipv4}}
+};
+
+struct virtchnl_proto_hdrs ice_dcf_inner_ipv4_udp_tmplt = {
+   TUNNEL_LEVEL_INNER, 2, {{proto_hdr_ipv4_with_prot, proto_hdr_udp}}
+};
+
+struct virtchnl_proto_hdrs ice_dcf_inner_ipv4_tcp_tmplt = {
+   TUNNEL_LEVEL_INNER, 2, {{proto

RE: [PATCH] eal: choose IOVA mode according to compilation flags

2023-04-13 Thread Slava Ovsiienko
> -Original Message-
> From: Morten Brørup 
> Sent: среда, 12 апреля 2023 г. 22:12
> To: Slava Ovsiienko ; dev@dpdk.org
> Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) ;
> david.march...@redhat.com
> Subject: RE: [PATCH] eal: choose IOVA mode according to compilation flags
> 
> > From: Viacheslav Ovsiienko [mailto:viachesl...@nvidia.com]
> > Sent: Wednesday, 12 April 2023 19.20
> >
> > The DPDK can be compiled to be run in IOVA VA mode with
> > 'enable_iova_as_pa=false' meson option. If there is no explicit EAL
> > --iova-mode parameter specified in the command line the rte_eal_init()
> > tried to deduce  VA or PA mode without taking into account the above
> > mentioned compile time option, resulting into initialization failure.
> >
> > Signed-off-by: Viacheslav Ovsiienko 
> > ---
> >  lib/eal/linux/eal.c | 5 -
> 
> This patch is close to being a bugfix. Good catch!
> 
> You could also consider another patch, logging warnings in
> rte_bus_get_iommu_class() [1] for the busses that want IOVA as PA when
> !RTE_IOVA_IN_MBUF.

Yes, looks reasonable, thank you.
Let me gather the comments first, then will update the patch.

> 
> [1]:
> https://elixir.bootlin.com/dpdk/v23.03/source/lib/eal/common/eal_common_
> bus.c#L224
> 
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c index
> > c37868b7f0..4481bc4ad8 100644
> > --- a/lib/eal/linux/eal.c
> > +++ b/lib/eal/linux/eal.c
> > @@ -1080,7 +1080,10 @@ rte_eal_init(int argc, char **argv)
> > if (iova_mode == RTE_IOVA_DC) {
> > RTE_LOG(DEBUG, EAL, "Buses did not request a
> specific IOVA
> > mode.\n");
> >
> > -   if (!phys_addrs) {
> > +   if (!RTE_IOVA_IN_MBUF) {
> > +   iova_mode = RTE_IOVA_VA;
> > +   RTE_LOG(DEBUG, EAL, "IOVA VA mode is
> forced by
> > build option.\n");
> 
> Minor detail regarding conventions: "IOVA VA " -> "IOVA as VA"
> 
> > +   } else if (!phys_addrs) {
> > /* if we have no access to physical addresses,
> >  * pick IOVA as VA mode.
> >  */
> > --
> > 2.18.1
> 
> Reviewed-by: Morten Brørup 



[PATCH 00/18] update idpf shared code

2023-04-13 Thread Wenjing Qiao
This patch set updates idpf shared code.

Wenjing Qiao (18):
  common/idpf: support flow subscription
  common/idpf: fix ctlq message send and receive
  common/idpf: fix ITR register definitions for AVF
  common/idpf: remove qregion struct variables
  common/idpf: move OEM capability to the last bit
  common/idpf: modify SSO/LSO and ITR fields
  common/idpf: add virtchnl2 error codes
  common/idpf: swap opcode and retval location in msg struct
  common/idpf: fix idpf_send_msg_to_cp prototypes
  common/idpf: fix memory leaks on ctrlq functions
  common/idpf: allocate static buffer at initialization
  common/idpf: add SyncE support over VF
  common/idpf: replace MAKEMASK to IDPF_M
  common/idpf: add GNSS support over VF
  common/idpf: add/delete queue groups commands
  common/idpf: add func to clean all DESCs on controlq
  common/idpf: fix cannot understand warnings
  common/idpf: update license and README

 .mailmap  |   8 +
 drivers/common/idpf/base/README   |   4 +-
 drivers/common/idpf/base/idpf_alloc.h |   2 +-
 drivers/common/idpf/base/idpf_common.c|  42 +-
 drivers/common/idpf/base/idpf_controlq.c  |  76 +-
 drivers/common/idpf/base/idpf_controlq.h  |   5 +-
 drivers/common/idpf/base/idpf_controlq_api.h  |  12 +-
 .../common/idpf/base/idpf_controlq_setup.c|   2 +-
 drivers/common/idpf/base/idpf_devids.h|   2 +-
 drivers/common/idpf/base/idpf_lan_pf_regs.h   |  37 +-
 drivers/common/idpf/base/idpf_lan_txrx.h  |  48 +-
 drivers/common/idpf/base/idpf_lan_vf_regs.h   |  35 +-
 drivers/common/idpf/base/idpf_osdep.h |   4 +-
 drivers/common/idpf/base/idpf_prototype.h |   4 +-
 drivers/common/idpf/base/idpf_type.h  |   4 +-
 drivers/common/idpf/base/meson.build  |   2 +-
 drivers/common/idpf/base/siov_regs.h  |   2 +-
 drivers/common/idpf/base/virtchnl.h   | 825 +-
 drivers/common/idpf/base/virtchnl2.h  | 282 +-
 drivers/common/idpf/base/virtchnl2_lan_desc.h |  30 +-
 .../common/idpf/base/virtchnl_inline_ipsec.h  |   2 +-
 21 files changed, 1252 insertions(+), 176 deletions(-)

-- 
2.25.1



[PATCH 01/18] common/idpf: support flow subscription

2023-04-13 Thread Wenjing Qiao
VF is able to subscribe a flow from PF by VIRTCHNL_FLOW_SUBSCRIBE.

PF is expected to offload a rule to hardware which will redirect
the packet that matching the required pattern to this VF.

Only a flow with dst mac address as PF's mac address can be subscribed.

VIRTCHNL_VF_OFFLOAD_FSUB_PF is used for Flow subscription capability
negotiation and only a trusted VF can be granted with this capability.

A flow can be unsubscribed by VIRTCHNL_FLOW_UNSUBSCRIBE.

Signed-off-by: Jie Wang 
Signed-off-by: Qi Zhang 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/virtchnl.h | 102 +++-
 1 file changed, 99 insertions(+), 3 deletions(-)

diff --git a/drivers/common/idpf/base/virtchnl.h 
b/drivers/common/idpf/base/virtchnl.h
index ea798e3971..3008802c4a 100644
--- a/drivers/common/idpf/base/virtchnl.h
+++ b/drivers/common/idpf/base/virtchnl.h
@@ -182,6 +182,8 @@ enum virtchnl_ops {
VIRTCHNL_OP_MAP_QUEUE_VECTOR = 111,
VIRTCHNL_OP_CONFIG_QUEUE_BW = 112,
VIRTCHNL_OP_CONFIG_QUANTA = 113,
+   VIRTCHNL_OP_FLOW_SUBSCRIBE = 114,
+   VIRTCHNL_OP_FLOW_UNSUBSCRIBE = 115,
VIRTCHNL_OP_MAX,
 };
 
@@ -298,6 +300,10 @@ static inline const char *virtchnl_op_str(enum 
virtchnl_ops v_opcode)
return "VIRTCHNL_OP_DISABLE_QUEUES_V2";
case VIRTCHNL_OP_MAP_QUEUE_VECTOR:
return "VIRTCHNL_OP_MAP_QUEUE_VECTOR";
+   case VIRTCHNL_OP_FLOW_SUBSCRIBE:
+   return "VIRTCHNL_OP_FLOW_SUBSCRIBE";
+   case VIRTCHNL_OP_FLOW_UNSUBSCRIBE:
+   return "VIRTCHNL_OP_FLOW_UNSUBSCRIBE";
case VIRTCHNL_OP_MAX:
return "VIRTCHNL_OP_MAX";
default:
@@ -434,6 +440,7 @@ VIRTCHNL_CHECK_STRUCT_LEN(16, virtchnl_vsi_resource);
/* BIT(8) is reserved */
 #define VIRTCHNL_VF_LARGE_NUM_QPAIRS   BIT(9)
 #define VIRTCHNL_VF_OFFLOAD_CRCBIT(10)
+#define VIRTCHNL_VF_OFFLOAD_FSUB_PFBIT(14)
 #define VIRTCHNL_VF_OFFLOAD_VLAN_V2BIT(15)
 #define VIRTCHNL_VF_OFFLOAD_VLAN   BIT(16)
 #define VIRTCHNL_VF_OFFLOAD_RX_POLLING BIT(17)
@@ -1451,6 +1458,7 @@ enum virtchnl_vfr_states {
 };
 
 #define VIRTCHNL_MAX_NUM_PROTO_HDRS32
+#define VIRTCHNL_MAX_NUM_PROTO_HDRS_W_MSK 16
 #define VIRTCHNL_MAX_SIZE_RAW_PACKET   1024
 #define PROTO_HDR_SHIFT5
 #define PROTO_HDR_FIELD_START(proto_hdr_type) \
@@ -1643,6 +1651,22 @@ struct virtchnl_proto_hdr {
 
 VIRTCHNL_CHECK_STRUCT_LEN(72, virtchnl_proto_hdr);
 
+struct virtchnl_proto_hdr_w_msk {
+   /* see enum virtchnl_proto_hdr_type */
+   s32 type;
+   u32 pad;
+   /**
+* binary buffer in network order for specific header type.
+* For example, if type = VIRTCHNL_PROTO_HDR_IPV4, a IPv4
+* header is expected to be copied into the buffer.
+*/
+   u8 buffer_spec[64];
+   /* binary buffer for bit-mask applied to specific header type */
+   u8 buffer_mask[64];
+};
+
+VIRTCHNL_CHECK_STRUCT_LEN(136, virtchnl_proto_hdr_w_msk);
+
 struct virtchnl_proto_hdrs {
u8 tunnel_level;
/**
@@ -1655,12 +1679,18 @@ struct virtchnl_proto_hdrs {
 */
int count;
/**
-* number of proto layers, must < VIRTCHNL_MAX_NUM_PROTO_HDRS
-* must be 0 for a raw packet request.
+* count must <=
+* VIRTCHNL_MAX_NUM_PROTO_HDRS + VIRTCHNL_MAX_NUM_PROTO_HDRS_W_MSK
+* count = 0 :  select raw
+* 1 < count <= VIRTCHNL_MAX_NUM_PROTO_HDRS :   select proto_hdr
+* count > VIRTCHNL_MAX_NUM_PROTO_HDRS :select proto_hdr_w_msk
+* last valid index = count - VIRTCHNL_MAX_NUM_PROTO_HDRS
 */
union {
struct virtchnl_proto_hdr
proto_hdr[VIRTCHNL_MAX_NUM_PROTO_HDRS];
+   struct virtchnl_proto_hdr_w_msk
+   proto_hdr_w_msk[VIRTCHNL_MAX_NUM_PROTO_HDRS_W_MSK];
struct {
u16 pkt_len;
u8 spec[VIRTCHNL_MAX_SIZE_RAW_PACKET];
@@ -1681,7 +1711,7 @@ struct virtchnl_rss_cfg {
 
 VIRTCHNL_CHECK_STRUCT_LEN(2444, virtchnl_rss_cfg);
 
-/* action configuration for FDIR */
+/* action configuration for FDIR and FSUB */
 struct virtchnl_filter_action {
/* see enum virtchnl_action type */
s32 type;
@@ -1799,6 +1829,66 @@ struct virtchnl_fdir_del {
 
 VIRTCHNL_CHECK_STRUCT_LEN(12, virtchnl_fdir_del);
 
+/* Status returned to VF after VF requests FSUB commands
+ * VIRTCHNL_FSUB_SUCCESS
+ * VF FLOW related request is successfully done by PF
+ * The request can be OP_FLOW_SUBSCRIBE/UNSUBSCRIBE.
+ *
+ * VIRTCHNL_FSUB_FAILURE_RULE_NORESOURCE
+ * OP_FLOW_SUBSCRIBE request is failed due to no Hardware resource.
+ *
+ * VIRTCHNL_FSUB_FAILURE_RULE_EXIST
+ * OP_FLOW_SUBSCRIBE request is failed due to the rule is already existed.
+ *
+ * VIRTCHNL_FSUB_FAILURE_RULE_NONEXIST
+ * OP_FLOW_UNSUBSCRIBE reque

[PATCH 02/18] common/idpf: fix ctlq message send and receive

2023-04-13 Thread Wenjing Qiao
Fixes the ctlq send and receive functions to not cast the cookie field
to a u64 before programming. By doing a cast, it can cause endianness
issues as LE will swap the lower 32 and higher 32 bits whereas BE will
not. By treating this field as two 32 bit values, both BE and LE will
place the retval and opcode in the correct location.

Since this field is now being treated as two 32 bit values, the cfg.data
section must also be split into a data high and data low. Macros to
easily pack and read these fields have also been added.

Fixes: fb4ac04e9bfa ("common/idpf: introduce common library")
Cc: sta...@dpdk.org

Signed-off-by: Charles Stoll 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/idpf_controlq.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/common/idpf/base/idpf_controlq.c 
b/drivers/common/idpf/base/idpf_controlq.c
index 3af81e5a64..8e4d3ee54f 100644
--- a/drivers/common/idpf/base/idpf_controlq.c
+++ b/drivers/common/idpf/base/idpf_controlq.c
@@ -311,18 +311,14 @@ int idpf_ctlq_send(struct idpf_hw *hw, struct 
idpf_ctlq_info *cq,
 
for (i = 0; i < num_q_msg; i++) {
struct idpf_ctlq_msg *msg = &q_msg[i];
-   u64 msg_cookie;
 
desc = IDPF_CTLQ_DESC(cq, cq->next_to_use);
 
desc->opcode = CPU_TO_LE16(msg->opcode);
desc->pfid_vfid = CPU_TO_LE16(msg->func_id);
 
-   msg_cookie = *(u64 *)&msg->cookie;
-   desc->cookie_high =
-   CPU_TO_LE32(IDPF_HI_DWORD(msg_cookie));
-   desc->cookie_low =
-   CPU_TO_LE32(IDPF_LO_DWORD(msg_cookie));
+   desc->cookie_high = CPU_TO_LE32(msg->cookie.mbx.chnl_opcode);
+   desc->cookie_low = CPU_TO_LE32(msg->cookie.mbx.chnl_retval);
 
desc->flags = CPU_TO_LE16((msg->host_id & IDPF_HOST_ID_MASK) <<
  IDPF_CTLQ_FLAG_HOST_ID_S);
@@ -620,8 +616,6 @@ int idpf_ctlq_recv(struct idpf_ctlq_info *cq, u16 
*num_q_msg,
num_to_clean = *num_q_msg;
 
for (i = 0; i < num_to_clean; i++) {
-   u64 msg_cookie;
-
/* Fetch next descriptor and check if marked as done */
desc = IDPF_CTLQ_DESC(cq, ntc);
flags = LE16_TO_CPU(desc->flags);
@@ -639,10 +633,8 @@ int idpf_ctlq_recv(struct idpf_ctlq_info *cq, u16 
*num_q_msg,
if (flags & IDPF_CTLQ_FLAG_ERR)
ret_code = -EBADMSG;
 
-   msg_cookie = (u64)LE32_TO_CPU(desc->cookie_high) << 32;
-   msg_cookie |= (u64)LE32_TO_CPU(desc->cookie_low);
-   idpf_memcpy(&q_msg[i].cookie, &msg_cookie, sizeof(u64),
-   IDPF_NONDMA_TO_NONDMA);
+   q_msg[i].cookie.mbx.chnl_opcode = 
LE32_TO_CPU(desc->cookie_high);
+   q_msg[i].cookie.mbx.chnl_retval = LE32_TO_CPU(desc->cookie_low);
 
q_msg[i].opcode = LE16_TO_CPU(desc->opcode);
q_msg[i].data_len = LE16_TO_CPU(desc->datalen);
-- 
2.25.1



[PATCH 03/18] common/idpf: fix ITR register definitions for AVF

2023-04-13 Thread Wenjing Qiao
Fix ITR register definitions for AVF1.0 and AVF2.0

Fixes: fb4ac04e9bfa ("common/idpf: introduce common library")
Cc: sta...@dpdk.org

Signed-off-by: Priyalee Kushwaha 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/idpf_lan_pf_regs.h |  9 +++--
 drivers/common/idpf/base/idpf_lan_vf_regs.h | 17 -
 2 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/common/idpf/base/idpf_lan_pf_regs.h 
b/drivers/common/idpf/base/idpf_lan_pf_regs.h
index 3df2347bd7..7f731ec3d6 100644
--- a/drivers/common/idpf/base/idpf_lan_pf_regs.h
+++ b/drivers/common/idpf/base/idpf_lan_pf_regs.h
@@ -77,8 +77,13 @@
 #define PF_GLINT_DYN_CTL_WB_ON_ITR_M   BIT(PF_GLINT_DYN_CTL_WB_ON_ITR_S)
 #define PF_GLINT_DYN_CTL_INTENA_MSK_S  31
 #define PF_GLINT_DYN_CTL_INTENA_MSK_M  BIT(PF_GLINT_DYN_CTL_INTENA_MSK_S)
-#define PF_GLINT_ITR_V2(_i, _reg_start) (((_i) * 4) + (_reg_start))
-#define PF_GLINT_ITR(_i, _INT) (PF_GLINT_BASE + (((_i) + 1) * 4) + ((_INT) * 
0x1000))
+/* _ITR is ITR index, _INT is interrupt index, _itrn_indx_spacing is
+ * spacing b/w itrn registers of the same vector.
+ */
+#define PF_GLINT_ITR_ADDR(_ITR, _reg_start, _itrn_indx_spacing) \
+   ((_reg_start) + (((_ITR)) * (_itrn_indx_spacing)))
+/* For PF, itrn_indx_spacing is 4 and itrn_reg_spacing is 0x1000 */
+#define PF_GLINT_ITR(_ITR, _INT) (PF_GLINT_BASE + (((_ITR) + 1) * 4) + ((_INT) 
* 0x1000))
 #define PF_GLINT_ITR_MAX_INDEX 2
 #define PF_GLINT_ITR_INTERVAL_S0
 #define PF_GLINT_ITR_INTERVAL_MMAKEMASK(0xFFF, 
PF_GLINT_ITR_INTERVAL_S)
diff --git a/drivers/common/idpf/base/idpf_lan_vf_regs.h 
b/drivers/common/idpf/base/idpf_lan_vf_regs.h
index 9cd4f757d9..13c5c5a7da 100644
--- a/drivers/common/idpf/base/idpf_lan_vf_regs.h
+++ b/drivers/common/idpf/base/idpf_lan_vf_regs.h
@@ -90,11 +90,18 @@
 #define VF_INT_DYN_CTLN_WB_ON_ITR_MBIT(VF_INT_DYN_CTLN_WB_ON_ITR_S)
 #define VF_INT_DYN_CTLN_INTENA_MSK_S   31
 #define VF_INT_DYN_CTLN_INTENA_MSK_M   BIT(VF_INT_DYN_CTLN_INTENA_MSK_S)
-#define VF_INT_ITR0(_i)(0x4C00 + ((_i) * 4))
-#define VF_INT_ITRN_V2(_i, _reg_start) ((_reg_start) + (((_i)) * 4))
-#define VF_INT_ITRN(_i, _INT)  (0x2800 + ((_i) * 4) + ((_INT) * 
0x40))
-#define VF_INT_ITRN_64(_i, _INT)   (0x2C00 + ((_i) * 4) + ((_INT) * 
0x100))
-#define VF_INT_ITRN_2K(_i, _INT)   (0x00072000 + ((_i) * 4) + ((_INT) * 
0x100))
+/* _ITR is ITR index, _INT is interrupt index, _itrn_indx_spacing is spacing
+ * b/w itrn registers of the same vector
+ */
+#define VF_INT_ITR0(_ITR)  (0x4C00 + ((_ITR) * 4))
+#define VF_INT_ITRN_ADDR(_ITR, _reg_start, _itrn_indx_spacing) \
+((_reg_start) + (((_ITR)) * (_itrn_indx_spacing)))
+/* For VF with 16 vector support, itrn_reg_spacing is 0x4 and 
itrn_indx_spacing is 0x40 */
+#define VF_INT_ITRN(_INT, _ITR)(0x2800 + ((_INT) * 4) + ((_ITR) * 
0x40))
+/* For VF with 64 vector support, itrn_reg_spacing is 0x4 and 
itrn_indx_spacing is 0x100 */
+#define VF_INT_ITRN_64(_INT, _ITR) (0x2C00 + ((_INT) * 4) + ((_ITR) * 
0x100))
+/* For VF with 2k vector support, itrn_reg_spacing is 0x4 and 
itrn_indx_spacing is 0x2000 */
+#define VF_INT_ITRN_2K(_INT, _ITR) (0x00072000 + ((_INT) * 4) + ((_ITR) * 
0x2000))
 #define VF_INT_ITRN_MAX_INDEX  2
 #define VF_INT_ITRN_INTERVAL_S 0
 #define VF_INT_ITRN_INTERVAL_M MAKEMASK(0xFFF, VF_INT_ITRN_INTERVAL_S)
-- 
2.25.1



[PATCH 04/18] common/idpf: remove qregion struct variables

2023-04-13 Thread Wenjing Qiao
Existing qregion variables are not well defined and cannot be
used for TC related stuff. Remove them from create vport
struct and add those freed bytes to a new reserved field.

Add appropriate comments on how to use the dynctl and itrn
register spacing variables.

Only VF reference was used in get version comments where it
should be PF/VF.

Note: qregion variables will be added once the requirements
are defined properly.

Signed-off-by: Pavan Kumar Linga 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/virtchnl2.h | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/common/idpf/base/virtchnl2.h 
b/drivers/common/idpf/base/virtchnl2.h
index d496f2388e..5c01734b65 100644
--- a/drivers/common/idpf/base/virtchnl2.h
+++ b/drivers/common/idpf/base/virtchnl2.h
@@ -426,13 +426,13 @@
 
 
 /* VIRTCHNL2_OP_VERSION
- * VF posts its version number to the CP. CP responds with its version number
+ * PF/VF posts its version number to the CP. CP responds with its version 
number
  * in the same format, along with a return code.
- * If there is a major version mismatch, then the VF cannot operate.
- * If there is a minor version mismatch, then the VF can operate but should
+ * If there is a major version mismatch, then the PF/VF cannot operate.
+ * If there is a minor version mismatch, then the PF/VF can operate but should
  * add a warning to the system log.
  *
- * This version opcode  MUST always be specified as == 1, regardless of other
+ * This version opcode MUST always be specified as == 1, regardless of other
  * changes in the API. The CP must always respond to this message without
  * error regardless of version mismatch.
  */
@@ -598,11 +598,7 @@ struct virtchnl2_create_vport {
/* see VIRTCHNL2_TX_DESC_IDS definitions */
__le64 tx_desc_ids;
 
-#define MAX_Q_REGIONS 16
-   __le32 max_qs_per_qregion[MAX_Q_REGIONS];
-   __le32 qregion_total_qs;
-   __le16 qregion_type;
-   __le16 pad2;
+   u8 reserved1[72];
 
/* see VIRTCHNL2_RSS_ALGORITHM definitions */
__le32 rss_algorithm;
@@ -665,9 +661,7 @@ struct virtchnl2_txq_info {
 */
__le16 peer_rx_queue_id;
 
-   /* value ranges from 0 to 15 */
-   __le16 qregion_id;
-   u8 pad[2];
+   u8 pad[4];
 
/* Egress pasid is used for SIOV use case */
__le32 egress_pasid;
@@ -734,10 +728,7 @@ struct virtchnl2_rxq_info {
 * if this field is set
 */
u8 bufq2_ena;
-   u8 pad2;
-
-   /* value ranges from 0 to 15 */
-   __le16 qregion_id;
+   u8 pad2[3];
 
/* Ingress pasid is used for SIOV use case */
__le32 ingress_pasid;
@@ -801,9 +792,13 @@ struct virtchnl2_vector_chunk {
 * interrupt indices without modifying the state of the interrupt.
 */
__le32 dynctl_reg_start;
+   /* register spacing to find the next dynctl and itrn register offset
+* from the provided dynctl_reg_start and itrn_reg_start respectively
+*/
__le32 dynctl_reg_spacing;
 
__le32 itrn_reg_start;
+   /* register spacing to find the individual itrn register where n=0..2 */
__le32 itrn_reg_spacing;
u8 reserved[8];
 };
-- 
2.25.1



[PATCH 05/18] common/idpf: move OEM capability to the last bit

2023-04-13 Thread Wenjing Qiao
Move the existing OEM capability in VIRTCHNL2_OTHER_CAPS to
the last bit. This should not break any backward compatibility
as it is not used yet.

And VIRTCHNL2_MEV_DEVICE is no longer upstreamed.

Signed-off-by: Pavan Kumar Linga 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/virtchnl2.h | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/common/idpf/base/virtchnl2.h 
b/drivers/common/idpf/base/virtchnl2.h
index 5c01734b65..32d8fe8c06 100644
--- a/drivers/common/idpf/base/virtchnl2.h
+++ b/drivers/common/idpf/base/virtchnl2.h
@@ -208,11 +208,8 @@
 #define VIRTCHNL2_CAP_RX_FLEX_DESC BIT(17)
 #define VIRTCHNL2_CAP_PTYPEBIT(18)
 #define VIRTCHNL2_CAP_LOOPBACK BIT(19)
-#define VIRTCHNL2_CAP_OEM  BIT(20)
-
-/* VIRTCHNL2_DEVICE_TYPE */
-/* underlying device type */
-#define VIRTCHNL2_MEV_DEVICE   0
+/* this must be the last capability */
+#define VIRTCHNL2_CAP_OEM  BIT(63)
 
 /* VIRTCHNL2_TXQ_SCHED_MODE
  * Transmit Queue Scheduling Modes - Queue mode is the legacy mode i.e. inorder
-- 
2.25.1



[PATCH 06/18] common/idpf: modify SSO/LSO and ITR fields

2023-04-13 Thread Wenjing Qiao
- Driver assumes minimum packet length for sso as 17 bytes
but it should be a negotiated value from CP.
- Similarly, the number of header buffers for lso that are
supported by the device should also be a negotiated value.

Add min_sso_packet_len, max_hdr_buf_per_lso to address the
above.

Also, the existing 'itrn_reg_spacing' should be used for
spacing between ITRn registers of 2 consecutive vectors and
add a new spacing field to get the spacing between ITR
registers of the same vector.

- ITR_IDX 2 is not used in the current code. Bring it back
if there exists any use case in the future.
- NO_ITR is not really a register index and it is used only
in the IDPF base code, so virtchnl support is not required for
that
- itr_idx_map is also not used as by default driver assumes
at the minimum 2 ITRs are supported by the device. If any
additional ITRs are also supported, then those should be
negotiated.

Remove all the above said fields and mark them as reserved.

Signed-off-by: Pavan Kumar Linga 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/virtchnl2.h | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/common/idpf/base/virtchnl2.h 
b/drivers/common/idpf/base/virtchnl2.h
index 32d8fe8c06..edf3f200b3 100644
--- a/drivers/common/idpf/base/virtchnl2.h
+++ b/drivers/common/idpf/base/virtchnl2.h
@@ -289,8 +289,6 @@
  */
 #define VIRTCHNL2_ITR_IDX_00
 #define VIRTCHNL2_ITR_IDX_11
-#define VIRTCHNL2_ITR_IDX_22
-#define VIRTCHNL2_ITR_IDX_NO_ITR   3
 
 /* VIRTCHNL2_VECTOR_LIMITS
  * Since PF/VF messages are limited by __le16 size, precalculate the maximum
@@ -510,9 +508,7 @@ struct virtchnl2_get_capabilities {
 */
u8 max_sg_bufs_per_tx_pkt;
 
-   /* see VIRTCHNL2_ITR_IDX definition */
-   u8 itr_idx_map;
-
+   u8 reserved1;
__le16 pad1;
 
/* version of Control Plane that is running */
@@ -521,7 +517,12 @@ struct virtchnl2_get_capabilities {
/* see VIRTCHNL2_DEVICE_TYPE definitions */
__le32 device_type;
 
-   u8 reserved[12];
+   /* min packet length supported by device for single segment offload */
+   u8 min_sso_packet_len;
+   /* max number of header buffers that can be used for an LSO */
+   u8 max_hdr_buf_per_lso;
+
+   u8 reserved[10];
 };
 
 VIRTCHNL2_CHECK_STRUCT_LEN(80, virtchnl2_get_capabilities);
@@ -789,15 +790,17 @@ struct virtchnl2_vector_chunk {
 * interrupt indices without modifying the state of the interrupt.
 */
__le32 dynctl_reg_start;
-   /* register spacing to find the next dynctl and itrn register offset
-* from the provided dynctl_reg_start and itrn_reg_start respectively
-*/
+   /* register spacing between dynctl registers of 2 consecutive vectors */
__le32 dynctl_reg_spacing;
 
__le32 itrn_reg_start;
-   /* register spacing to find the individual itrn register where n=0..2 */
+   /* register spacing between itrn registers of 2 consecutive vectors */
__le32 itrn_reg_spacing;
-   u8 reserved[8];
+   /* register spacing between itrn registers of the same vector
+* where n=0..2
+*/
+   __le32 itrn_index_spacing;
+   u8 reserved[4];
 };
 
 VIRTCHNL2_CHECK_STRUCT_LEN(32, virtchnl2_vector_chunk);
-- 
2.25.1



[PATCH 07/18] common/idpf: add virtchnl2 error codes

2023-04-13 Thread Wenjing Qiao
Virtchnl2 error codes are required for meaningful failure
information sharing between CP and PF/VF. Introduce the
necessary error codes.

New error codes were introduced removing the old ones. So
the references to the old one should be modified to avoid
CI build failures.

Use appropriate error codes wherever necessary.

Signed-off-by: Kazatsker Kirill 
Signed-off-by: Pavan Kumar Linga 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/virtchnl2.h | 40 +---
 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/common/idpf/base/virtchnl2.h 
b/drivers/common/idpf/base/virtchnl2.h
index edf3f200b3..415e90358e 100644
--- a/drivers/common/idpf/base/virtchnl2.h
+++ b/drivers/common/idpf/base/virtchnl2.h
@@ -12,14 +12,34 @@
 
 #include "virtchnl2_lan_desc.h"
 
-/* Error Codes
- * Note that many older versions of various iAVF drivers convert the reported
- * status code directly into an iavf_status enumeration. For this reason, it
- * is important that the values of these enumerations line up.
- */
-#defineVIRTCHNL2_STATUS_SUCCESS0
-#defineVIRTCHNL2_STATUS_ERR_PARAM  -5
-#defineVIRTCHNL2_STATUS_ERR_OPCODE_MISMATCH-38
+/* VIRTCHNL2_ERROR_CODES */
+/* success */
+#defineVIRTCHNL2_STATUS_SUCCESS0
+/* Operation not permitted, used in case of command not permitted for sender */
+#defineVIRTCHNL2_STATUS_ERR_EPERM  1
+/* Bad opcode - virtchnl interface problem */
+#defineVIRTCHNL2_STATUS_ERR_ESRCH  3
+/* I/O error - HW access error */
+#defineVIRTCHNL2_STATUS_ERR_EIO5
+/* No such resource - Referenced resource is not allacated */
+#defineVIRTCHNL2_STATUS_ERR_ENXIO  6
+/* Permission denied - Resource is not permitted to caller */
+#defineVIRTCHNL2_STATUS_ERR_EACCES 13
+/* Device or resource busy - In case shared resource is in use by others */
+#defineVIRTCHNL2_STATUS_ERR_EBUSY  16
+/* Object already exists and not free */
+#defineVIRTCHNL2_STATUS_ERR_EEXIST 17
+/* Invalid input argument in command */
+#defineVIRTCHNL2_STATUS_ERR_EINVAL 22
+/* No space left or allocation failure */
+#defineVIRTCHNL2_STATUS_ERR_ENOSPC 28
+/* Parameter out of range */
+#defineVIRTCHNL2_STATUS_ERR_ERANGE 34
+
+/* Op not allowed in current dev mode */
+#defineVIRTCHNL2_STATUS_ERR_EMODE  200
+/* State Machine error - Command sequence problem */
+#defineVIRTCHNL2_STATUS_ERR_ESM201
 
 /* These macros are used to generate compilation errors if a structure/union
  * is not exactly the correct length. It gives a divide by zero error if the
@@ -1445,11 +1465,11 @@ virtchnl2_vc_validate_vf_msg(__rte_unused struct 
virtchnl2_version_info *ver, u3
case VIRTCHNL2_OP_EVENT:
case VIRTCHNL2_OP_UNKNOWN:
default:
-   return VIRTCHNL2_STATUS_ERR_PARAM;
+   return VIRTCHNL2_STATUS_ERR_ESRCH;
}
/* few more checks */
if (err_msg_format || valid_len != msglen)
-   return VIRTCHNL2_STATUS_ERR_OPCODE_MISMATCH;
+   return VIRTCHNL2_STATUS_ERR_EINVAL;
 
return 0;
 }
-- 
2.25.1



[PATCH 08/18] common/idpf: swap opcode and retval location in msg struct

2023-04-13 Thread Wenjing Qiao
To make the code more readable and make it clearer that the opcode goes
in cookie_high and retval goes in cookie_low.

Add macro definitions for filling opcode and retval.

Signed-off-by: Charles Stoll 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/idpf_controlq.c | 2 ++
 drivers/common/idpf/base/idpf_controlq_api.h | 6 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/common/idpf/base/idpf_controlq.c 
b/drivers/common/idpf/base/idpf_controlq.c
index 8e4d3ee54f..8381e4000f 100644
--- a/drivers/common/idpf/base/idpf_controlq.c
+++ b/drivers/common/idpf/base/idpf_controlq.c
@@ -288,6 +288,8 @@ int idpf_ctlq_deinit(struct idpf_hw *hw)
  * send routine via the q_msg struct / control queue specific data struct.
  * The control queue will hold a reference to each send message until
  * the completion for that message has been cleaned.
+ * Since all q_msgs being sent are store in native endianness, these values
+ * must be converted to LE before being written to the hw descriptor.
  */
 int idpf_ctlq_send(struct idpf_hw *hw, struct idpf_ctlq_info *cq,
   u16 num_q_msg, struct idpf_ctlq_msg q_msg[])
diff --git a/drivers/common/idpf/base/idpf_controlq_api.h 
b/drivers/common/idpf/base/idpf_controlq_api.h
index 32d17baadf..80be282b42 100644
--- a/drivers/common/idpf/base/idpf_controlq_api.h
+++ b/drivers/common/idpf/base/idpf_controlq_api.h
@@ -63,9 +63,13 @@ struct idpf_ctlq_msg {
u16 status; /* when receiving a message */
};
union {
+#ifndef __KERNEL__
+#define FILL_OPCODE_V1(msg, opcode) ((msg).cookie.cfg.mbx.chnl_opcode = opcode)
+#define FILL_RETVAL_V1(msg, retval) ((msg).cookie.cfg.mbx.chnl_retval = retval)
+#endif /* __KERNEL__ */
struct {
-   u32 chnl_retval;
u32 chnl_opcode;
+   u32 chnl_retval;
} mbx;
} cookie;
union {
-- 
2.25.1



[PATCH 09/18] common/idpf: fix idpf_send_msg_to_cp prototypes

2023-04-13 Thread Wenjing Qiao
Virtchnl2 opcodes are no longer in the enum virtchnl_ops. So change
these parameters to allow int rather that compiler enum type checking.

Fixes: fb4ac04e9bfa ("common/idpf: introduce common library")
Cc: sta...@dpdk.org

Signed-off-by: Christopher Pau 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/idpf_common.c| 2 +-
 drivers/common/idpf/base/idpf_prototype.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/common/idpf/base/idpf_common.c 
b/drivers/common/idpf/base/idpf_common.c
index 3a9fdb1878..69e3b32f85 100644
--- a/drivers/common/idpf/base/idpf_common.c
+++ b/drivers/common/idpf/base/idpf_common.c
@@ -146,7 +146,7 @@ int idpf_init_hw(struct idpf_hw *hw, struct idpf_ctlq_size 
ctlq_size)
  * is sent asynchronously, i.e. idpf_asq_send_command() does not wait for
  * completion before returning.
  */
-int idpf_send_msg_to_cp(struct idpf_hw *hw, enum virtchnl_ops v_opcode,
+int idpf_send_msg_to_cp(struct idpf_hw *hw, int v_opcode,
int v_retval, u8 *msg, u16 msglen)
 {
struct idpf_ctlq_msg ctlq_msg = { 0 };
diff --git a/drivers/common/idpf/base/idpf_prototype.h 
b/drivers/common/idpf/base/idpf_prototype.h
index 529b62212d..3ce25e644d 100644
--- a/drivers/common/idpf/base/idpf_prototype.h
+++ b/drivers/common/idpf/base/idpf_prototype.h
@@ -40,6 +40,6 @@ int idpf_set_rss_key(struct idpf_hw *hw, u16 seid,
 int idpf_set_mac_type(struct idpf_hw *hw);
 
 int idpf_reset(struct idpf_hw *hw);
-int idpf_send_msg_to_cp(struct idpf_hw *hw, enum virtchnl_ops v_opcode,
+int idpf_send_msg_to_cp(struct idpf_hw *hw, int v_opcode,
int v_retval, u8 *msg, u16 msglen);
 #endif /* _IDPF_PROTOTYPE_H_ */
-- 
2.25.1



[PATCH 10/18] common/idpf: fix memory leaks on ctrlq functions

2023-04-13 Thread Wenjing Qiao
idpf_init_hw needs to free it's q_info.
idpf_clean_arq_element needs to return buffers via post_rx_buffs

Fixes: fb4ac04e9bfa ("common/idpf: introduce common library")
Cc: sta...@dpdk.org

Signed-off-by: Christopher Pau 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/idpf_common.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/common/idpf/base/idpf_common.c 
b/drivers/common/idpf/base/idpf_common.c
index 69e3b32f85..de82c3458f 100644
--- a/drivers/common/idpf/base/idpf_common.c
+++ b/drivers/common/idpf/base/idpf_common.c
@@ -130,6 +130,8 @@ int idpf_init_hw(struct idpf_hw *hw, struct idpf_ctlq_size 
ctlq_size)
hw->mac.addr[4] = 0x03;
hw->mac.addr[5] = 0x14;
 
+   idpf_free(hw, q_info);
+
return 0;
 }
 
@@ -219,6 +221,7 @@ bool idpf_check_asq_alive(struct idpf_hw *hw)
 int idpf_clean_arq_element(struct idpf_hw *hw,
   struct idpf_arq_event_info *e, u16 *pending)
 {
+   struct idpf_dma_mem *dma_mem = NULL;
struct idpf_ctlq_msg msg = { 0 };
int status;
u16 msg_data_len;
@@ -226,6 +229,8 @@ int idpf_clean_arq_element(struct idpf_hw *hw,
*pending = 1;
 
status = idpf_ctlq_recv(hw->arq, pending, &msg);
+   if (status == -ENOMSG)
+   goto exit;
 
/* ctlq_msg does not align to ctlq_desc, so copy relevant data here */
e->desc.opcode = msg.opcode;
@@ -240,7 +245,14 @@ int idpf_clean_arq_element(struct idpf_hw *hw,
msg_data_len = msg.data_len;
idpf_memcpy(e->msg_buf, msg.ctx.indirect.payload->va, 
msg_data_len,
IDPF_DMA_TO_NONDMA);
+   dma_mem = msg.ctx.indirect.payload;
+   } else {
+   *pending = 0;
}
+
+   status = idpf_ctlq_post_rx_buffs(hw, hw->arq, pending, &dma_mem);
+
+exit:
return status;
 }
 
-- 
2.25.1



[PATCH 11/18] common/idpf: allocate static buffer at initialization

2023-04-13 Thread Wenjing Qiao
Some OSs don't allow allocating DMA memory at runtime. So create an
initial static buffer at initialization to hold this data.

Signed-off-by: Christopher Pau 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/idpf_common.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/common/idpf/base/idpf_common.c 
b/drivers/common/idpf/base/idpf_common.c
index de82c3458f..f4a5707272 100644
--- a/drivers/common/idpf/base/idpf_common.c
+++ b/drivers/common/idpf/base/idpf_common.c
@@ -6,6 +6,7 @@
 #include "idpf_prototype.h"
 #include "virtchnl.h"
 
+struct idpf_dma_mem send_dma_mem = { 0 };
 
 /**
  * idpf_set_mac_type - Sets MAC type
@@ -132,6 +133,15 @@ int idpf_init_hw(struct idpf_hw *hw, struct idpf_ctlq_size 
ctlq_size)
 
idpf_free(hw, q_info);
 
+   /*
+* Need an initial static buffer to copy DMA memory to send
+* for drivers that do not allow this allocation at runtime
+*/
+   send_dma_mem.va = (struct idpf_dma_mem *)
+   idpf_alloc_dma_mem(hw, &send_dma_mem, 4096);
+   if (!send_dma_mem.va)
+   return -ENOMEM;
+
return 0;
 }
 
@@ -152,7 +162,6 @@ int idpf_send_msg_to_cp(struct idpf_hw *hw, int v_opcode,
int v_retval, u8 *msg, u16 msglen)
 {
struct idpf_ctlq_msg ctlq_msg = { 0 };
-   struct idpf_dma_mem dma_mem = { 0 };
int status;
 
ctlq_msg.opcode = idpf_mbq_opc_send_msg_to_pf;
@@ -162,19 +171,11 @@ int idpf_send_msg_to_cp(struct idpf_hw *hw, int v_opcode,
ctlq_msg.cookie.mbx.chnl_opcode = v_opcode;
 
if (msglen > 0) {
-   dma_mem.va = (struct idpf_dma_mem *)
- idpf_alloc_dma_mem(hw, &dma_mem, msglen);
-   if (!dma_mem.va)
-   return -ENOMEM;
-
-   idpf_memcpy(dma_mem.va, msg, msglen, IDPF_NONDMA_TO_DMA);
-   ctlq_msg.ctx.indirect.payload = &dma_mem;
+   idpf_memcpy(send_dma_mem.va, msg, msglen, IDPF_NONDMA_TO_DMA);
+   ctlq_msg.ctx.indirect.payload = &send_dma_mem;
}
status = idpf_ctlq_send(hw, hw->asq, 1, &ctlq_msg);
 
-   if (dma_mem.va)
-   idpf_free_dma_mem(hw, &dma_mem);
-
return status;
 }
 
@@ -262,6 +263,9 @@ int idpf_clean_arq_element(struct idpf_hw *hw,
  */
 int idpf_deinit_hw(struct idpf_hw *hw)
 {
+   if (send_dma_mem.va)
+   idpf_free_dma_mem(hw, &send_dma_mem);
+
hw->asq = NULL;
hw->arq = NULL;
 
-- 
2.25.1



[PATCH 12/18] common/idpf: add SyncE support over VF

2023-04-13 Thread Wenjing Qiao
This patch enables to VF access to all SyncE related operations.

Most of the opcodes in this implementation map directly to the
AQ commands. Additionally there is a VIRTCHNL_OP_SYNCE_GET_HW_INFO
opcode which should be used by VF to discover all hardware
related details required for Synce operations.

The goal of this implementation is to provide device agnostic
interface to the VF, but due to the feature design the VF will
get the minimum HW details via VIRTCHNL_OP_SYNCE_GET_HW_INFO
opcode.

Signed-off-by: Piotr Gardocki 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/virtchnl.h | 582 
 1 file changed, 582 insertions(+)

diff --git a/drivers/common/idpf/base/virtchnl.h 
b/drivers/common/idpf/base/virtchnl.h
index 3008802c4a..54d66c4913 100644
--- a/drivers/common/idpf/base/virtchnl.h
+++ b/drivers/common/idpf/base/virtchnl.h
@@ -184,6 +184,19 @@ enum virtchnl_ops {
VIRTCHNL_OP_CONFIG_QUANTA = 113,
VIRTCHNL_OP_FLOW_SUBSCRIBE = 114,
VIRTCHNL_OP_FLOW_UNSUBSCRIBE = 115,
+   VIRTCHNL_OP_SYNCE_GET_PHY_REC_CLK_OUT = 116,
+   VIRTCHNL_OP_SYNCE_SET_PHY_REC_CLK_OUT = 117,
+   VIRTCHNL_OP_SYNCE_GET_CGU_REF_PRIO = 118,
+   VIRTCHNL_OP_SYNCE_SET_CGU_REF_PRIO = 119,
+   VIRTCHNL_OP_SYNCE_GET_INPUT_PIN_CFG = 120,
+   VIRTCHNL_OP_SYNCE_SET_INPUT_PIN_CFG = 121,
+   VIRTCHNL_OP_SYNCE_GET_OUTPUT_PIN_CFG = 122,
+   VIRTCHNL_OP_SYNCE_SET_OUTPUT_PIN_CFG = 123,
+   VIRTCHNL_OP_SYNCE_GET_CGU_ABILITIES = 124,
+   VIRTCHNL_OP_SYNCE_GET_CGU_DPLL_STATUS = 125,
+   VIRTCHNL_OP_SYNCE_SET_CGU_DPLL_CONFIG = 126,
+   VIRTCHNL_OP_SYNCE_GET_CGU_INFO = 127,
+   VIRTCHNL_OP_SYNCE_GET_HW_INFO = 128,
VIRTCHNL_OP_MAX,
 };
 
@@ -294,6 +307,32 @@ static inline const char *virtchnl_op_str(enum 
virtchnl_ops v_opcode)
return "VIRTCHNL_OP_1588_PTP_SET_PIN_CFG";
case VIRTCHNL_OP_1588_PTP_EXT_TIMESTAMP:
return "VIRTCHNL_OP_1588_PTP_EXT_TIMESTAMP";
+   case VIRTCHNL_OP_SYNCE_GET_PHY_REC_CLK_OUT:
+   return "VIRTCHNL_OP_SYNCE_GET_PHY_REC_CLK_OUT";
+   case VIRTCHNL_OP_SYNCE_SET_PHY_REC_CLK_OUT:
+   return "VIRTCHNL_OP_SYNCE_SET_PHY_REC_CLK_OUT";
+   case VIRTCHNL_OP_SYNCE_GET_CGU_REF_PRIO:
+   return "VIRTCHNL_OP_SYNCE_GET_CGU_REF_PRIO";
+   case VIRTCHNL_OP_SYNCE_SET_CGU_REF_PRIO:
+   return "VIRTCHNL_OP_SYNCE_SET_CGU_REF_PRIO";
+   case VIRTCHNL_OP_SYNCE_GET_INPUT_PIN_CFG:
+   return "VIRTCHNL_OP_SYNCE_GET_INPUT_PIN_CFG";
+   case VIRTCHNL_OP_SYNCE_SET_INPUT_PIN_CFG:
+   return "VIRTCHNL_OP_SYNCE_SET_INPUT_PIN_CFG";
+   case VIRTCHNL_OP_SYNCE_GET_OUTPUT_PIN_CFG:
+   return "VIRTCHNL_OP_SYNCE_GET_OUTPUT_PIN_CFG";
+   case VIRTCHNL_OP_SYNCE_SET_OUTPUT_PIN_CFG:
+   return "VIRTCHNL_OP_SYNCE_SET_OUTPUT_PIN_CFG";
+   case VIRTCHNL_OP_SYNCE_GET_CGU_ABILITIES:
+   return "VIRTCHNL_OP_SYNCE_GET_CGU_ABILITIES";
+   case VIRTCHNL_OP_SYNCE_GET_CGU_DPLL_STATUS:
+   return "VIRTCHNL_OP_SYNCE_GET_CGU_DPLL_STATUS";
+   case VIRTCHNL_OP_SYNCE_SET_CGU_DPLL_CONFIG:
+   return "VIRTCHNL_OP_SYNCE_SET_CGU_DPLL_CONFIG";
+   case VIRTCHNL_OP_SYNCE_GET_CGU_INFO:
+   return "VIRTCHNL_OP_SYNCE_GET_CGU_INFO";
+   case VIRTCHNL_OP_SYNCE_GET_HW_INFO:
+   return "VIRTCHNL_OP_SYNCE_GET_HW_INFO";
case VIRTCHNL_OP_ENABLE_QUEUES_V2:
return "VIRTCHNL_OP_ENABLE_QUEUES_V2";
case VIRTCHNL_OP_DISABLE_QUEUES_V2:
@@ -2065,6 +2104,19 @@ VIRTCHNL_CHECK_STRUCT_LEN(12, virtchnl_quanta_cfg);
  *   VIRTCHNL_OP_1588_PTP_GET_PIN_CFGS
  *   VIRTCHNL_OP_1588_PTP_SET_PIN_CFG
  *   VIRTCHNL_OP_1588_PTP_EXT_TIMESTAMP
+ *   VIRTCHNL_OP_SYNCE_GET_PHY_REC_CLK_OUT
+ *   VIRTCHNL_OP_SYNCE_SET_PHY_REC_CLK_OUT
+ *   VIRTCHNL_OP_SYNCE_GET_CGU_REF_PRIO
+ *   VIRTCHNL_OP_SYNCE_SET_CGU_REF_PRIO
+ *   VIRTCHNL_OP_SYNCE_GET_INPUT_PIN_CFG
+ *   VIRTCHNL_OP_SYNCE_SET_INPUT_PIN_CFG
+ *   VIRTCHNL_OP_SYNCE_GET_OUTPUT_PIN_CFG
+ *   VIRTCHNL_OP_SYNCE_SET_OUTPUT_PIN_CFG
+ *   VIRTCHNL_OP_SYNCE_GET_CGU_ABILITIES
+ *   VIRTCHNL_OP_SYNCE_GET_CGU_DPLL_STATUS
+ *   VIRTCHNL_OP_SYNCE_SET_CGU_DPLL_CONFIG
+ *   VIRTCHNL_OP_SYNCE_GET_CGU_INFO
+ *   VIRTCHNL_OP_SYNCE_GET_HW_INFO
  *
  * Support for offloading control of the device PTP hardware clock (PHC) is 
enabled
  * by VIRTCHNL_VF_CAP_PTP. This capability allows a VF to request that PF
@@ -2085,6 +2137,7 @@ VIRTCHNL_CHECK_STRUCT_LEN(12, virtchnl_quanta_cfg);
 #define VIRTCHNL_1588_PTP_CAP_WRITE_PHCBIT(3)
 #define VIRTCHNL_1588_PTP_CAP_PHC_REGS BIT(4)
 #define VIRTCHNL_1588_PTP_CAP_PIN_CFG  BIT(5)
+#define VIRTCHNL_1588_PTP_CAP_SYNCEBIT(6)
 
 /**
  * virtchnl_phc_regs
@@ -,6 +2275,11 @@ enum virtchnl_ptp_tstamp_format {
  * input to timestamp external events, or as an output to cause a periodic
  * signal output.
  *
+ * VIRTCHNL_1588_P

[PATCH 13/18] common/idpf: replace MAKEMASK to IDPF_M

2023-04-13 Thread Wenjing Qiao
Replace MAKEMASK to IDPF_M to avoid conflicts with MAKEMASK
redefinition from various subcomponents.

Signed-off-by: Priyalee Kushwaha 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/idpf_controlq.h  |  3 --
 drivers/common/idpf/base/idpf_lan_pf_regs.h   | 26 +--
 drivers/common/idpf/base/idpf_lan_txrx.h  | 46 +--
 drivers/common/idpf/base/idpf_lan_vf_regs.h   | 16 +++
 drivers/common/idpf/base/idpf_osdep.h |  2 +
 drivers/common/idpf/base/idpf_type.h  |  2 -
 drivers/common/idpf/base/virtchnl2_lan_desc.h | 28 +--
 7 files changed, 60 insertions(+), 63 deletions(-)

diff --git a/drivers/common/idpf/base/idpf_controlq.h 
b/drivers/common/idpf/base/idpf_controlq.h
index e7b0d803b3..47bffcf79f 100644
--- a/drivers/common/idpf/base/idpf_controlq.h
+++ b/drivers/common/idpf/base/idpf_controlq.h
@@ -97,9 +97,6 @@ struct idpf_ctlq_desc {
 #define IDPF_CTLQ_FLAG_VFC BIT(IDPF_CTLQ_FLAG_VFC_S)   /* 0x800  */
 #define IDPF_CTLQ_FLAG_BUF BIT(IDPF_CTLQ_FLAG_BUF_S)   /* 0x1000 */
 
-/* Host ID is a special field that has 3b and not a 1b flag */
-#define IDPF_CTLQ_FLAG_HOST_ID_M MAKE_MASK(0x7000UL, IDPF_CTLQ_FLAG_HOST_ID_S)
-
 struct idpf_mbxq_desc {
u8 pad[8];  /* CTLQ flags/opcode/len/retval fields */
u32 chnl_opcode;/* avoid confusion with desc->opcode */
diff --git a/drivers/common/idpf/base/idpf_lan_pf_regs.h 
b/drivers/common/idpf/base/idpf_lan_pf_regs.h
index 7f731ec3d6..1c665d1f3b 100644
--- a/drivers/common/idpf/base/idpf_lan_pf_regs.h
+++ b/drivers/common/idpf/base/idpf_lan_pf_regs.h
@@ -24,7 +24,7 @@
 #define PF_FW_ARQBAH   (PF_FW_BASE + 0x4)
 #define PF_FW_ARQLEN   (PF_FW_BASE + 0x8)
 #define PF_FW_ARQLEN_ARQLEN_S  0
-#define PF_FW_ARQLEN_ARQLEN_M  MAKEMASK(0x1FFF, PF_FW_ARQLEN_ARQLEN_S)
+#define PF_FW_ARQLEN_ARQLEN_M  IDPF_M(0x1FFF, PF_FW_ARQLEN_ARQLEN_S)
 #define PF_FW_ARQLEN_ARQVFE_S  28
 #define PF_FW_ARQLEN_ARQVFE_M  BIT(PF_FW_ARQLEN_ARQVFE_S)
 #define PF_FW_ARQLEN_ARQOVFL_S 29
@@ -35,14 +35,14 @@
 #define PF_FW_ARQLEN_ARQENABLE_M   BIT(PF_FW_ARQLEN_ARQENABLE_S)
 #define PF_FW_ARQH (PF_FW_BASE + 0xC)
 #define PF_FW_ARQH_ARQH_S  0
-#define PF_FW_ARQH_ARQH_M  MAKEMASK(0x1FFF, PF_FW_ARQH_ARQH_S)
+#define PF_FW_ARQH_ARQH_M  IDPF_M(0x1FFF, PF_FW_ARQH_ARQH_S)
 #define PF_FW_ARQT (PF_FW_BASE + 0x10)
 
 #define PF_FW_ATQBAL   (PF_FW_BASE + 0x14)
 #define PF_FW_ATQBAH   (PF_FW_BASE + 0x18)
 #define PF_FW_ATQLEN   (PF_FW_BASE + 0x1C)
 #define PF_FW_ATQLEN_ATQLEN_S  0
-#define PF_FW_ATQLEN_ATQLEN_M  MAKEMASK(0x3FF, PF_FW_ATQLEN_ATQLEN_S)
+#define PF_FW_ATQLEN_ATQLEN_M  IDPF_M(0x3FF, PF_FW_ATQLEN_ATQLEN_S)
 #define PF_FW_ATQLEN_ATQVFE_S  28
 #define PF_FW_ATQLEN_ATQVFE_M  BIT(PF_FW_ATQLEN_ATQVFE_S)
 #define PF_FW_ATQLEN_ATQOVFL_S 29
@@ -53,7 +53,7 @@
 #define PF_FW_ATQLEN_ATQENABLE_M   BIT(PF_FW_ATQLEN_ATQENABLE_S)
 #define PF_FW_ATQH (PF_FW_BASE + 0x20)
 #define PF_FW_ATQH_ATQH_S  0
-#define PF_FW_ATQH_ATQH_M  MAKEMASK(0x3FF, PF_FW_ATQH_ATQH_S)
+#define PF_FW_ATQH_ATQH_M  IDPF_M(0x3FF, PF_FW_ATQH_ATQH_S)
 #define PF_FW_ATQT (PF_FW_BASE + 0x24)
 
 /* Interrupts */
@@ -66,7 +66,7 @@
 #define PF_GLINT_DYN_CTL_SWINT_TRIG_S  2
 #define PF_GLINT_DYN_CTL_SWINT_TRIG_M  BIT(PF_GLINT_DYN_CTL_SWINT_TRIG_S)
 #define PF_GLINT_DYN_CTL_ITR_INDX_S3
-#define PF_GLINT_DYN_CTL_ITR_INDX_MMAKEMASK(0x3, 
PF_GLINT_DYN_CTL_ITR_INDX_S)
+#define PF_GLINT_DYN_CTL_ITR_INDX_MIDPF_M(0x3, PF_GLINT_DYN_CTL_ITR_INDX_S)
 #define PF_GLINT_DYN_CTL_INTERVAL_S5
 #define PF_GLINT_DYN_CTL_INTERVAL_MBIT(PF_GLINT_DYN_CTL_INTERVAL_S)
 #define PF_GLINT_DYN_CTL_SW_ITR_INDX_ENA_S 24
@@ -86,13 +86,13 @@
 #define PF_GLINT_ITR(_ITR, _INT) (PF_GLINT_BASE + (((_ITR) + 1) * 4) + ((_INT) 
* 0x1000))
 #define PF_GLINT_ITR_MAX_INDEX 2
 #define PF_GLINT_ITR_INTERVAL_S0
-#define PF_GLINT_ITR_INTERVAL_MMAKEMASK(0xFFF, 
PF_GLINT_ITR_INTERVAL_S)
+#define PF_GLINT_ITR_INTERVAL_MIDPF_M(0xFFF, 
PF_GLINT_ITR_INTERVAL_S)
 
 /* Timesync registers */
 #define PF_TIMESYNC_BASE   0x08404000
 #define PF_GLTSYN_CMD_SYNC (PF_TIMESYNC_BASE)
 #define PF_GLTSYN_CMD_SYNC_EXEC_CMD_S  0
-#define PF_GLTSYN_CMD_SYNC_EXEC_CMD_M  MAKEMASK(0x3, 
PF_GLTSYN_CMD_SYNC_EXEC_CMD_S)
+#define PF_GLTSYN_CMD_SYNC_EXEC_CMD_M  IDPF_M(0x3, 
PF_GLTSYN_CMD_SYNC_EXEC_CMD_S)
 #define PF_GLTSYN_CMD_SYNC_SHTIME_EN_S 2
 #define PF_GLTSYN_CMD_SYNC_SHTIME_EN_M BIT(PF_GLTSYN_CMD_SYNC_SHTIME_EN_S)
 #define PF_GLTSYN_SHTIME_0 (PF_TIMESYNC_BASE + 0x4)
@@ -104,23 +104,23 @@
 /* Generic registers */
 #define PF_INT_DIR_OICR_ENA0x08406000
 #define 

[PATCH 14/18] common/idpf: add GNSS support over VF

2023-04-13 Thread Wenjing Qiao
This patch enables VF access to GNSS Console I2C.

Most of the opcodes in this implementation map directly to the
AQ commands for GNSS Console I2C Read and Write for GNSS status,
configuration, and NMEA messages.

Additionally there is VF and PF negotiation on GNSS Access
Capability through Extended PTP Capability Exchange. VF can
access GNSS Console I2C only if Extended PTP Capability
exchange indicates so.

Signed-off-by: Jun Zhang 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/virtchnl.h | 111 
 1 file changed, 111 insertions(+)

diff --git a/drivers/common/idpf/base/virtchnl.h 
b/drivers/common/idpf/base/virtchnl.h
index 54d66c4913..4e9cf9fdeb 100644
--- a/drivers/common/idpf/base/virtchnl.h
+++ b/drivers/common/idpf/base/virtchnl.h
@@ -197,6 +197,8 @@ enum virtchnl_ops {
VIRTCHNL_OP_SYNCE_SET_CGU_DPLL_CONFIG = 126,
VIRTCHNL_OP_SYNCE_GET_CGU_INFO = 127,
VIRTCHNL_OP_SYNCE_GET_HW_INFO = 128,
+   VIRTCHNL_OP_GNSS_READ_I2C = 129,
+   VIRTCHNL_OP_GNSS_WRITE_I2C = 130,
VIRTCHNL_OP_MAX,
 };
 
@@ -333,6 +335,10 @@ static inline const char *virtchnl_op_str(enum 
virtchnl_ops v_opcode)
return "VIRTCHNL_OP_SYNCE_GET_CGU_INFO";
case VIRTCHNL_OP_SYNCE_GET_HW_INFO:
return "VIRTCHNL_OP_SYNCE_GET_HW_INFO";
+   case VIRTCHNL_OP_GNSS_READ_I2C:
+   return "VIRTCHNL_OP_GNSS_READ_I2C";
+   case VIRTCHNL_OP_GNSS_WRITE_I2C:
+   return "VIRTCHNL_OP_GNSS_WRITE_I2C";
case VIRTCHNL_OP_ENABLE_QUEUES_V2:
return "VIRTCHNL_OP_ENABLE_QUEUES_V2";
case VIRTCHNL_OP_DISABLE_QUEUES_V2:
@@ -2117,6 +2123,8 @@ VIRTCHNL_CHECK_STRUCT_LEN(12, virtchnl_quanta_cfg);
  *   VIRTCHNL_OP_SYNCE_SET_CGU_DPLL_CONFIG
  *   VIRTCHNL_OP_SYNCE_GET_CGU_INFO
  *   VIRTCHNL_OP_SYNCE_GET_HW_INFO
+ *   VIRTCHNL_OP_GNSS_READ_I2C
+ *   VIRTCHNL_OP_GNSS_WRITE_I2C
  *
  * Support for offloading control of the device PTP hardware clock (PHC) is 
enabled
  * by VIRTCHNL_VF_CAP_PTP. This capability allows a VF to request that PF
@@ -2138,6 +2146,7 @@ VIRTCHNL_CHECK_STRUCT_LEN(12, virtchnl_quanta_cfg);
 #define VIRTCHNL_1588_PTP_CAP_PHC_REGS BIT(4)
 #define VIRTCHNL_1588_PTP_CAP_PIN_CFG  BIT(5)
 #define VIRTCHNL_1588_PTP_CAP_SYNCEBIT(6)
+#define VIRTCHNL_1588_PTP_CAP_GNSS BIT(7)
 
 /**
  * virtchnl_phc_regs
@@ -2280,6 +2289,10 @@ enum virtchnl_ptp_tstamp_format {
  * VIRTCHNL_OP_SYNCE_GET_HW_INFO. It returns to VF all required HW details
  * needed for further processing.
  *
+ * VIRTCHNL_1588_PTP_CAP_GNSS indicates that the VF has access to GNSS related
+ * capabilities, i.e. Access onboard GNSS Module (if present) through I2C GNSS
+ * console for GNSS Configuration, Status, and NMEA Messages.
+ *
  * Note that in the future, additional capability flags may be added which
  * indicate additional extended support. All fields marked as reserved by this
  * header will be set to zero. VF implementations should verify this to ensure
@@ -3146,6 +3159,98 @@ struct virtchnl_synce_get_hw_info {
 
 VIRTCHNL_CHECK_STRUCT_LEN(72, virtchnl_synce_get_hw_info);
 
+/**
+ * virtchnl_link_topo_params
+ * @lport_num: link port number
+ * @lport_num_valid: link port number validity
+ * @node_type_ctx: node type & context
+ * @index: node index
+ *
+ * Structure used as part of virtchnl_link_topo_addr with gnss I2C read or 
write
+ * request. VF sets this structure field for GNSS I2C console Node, PF passes 
it
+ * on to AdminQ.
+ */
+struct virtchnl_link_topo_params {
+   u8 lport_num;
+   u8 lport_num_valid;
+   u8 node_type_ctx;
+#define VIRTCHNL_LINK_TOPO_NODE_TYPE_GPS   11
+#define VIRTCHNL_LINK_TOPO_NODE_CTX_S  4
+#define VIRTCHNL_LINK_TOPO_NODE_CTX_M  \
+   (0xF << VIRTCHNL_LINK_TOPO_NODE_CTX_S)
+#define VIRTCHNL_LINK_TOPO_NODE_CTX_GLOBAL 0
+#define VIRTCHNL_LINK_TOPO_NODE_CTX_BOARD  1
+#define VIRTCHNL_LINK_TOPO_NODE_CTX_PORT   2
+#define VIRTCHNL_LINK_TOPO_NODE_CTX_NODE   3
+#define VIRTCHNL_LINK_TOPO_NODE_CTX_PROVIDED   4
+#define VIRTCHNL_LINK_TOPO_NODE_CTX_OVERRIDE   5
+   u8 index;
+};
+
+VIRTCHNL_CHECK_STRUCT_LEN(4, virtchnl_link_topo_params);
+
+/**
+ * virtchnl_link_topo_addr
+ * @topo_params: link topo parameters
+ * @handle: link topo handle (board type, mezzaine / lom Type)
+ *
+ * Structure used as part of virtchnl_gnss_i2c read or write request. VF sets
+ * this structure field for GNSS I2C console Node, PF passes it on to AdminQ.
+ */
+struct virtchnl_link_topo_addr {
+   struct virtchnl_link_topo_params topo_params;
+   u16  handle;
+};
+
+VIRTCHNL_CHECK_STRUCT_LEN(6, virtchnl_link_topo_addr);
+
+/**
+ * virtchnl_gnss_i2c
+ * @topo_addr: link topo address
+ * @i2c_addr: gnss console I2C Address
+ * @i2c_params: gnss console I2C Parameters
+ * @i2c_bus_addr: gnss console I2C Bus Address
+ * @i2c_data: Data to be written to gnss module
+ *
+ * Structure sent wi

[PATCH 15/18] common/idpf: add/delete queue groups commands

2023-04-13 Thread Wenjing Qiao
Add types for new two virtchnl commands: add & delete queue group

Signed-off-by: Nizan Zorea 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/virtchnl2.h | 189 +++
 1 file changed, 189 insertions(+)

diff --git a/drivers/common/idpf/base/virtchnl2.h 
b/drivers/common/idpf/base/virtchnl2.h
index 415e90358e..9e70e5b10e 100644
--- a/drivers/common/idpf/base/virtchnl2.h
+++ b/drivers/common/idpf/base/virtchnl2.h
@@ -95,6 +95,8 @@
 #defineVIRTCHNL2_OP_ADD_MAC_ADDR   535
 #defineVIRTCHNL2_OP_DEL_MAC_ADDR   536
 #defineVIRTCHNL2_OP_CONFIG_PROMISCUOUS_MODE537
+#defineVIRTCHNL2_OP_ADD_QUEUE_GROUPS   538
+#defineVIRTCHNL2_OP_DEL_QUEUE_GROUPS   539
 
 #define VIRTCHNL2_RDMA_INVALID_QUEUE_IDX   0x
 
@@ -345,6 +347,14 @@
 #define VIRTCHNL2_UNICAST_PROMISC  BIT(0)
 #define VIRTCHNL2_MULTICAST_PROMISCBIT(1)
 
+/* VIRTCHNL2_QUEUE_GROUP_TYPE
+ * Type of queue groups
+ * 0 till 0xFF is for general use
+ */
+#define VIRTCHNL2_QUEUE_GROUP_DATA 1
+#define VIRTCHNL2_QUEUE_GROUP_MBX  2
+#define VIRTCHNL2_QUEUE_GROUP_CONFIG   3
+
 /* VIRTCHNL2_PROTO_HDR_TYPE
  * Protocol header type within a packet segment. A segment consists of one or
  * more protocol headers that make up a logical group of protocol headers. Each
@@ -794,6 +804,133 @@ struct virtchnl2_add_queues {
 
 VIRTCHNL2_CHECK_STRUCT_LEN(56, virtchnl2_add_queues);
 
+/* Queue Groups Extension */
+
+struct virtchnl2_rx_queue_group_info {
+   /* IN/OUT, user can ask to update rss_lut size originally allocated
+* by CreateVport command. New size will be returned if allocation
+* suceeded, otherwise original rss_size from CreateVport will
+* be returned.
+*/
+   __le16 rss_lut_size;
+   /* Future extension purpose */
+   u8 pad[6];
+};
+
+VIRTCHNL2_CHECK_STRUCT_LEN(8, virtchnl2_rx_queue_group_info);
+
+struct virtchnl2_tx_queue_group_info { /* IN */
+   /* TX TC queue group will be connected to */
+   u8 tx_tc;
+   /* Each group can have its own priority, value 0-7, while each group
+* with unique priority is strict priority.
+* It can be single set of queue groups which configured with
+* same priority, then they are assumed part of WFQ arbitration
+* group and are expected to be assigned with weight.
+*/
+   u8 priority;
+   /* Determines if queue group is expected to be Strict Priority
+* according to its priority
+*/
+   u8 is_sp;
+   u8 pad;
+
+   /* Peak Info Rate Weight in case Queue Group is part of WFQ
+* arbitration set.
+* The weights of the groups are independent of each other.
+* Possible values: 1-200
+*/
+   __le16 pir_weight;
+   /* Future extension purpose for CIR only */
+   u8 cir_pad[2];
+   /* Future extension purpose*/
+   u8 pad2[8];
+};
+
+VIRTCHNL2_CHECK_STRUCT_LEN(16, virtchnl2_tx_queue_group_info);
+
+struct virtchnl2_queue_group_id {
+   /* Queue group ID - depended on it's type
+* Data: is an ID which is relative to Vport
+* Config & Mailbox: is an ID which is relative to func.
+* This ID is use in future calls, i.e. delete.
+* Requested by host and assigned by Control plane.
+*/
+   __le16 queue_group_id;
+   /* Functional type: see VIRTCHNL2_QUEUE_GROUP_TYPE definitions */
+   __le16 queue_group_type;
+   u8 pad[4];
+};
+
+VIRTCHNL2_CHECK_STRUCT_LEN(8, virtchnl2_queue_group_id);
+
+struct virtchnl2_queue_group_info {
+   /* IN */
+   struct virtchnl2_queue_group_id qg_id;
+   /* IN, Number of queue of different types in the group. */
+   __le16 num_tx_q;
+   __le16 num_tx_complq;
+   __le16 num_rx_q;
+   __le16 num_rx_bufq;
+
+   struct virtchnl2_tx_queue_group_info tx_q_grp_info;
+   struct virtchnl2_rx_queue_group_info rx_q_grp_info;
+   /* Future extension purpose */
+   u8 pad[40];
+   struct virtchnl2_queue_reg_chunks chunks; /* OUT */
+};
+
+VIRTCHNL2_CHECK_STRUCT_LEN(120, virtchnl2_queue_group_info);
+
+struct virtchnl2_queue_groups {
+   __le16 num_queue_groups;
+   u8 pad[6];
+   struct virtchnl2_queue_group_info groups[1];
+};
+
+VIRTCHNL2_CHECK_STRUCT_LEN(128, virtchnl2_queue_groups);
+
+/* VIRTCHNL2_OP_ADD_QUEUE_GROUPS
+ * PF sends this message to request additional transmit/receive queue groups
+ * beyond the ones that were assigned via CREATE_VPORT request.
+ * virtchnl2_add_queue_groups structure is used to specify the number of each
+ * type of queues. CP responds with the same structure with the actual number 
of
+ * groups and queues assigned followed by num_queue_groups and num_chunks of
+ * virtchnl2_queue_groups and virtchnl2_queue_chunk structures.
+ */
+struct virtchnl2_add_queue_groups {
+   /* I

[PATCH 16/18] common/idpf: add func to clean all DESCs on controlq

2023-04-13 Thread Wenjing Qiao
Add 'idpf_ctlq_clean_sq_force' which will clean all descriptors on
given control queue. It is needed in case control plane is not
running and we need to do proper driver cleanup.

Signed-off-by: NorbertX Ciosek 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/idpf_controlq.c | 56 ++--
 drivers/common/idpf/base/idpf_controlq_api.h |  4 ++
 2 files changed, 55 insertions(+), 5 deletions(-)

diff --git a/drivers/common/idpf/base/idpf_controlq.c 
b/drivers/common/idpf/base/idpf_controlq.c
index 8381e4000f..9374fce71e 100644
--- a/drivers/common/idpf/base/idpf_controlq.c
+++ b/drivers/common/idpf/base/idpf_controlq.c
@@ -386,13 +386,15 @@ int idpf_ctlq_send(struct idpf_hw *hw, struct 
idpf_ctlq_info *cq,
 }
 
 /**
- * idpf_ctlq_clean_sq - reclaim send descriptors on HW write back for the
- * requested queue
+ * __idpf_ctlq_clean_sq - helper function to reclaim descriptors on HW write
+ * back for the requested queue
  * @cq: pointer to the specific Control queue
  * @clean_count: (input|output) number of descriptors to clean as input, and
  * number of descriptors actually cleaned as output
  * @msg_status: (output) pointer to msg pointer array to be populated; needs
  * to be allocated by caller
+ * @force: (input) clean descriptors which were not done yet. Use with caution
+ * in kernel mode only
  *
  * Returns an array of message pointers associated with the cleaned
  * descriptors. The pointers are to the original ctlq_msgs sent on the cleaned
@@ -400,8 +402,8 @@ int idpf_ctlq_send(struct idpf_hw *hw, struct 
idpf_ctlq_info *cq,
  * to send will have a non-zero status. The caller is expected to free original
  * ctlq_msgs and free or reuse the DMA buffers.
  */
-int idpf_ctlq_clean_sq(struct idpf_ctlq_info *cq, u16 *clean_count,
-  struct idpf_ctlq_msg *msg_status[])
+static int __idpf_ctlq_clean_sq(struct idpf_ctlq_info *cq, u16 *clean_count,
+   struct idpf_ctlq_msg *msg_status[], bool force)
 {
struct idpf_ctlq_desc *desc;
u16 i = 0, num_to_clean;
@@ -425,7 +427,7 @@ int idpf_ctlq_clean_sq(struct idpf_ctlq_info *cq, u16 
*clean_count,
for (i = 0; i < num_to_clean; i++) {
/* Fetch next descriptor and check if marked as done */
desc = IDPF_CTLQ_DESC(cq, ntc);
-   if (!(LE16_TO_CPU(desc->flags) & IDPF_CTLQ_FLAG_DD))
+   if (!force && !(LE16_TO_CPU(desc->flags) & IDPF_CTLQ_FLAG_DD))
break;
 
desc_err = LE16_TO_CPU(desc->ret_val);
@@ -435,6 +437,8 @@ int idpf_ctlq_clean_sq(struct idpf_ctlq_info *cq, u16 
*clean_count,
}
 
msg_status[i] = cq->bi.tx_msg[ntc];
+   if (!msg_status[i])
+   break;
msg_status[i]->status = desc_err;
 
cq->bi.tx_msg[ntc] = NULL;
@@ -457,6 +461,48 @@ int idpf_ctlq_clean_sq(struct idpf_ctlq_info *cq, u16 
*clean_count,
return ret;
 }
 
+/**
+ * idpf_ctlq_clean_sq_force - reclaim all descriptors on HW write back for the
+ * requested queue. Use only in kernel mode.
+ * @cq: pointer to the specific Control queue
+ * @clean_count: (input|output) number of descriptors to clean as input, and
+ * number of descriptors actually cleaned as output
+ * @msg_status: (output) pointer to msg pointer array to be populated; needs
+ * to be allocated by caller
+ *
+ * Returns an array of message pointers associated with the cleaned
+ * descriptors. The pointers are to the original ctlq_msgs sent on the cleaned
+ * descriptors.  The status will be returned for each; any messages that failed
+ * to send will have a non-zero status. The caller is expected to free original
+ * ctlq_msgs and free or reuse the DMA buffers.
+ */
+int idpf_ctlq_clean_sq_force(struct idpf_ctlq_info *cq, u16 *clean_count,
+struct idpf_ctlq_msg *msg_status[])
+{
+   return __idpf_ctlq_clean_sq(cq, clean_count, msg_status, true);
+}
+
+/**
+ * idpf_ctlq_clean_sq - reclaim send descriptors on HW write back for the
+ * requested queue
+ * @cq: pointer to the specific Control queue
+ * @clean_count: (input|output) number of descriptors to clean as input, and
+ * number of descriptors actually cleaned as output
+ * @msg_status: (output) pointer to msg pointer array to be populated; needs
+ * to be allocated by caller
+ *
+ * Returns an array of message pointers associated with the cleaned
+ * descriptors. The pointers are to the original ctlq_msgs sent on the cleaned
+ * descriptors.  The status will be returned for each; any messages that failed
+ * to send will have a non-zero status. The caller is expected to free original
+ * ctlq_msgs and free or reuse the DMA buffers.
+ */
+int idpf_ctlq_clean_sq(struct idpf_ctlq_info *cq, u16 *clean_count,
+  struct idpf_ctlq_msg *msg_status[])
+{
+   return __idpf_ctlq_clean_sq(cq, clean_count, msg_status, false);
+}
+
 /**
  * idpf_ctlq_po

[PATCH 17/18] common/idpf: fix cannot understand warnings

2023-04-13 Thread Wenjing Qiao
Fix cannot understand function prototype warning, it is due to missing
"struct" keyword and not described parameter or member in comments.

Fixes: fb4ac04e9bfa ("common/idpf: introduce common library")
Cc: sta...@dpdk.org

Signed-off-by: Simei Su 
Signed-off-by: Wenjing Qiao 
---
 drivers/common/idpf/base/virtchnl.h | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/common/idpf/base/virtchnl.h 
b/drivers/common/idpf/base/virtchnl.h
index 4e9cf9fdeb..a333a3d88c 100644
--- a/drivers/common/idpf/base/virtchnl.h
+++ b/drivers/common/idpf/base/virtchnl.h
@@ -2149,7 +2149,7 @@ VIRTCHNL_CHECK_STRUCT_LEN(12, virtchnl_quanta_cfg);
 #define VIRTCHNL_1588_PTP_CAP_GNSS BIT(7)
 
 /**
- * virtchnl_phc_regs
+ * struct virtchnl_phc_regs
  *
  * Structure defines how the VF should access PHC related registers. The VF
  * must request VIRTCHNL_1588_PTP_CAP_PHC_REGS. If the VF has access to PHC
@@ -2211,7 +2211,7 @@ enum virtchnl_ptp_tstamp_format {
 };
 
 /**
- * virtchnl_ptp_caps
+ * struct virtchnl_ptp_caps
  *
  * Structure that defines the PTP capabilities available to the VF. The VF
  * sends VIRTCHNL_OP_1588_PTP_GET_CAPS, and must fill in the ptp_caps field
@@ -2313,7 +2313,7 @@ struct virtchnl_ptp_caps {
 VIRTCHNL_CHECK_STRUCT_LEN(48, virtchnl_ptp_caps);
 
 /**
- * virtchnl_phc_time
+ * struct virtchnl_phc_time
  * @time: PHC time in nanoseconds
  * @rsvd: Reserved for future extension
  *
@@ -2339,7 +2339,7 @@ struct virtchnl_phc_time {
 VIRTCHNL_CHECK_STRUCT_LEN(16, virtchnl_phc_time);
 
 /**
- * virtchnl_phc_adj_time
+ * struct virtchnl_phc_adj_time
  * @delta: offset requested to adjust clock by
  * @rsvd: reserved for future extension
  *
@@ -2359,7 +2359,7 @@ struct virtchnl_phc_adj_time {
 VIRTCHNL_CHECK_STRUCT_LEN(16, virtchnl_phc_adj_time);
 
 /**
- * virtchnl_phc_adj_freq
+ * struct virtchnl_phc_adj_freq
  * @scaled_ppm: frequency adjustment represented in scaled parts per million
  * @rsvd: Reserved for future extension
  *
@@ -2388,7 +2388,7 @@ struct virtchnl_phc_adj_freq {
 VIRTCHNL_CHECK_STRUCT_LEN(16, virtchnl_phc_adj_freq);
 
 /**
- * virtchnl_phc_tx_stamp
+ * struct virtchnl_phc_tx_stamp
  * @tstamp: timestamp value
  * @rsvd: Reserved for future extension
  *
@@ -2435,7 +2435,7 @@ enum virtchnl_phc_ext_ts_mode {
 };
 
 /**
- * virtchnl_phc_ext_ts
+ * struct virtchnl_phc_ext_ts
  * @mode: mode of external timestamp request
  * @rsvd: reserved for future extension
  *
@@ -2473,13 +2473,13 @@ enum virtchnl_phc_per_out_flags {
 };
 
 /**
- * virtchnl_phc_per_out
+ * struct virtchnl_phc_per_out
  * @start: absolute start time (if VIRTCHNL_PHC_PER_OUT_PHASE_START unset)
  * @phase: phase offset to start (if VIRTCHNL_PHC_PER_OUT_PHASE_START set)
  * @period: time to complete a full clock cycle (low - > high -> low)
  * @on: length of time the signal should stay high
  * @flags: flags defining the periodic output operation.
- * rsvd: reserved for future extension
+ * @rsvd: reserved for future extension
  *
  * Configuration for a periodic output signal. Used to define the signal that
  * should be generated on a given function.
@@ -2547,7 +2547,8 @@ enum virtchnl_phc_pin_cfg_flags {
 };
 
 /**
- * virtchnl_phc_set_pin
+ * struct virtchnl_phc_set_pin
+ * @flags: flags defining the bits to cfg pin
  * @pin_index: The pin to get or set
  * @func: the function type the pin is assigned to
  * @func_index: the index of the function the pin is assigned to
@@ -2591,7 +2592,7 @@ struct virtchnl_phc_set_pin {
 VIRTCHNL_CHECK_STRUCT_LEN(80, virtchnl_phc_set_pin);
 
 /**
- * virtchnl_phc_pin
+ * struct virtchnl_phc_pin
  * @pin_index: The pin to get or set
  * @func: the function type the pin is assigned to
  * @func_index: the index of the function the pin is assigned to
@@ -2618,9 +2619,10 @@ struct virtchnl_phc_pin {
 VIRTCHNL_CHECK_STRUCT_LEN(72, virtchnl_phc_pin);
 
 /**
- * virtchnl_phc_pin_cfg
+ * struct virtchnl_phc_get_pins
  * @len: length of the variable pin config array
  * @pins: variable length pin configuration array
+ * @rsvd: reserved for future extension
  *
  * Variable structure sent by the PF in reply to
  * VIRTCHNL_OP_1588_PTP_GET_PIN_CFGS. The VF does not send this structure with
@@ -2642,7 +2644,7 @@ struct virtchnl_phc_get_pins {
 VIRTCHNL_CHECK_STRUCT_LEN(80, virtchnl_phc_get_pins);
 
 /**
- * virtchnl_phc_ext_stamp
+ * struct virtchnl_phc_ext_stamp
  * @tstamp: timestamp value
  * @tstamp_rsvd: Reserved for future extension of the timestamp value.
  * @tstamp_format: format of the timstamp
-- 
2.25.1



[PATCH 18/18] common/idpf: update license and README

2023-04-13 Thread Wenjing Qiao
Update license and README

Signed-off-by: Wenjing Qiao 
---
 .mailmap | 8 
 drivers/common/idpf/base/README  | 4 ++--
 drivers/common/idpf/base/idpf_alloc.h| 2 +-
 drivers/common/idpf/base/idpf_common.c   | 2 +-
 drivers/common/idpf/base/idpf_controlq.c | 2 +-
 drivers/common/idpf/base/idpf_controlq.h | 2 +-
 drivers/common/idpf/base/idpf_controlq_api.h | 2 +-
 drivers/common/idpf/base/idpf_controlq_setup.c   | 2 +-
 drivers/common/idpf/base/idpf_devids.h   | 2 +-
 drivers/common/idpf/base/idpf_lan_pf_regs.h  | 2 +-
 drivers/common/idpf/base/idpf_lan_txrx.h | 2 +-
 drivers/common/idpf/base/idpf_lan_vf_regs.h  | 2 +-
 drivers/common/idpf/base/idpf_osdep.h| 2 +-
 drivers/common/idpf/base/idpf_prototype.h| 2 +-
 drivers/common/idpf/base/idpf_type.h | 2 +-
 drivers/common/idpf/base/meson.build | 2 +-
 drivers/common/idpf/base/siov_regs.h | 2 +-
 drivers/common/idpf/base/virtchnl.h  | 2 +-
 drivers/common/idpf/base/virtchnl2.h | 2 +-
 drivers/common/idpf/base/virtchnl2_lan_desc.h| 2 +-
 drivers/common/idpf/base/virtchnl_inline_ipsec.h | 2 +-
 21 files changed, 29 insertions(+), 21 deletions(-)

diff --git a/.mailmap b/.mailmap
index 0859104404..309b1bc69e 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1603,3 +1603,11 @@ Ziye Yang 
 Zoltan Kiss  
 Zorik Machulsky 
 Zyta Szpak   
+Charles Stoll 
+Nizan Zorea 
+Vinoth Kumar Chandra Mohan 
+NorbertX Ciosek 
+Pavan Kumar Linga 
+Jun Zhang 
+Priyalee Kushwaha 
+Kazatsker Kirill 
diff --git a/drivers/common/idpf/base/README b/drivers/common/idpf/base/README
index 257ad6c4b1..693049c057 100644
--- a/drivers/common/idpf/base/README
+++ b/drivers/common/idpf/base/README
@@ -1,12 +1,12 @@
 /* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2021-2022 Intel Corporation
+ * Copyright(c) 2021-2023 Intel Corporation
  */
 
 Intel® IDPF driver
 ==
 
 This directory contains source code of BSD-3-Clause idpf driver of version
-2022.09.13 released by the team which develops basic drivers for Intel IPU.
+2023.02.23 released by the team which develops basic drivers for Intel IPU.
 The directory of base/ contains the original source package.
 This driver is valid for the product(s) listed below
 
diff --git a/drivers/common/idpf/base/idpf_alloc.h 
b/drivers/common/idpf/base/idpf_alloc.h
index bc054851b3..5cc4beb5cf 100644
--- a/drivers/common/idpf/base/idpf_alloc.h
+++ b/drivers/common/idpf/base/idpf_alloc.h
@@ -1,5 +1,5 @@
 /* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2001-2022 Intel Corporation
+ * Copyright(c) 2001-2023 Intel Corporation
  */
 
 #ifndef _IDPF_ALLOC_H_
diff --git a/drivers/common/idpf/base/idpf_common.c 
b/drivers/common/idpf/base/idpf_common.c
index f4a5707272..d0efc6be66 100644
--- a/drivers/common/idpf/base/idpf_common.c
+++ b/drivers/common/idpf/base/idpf_common.c
@@ -1,5 +1,5 @@
 /* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2001-2022 Intel Corporation
+ * Copyright(c) 2001-2023 Intel Corporation
  */
 
 #include "idpf_type.h"
diff --git a/drivers/common/idpf/base/idpf_controlq.c 
b/drivers/common/idpf/base/idpf_controlq.c
index 9374fce71e..68aae6f321 100644
--- a/drivers/common/idpf/base/idpf_controlq.c
+++ b/drivers/common/idpf/base/idpf_controlq.c
@@ -1,5 +1,5 @@
 /* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2001-2022 Intel Corporation
+ * Copyright(c) 2001-2023 Intel Corporation
  */
 
 #include "idpf_controlq.h"
diff --git a/drivers/common/idpf/base/idpf_controlq.h 
b/drivers/common/idpf/base/idpf_controlq.h
index 47bffcf79f..0fe0e94a37 100644
--- a/drivers/common/idpf/base/idpf_controlq.h
+++ b/drivers/common/idpf/base/idpf_controlq.h
@@ -1,5 +1,5 @@
 /* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2001-2022 Intel Corporation
+ * Copyright(c) 2001-2023 Intel Corporation
  */
 
 #ifndef _IDPF_CONTROLQ_H_
diff --git a/drivers/common/idpf/base/idpf_controlq_api.h 
b/drivers/common/idpf/base/idpf_controlq_api.h
index a00faac05f..ad649ab356 100644
--- a/drivers/common/idpf/base/idpf_controlq_api.h
+++ b/drivers/common/idpf/base/idpf_controlq_api.h
@@ -1,5 +1,5 @@
 /* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2001-2022 Intel Corporation
+ * Copyright(c) 2001-2023 Intel Corporation
  */
 
 #ifndef _IDPF_CONTROLQ_API_H_
diff --git a/drivers/common/idpf/base/idpf_controlq_setup.c 
b/drivers/common/idpf/base/idpf_controlq_setup.c
index 3a272b1f8d..0f1b52a7e9 100644
--- a/drivers/common/idpf/base/idpf_controlq_setup.c
+++ b/drivers/common/idpf/base/idpf_controlq_setup.c
@@ -1,5 +1,5 @@
 /* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2001-2022 Intel Corporation
+ * Copyright(c) 2001-2023 Intel Corporation
  */
 
 
diff --git a/drivers/common/idpf/base/idpf_devids.h 
b/drivers/common/idpf/base/idpf_devids.h
index a91eb4e02a..c47762d5b7 100644
--- a/drivers/common/idpf/bas

[PATCH] net/virtio-user: fix leak when initialisation fails

2023-04-13 Thread David Marchand
Caught with ASan.
If initialising a virtio_user port fails, we may leak the ifname passed
via a devargs.

Fixes: 4214a1b493f2 ("net/virtio-user: support changing tap interface name")
Cc: sta...@dpdk.org

Signed-off-by: David Marchand 
---
 drivers/net/virtio/virtio_user/virtio_user_dev.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c 
b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index f46a131b5c..744f3c30d2 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -696,11 +696,7 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char 
*path, uint16_t queues,
dev->frontend_features = 0;
dev->unsupported_features = 0;
dev->backend_type = backend_type;
-
-   if (*ifname) {
-   dev->ifname = *ifname;
-   *ifname = NULL;
-   }
+   dev->ifname = *ifname;
 
if (virtio_user_dev_setup(dev) < 0) {
PMD_INIT_LOG(ERR, "(%s) backend set up fails", dev->path);
@@ -794,6 +790,7 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char 
*path, uint16_t queues,
}
}
 
+   *ifname = NULL;
return 0;
 
 notify_uninit:
-- 
2.39.2



[PATCH v2 1/3] eal: add x86 cpuid support for monitorx

2023-04-13 Thread Sivaprasad Tummala
Add a new CPUID flag to indicate support for monitorx instruction
on AMD Epyc processors.

Signed-off-by: Sivaprasad Tummala 
---
 lib/eal/include/generic/rte_cpuflags.h | 2 ++
 lib/eal/x86/include/rte_cpuflags.h | 1 +
 lib/eal/x86/rte_cpuflags.c | 3 +++
 3 files changed, 6 insertions(+)

diff --git a/lib/eal/include/generic/rte_cpuflags.h 
b/lib/eal/include/generic/rte_cpuflags.h
index d35551e931..db653a8dd7 100644
--- a/lib/eal/include/generic/rte_cpuflags.h
+++ b/lib/eal/include/generic/rte_cpuflags.h
@@ -26,6 +26,8 @@ struct rte_cpu_intrinsics {
/**< indicates support for rte_power_pause function */
uint32_t power_monitor_multi : 1;
/**< indicates support for rte_power_monitor_multi function */
+   uint32_t amd_power_monitorx : 1;
+   /**< indicates amd support for rte_power_monitor function */
 };
 
 /**
diff --git a/lib/eal/x86/include/rte_cpuflags.h 
b/lib/eal/x86/include/rte_cpuflags.h
index 92e90fb6e0..d3e608533a 100644
--- a/lib/eal/x86/include/rte_cpuflags.h
+++ b/lib/eal/x86/include/rte_cpuflags.h
@@ -133,6 +133,7 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_AVX512VP2INTERSECT, /**< AVX512 Two Register 
Intersection */
 
RTE_CPUFLAG_WAITPKG,/**< UMONITOR/UMWAIT/TPAUSE */
+   RTE_CPUFLAG_MONITORX,   /**< MONITORX */
 
/* The last item */
RTE_CPUFLAG_NUMFLAGS,   /**< This should always be the 
last! */
diff --git a/lib/eal/x86/rte_cpuflags.c b/lib/eal/x86/rte_cpuflags.c
index d6b518251b..ae2e0a8470 100644
--- a/lib/eal/x86/rte_cpuflags.c
+++ b/lib/eal/x86/rte_cpuflags.c
@@ -133,6 +133,7 @@ const struct feature_entry rte_cpu_feature_table[] = {
 
FEAT_DEF(LAHF_SAHF, 0x8001, 0, RTE_REG_ECX,  0)
FEAT_DEF(LZCNT, 0x8001, 0, RTE_REG_ECX,  4)
+   FEAT_DEF(MONITORX, 0x8001, 0, RTE_REG_ECX,  29)
 
FEAT_DEF(SYSCALL, 0x8001, 0, RTE_REG_EDX, 11)
FEAT_DEF(XD, 0x8001, 0, RTE_REG_EDX, 20)
@@ -191,5 +192,7 @@ rte_cpu_get_intrinsics_support(struct rte_cpu_intrinsics 
*intrinsics)
intrinsics->power_pause = 1;
if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_RTM))
intrinsics->power_monitor_multi = 1;
+   } else if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_MONITORX)) {
+   intrinsics->amd_power_monitorx = 1;
}
 }
-- 
2.34.1



[PATCH v2 3/3] power: amd power monitor support

2023-04-13 Thread Sivaprasad Tummala
mwaitx allows epyc processors to enter a implementation dependent
power/performance optimized state (C1 state) for a specific period
or until a store to the monitored address range.

Signed-off-by: Sivaprasad Tummala 
---
 lib/eal/x86/rte_power_intrinsics.c | 83 --
 lib/power/rte_power_pmd_mgmt.c |  3 +-
 2 files changed, 82 insertions(+), 4 deletions(-)

diff --git a/lib/eal/x86/rte_power_intrinsics.c 
b/lib/eal/x86/rte_power_intrinsics.c
index f749da9b85..d688066b3a 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -30,6 +30,7 @@ __umwait_wakeup(volatile void *addr)
 
 static bool wait_supported;
 static bool wait_multi_supported;
+static bool amd_mwaitx_supported;
 
 static inline uint64_t
 __get_umwait_val(const volatile void *p, const uint8_t sz)
@@ -65,6 +66,76 @@ __check_val_size(const uint8_t sz)
}
 }
 
+/**
+ * This function uses MONITORX/MWAITX instructions and will enter C1 state.
+ * For more information about usage of these instructions, please refer to
+ * AMD64 Architecture Programmer’s Manual.
+ */
+static inline int
+amd_power_monitorx(const struct rte_power_monitor_cond *pmc,
+   const uint64_t tsc_timestamp)
+{
+   const unsigned int lcore_id = rte_lcore_id();
+   struct power_wait_status *s;
+   uint64_t cur_value;
+
+   RTE_SET_USED(tsc_timestamp);
+
+   /* prevent non-EAL thread from using this API */
+   if (lcore_id >= RTE_MAX_LCORE)
+   return -EINVAL;
+
+   if (pmc == NULL)
+   return -EINVAL;
+
+   if (__check_val_size(pmc->size) < 0)
+   return -EINVAL;
+
+   if (pmc->fn == NULL)
+   return -EINVAL;
+
+   s = &wait_status[lcore_id];
+
+   /* update sleep address */
+   rte_spinlock_lock(&s->lock);
+   s->monitor_addr = pmc->addr;
+
+   /*
+* we're using raw byte codes for now as only the newest compiler
+* versions support this instruction natively.
+*/
+   /* set address for MONITORX */
+   asm volatile(".byte 0x0f, 0x01, 0xfa;"
+   :
+   : "a"(pmc->addr),
+   "c"(0),  /* no extensions */
+   "d"(0)); /* no hints */
+
+   /* now that we've put this address into monitor, we can unlock */
+   rte_spinlock_unlock(&s->lock);
+
+   cur_value = __get_umwait_val(pmc->addr, pmc->size);
+
+   /* check if callback indicates we should abort */
+   if (pmc->fn(cur_value, pmc->opaque) != 0)
+   goto end;
+
+   /* execute MWAITX */
+   asm volatile(".byte 0x0f, 0x01, 0xfb;"
+   : /* ignore rflags */
+   : "a"(0), /* enter C1 */
+   "c"(0), /* no time-out */
+   "b"(0));
+
+end:
+   /* erase sleep address */
+   rte_spinlock_lock(&s->lock);
+   s->monitor_addr = NULL;
+   rte_spinlock_unlock(&s->lock);
+
+   return 0;
+}
+
 /**
  * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
  * For more information about usage of these instructions, please refer to
@@ -81,8 +152,12 @@ rte_power_monitor(const struct rte_power_monitor_cond *pmc,
uint64_t cur_value;
 
/* prevent user from running this instruction if it's not supported */
-   if (!wait_supported)
-   return -ENOTSUP;
+   if (!wait_supported) {
+   if (amd_mwaitx_supported)
+   return amd_power_monitorx(pmc, tsc_timestamp);
+   else
+   return -ENOTSUP;
+   }
 
/* prevent non-EAL thread from using this API */
if (lcore_id >= RTE_MAX_LCORE)
@@ -170,6 +245,8 @@ RTE_INIT(rte_power_intrinsics_init) {
wait_supported = 1;
if (i.power_monitor_multi)
wait_multi_supported = 1;
+   if (i.amd_power_monitorx)
+   amd_mwaitx_supported = 1;
 }
 
 int
@@ -178,7 +255,7 @@ rte_power_monitor_wakeup(const unsigned int lcore_id)
struct power_wait_status *s;
 
/* prevent user from running this instruction if it's not supported */
-   if (!wait_supported)
+   if (!wait_supported && !amd_mwaitx_supported)
return -ENOTSUP;
 
/* prevent buffer overrun */
diff --git a/lib/power/rte_power_pmd_mgmt.c b/lib/power/rte_power_pmd_mgmt.c
index ca1840387c..048a41dc29 100644
--- a/lib/power/rte_power_pmd_mgmt.c
+++ b/lib/power/rte_power_pmd_mgmt.c
@@ -447,7 +447,8 @@ check_monitor(struct pmd_core_cfg *cfg, const union queue 
*qdata)
bool multimonitor_supported;
 
/* check if rte_power_monitor is supported */
-   if (!global_data.intrinsics_support.power_monitor) {
+   if ((!global_data.intrinsics_support.power_monitor) &&
+   (!global_data.intrinsics_support.amd_power_monitorx)) {
RTE_LOG(DEBUG, POWER, "Monitoring intrinsics are not 
supp

[PATCH v2 2/3] doc: announce new cpu flag added to rte_cpu_flag_t

2023-04-13 Thread Sivaprasad Tummala
A new flag RTE_CPUFLAG_MONITORX is added to rte_cpu_flag_t in
DPDK 23.07 release to support monitorx instruction on Epyc processors.
This results in ABI breakage for legacy apps.

Signed-off-by: Sivaprasad Tummala 
---
 doc/guides/rel_notes/deprecation.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index dcc1ca1696..65e849616d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -163,3 +163,6 @@ Deprecation Notices
   The new port library API (functions rte_swx_port_*)
   will gradually transition from experimental to stable status
   starting with DPDK 23.07 release.
+
+* eal/x86: The enum ``rte_cpu_flag_t`` will be extended with a new cpu flag
+  ``RTE_CPUFLAG_MONITORX`` to support monitorx instruction on Epyc processors.
-- 
2.34.1



Re: [PATCH v2 1/3] eal: add x86 cpuid support for monitorx

2023-04-13 Thread David Marchand
On Thu, Apr 13, 2023 at 1:54 PM Sivaprasad Tummala
 wrote:
>
> Add a new CPUID flag to indicate support for monitorx instruction
> on AMD Epyc processors.
>
> Signed-off-by: Sivaprasad Tummala 
> ---
>  lib/eal/include/generic/rte_cpuflags.h | 2 ++
>  lib/eal/x86/include/rte_cpuflags.h | 1 +
>  lib/eal/x86/rte_cpuflags.c | 3 +++
>  3 files changed, 6 insertions(+)
>
> diff --git a/lib/eal/include/generic/rte_cpuflags.h 
> b/lib/eal/include/generic/rte_cpuflags.h
> index d35551e931..db653a8dd7 100644
> --- a/lib/eal/include/generic/rte_cpuflags.h
> +++ b/lib/eal/include/generic/rte_cpuflags.h
> @@ -26,6 +26,8 @@ struct rte_cpu_intrinsics {
> /**< indicates support for rte_power_pause function */
> uint32_t power_monitor_multi : 1;
> /**< indicates support for rte_power_monitor_multi function */
> +   uint32_t amd_power_monitorx : 1;
> +   /**< indicates amd support for rte_power_monitor function */

I did not look at the patch detail, I just stopped at this part.
What makes the AMD monitorx stuff special that it needs to be exposed
in the generic API?


-- 
David Marchand



RE: [PATCH 0/6] add support for CDX bus

2023-04-13 Thread Gupta, Nipun


> -Original Message-
> From: Gupta, Nipun
> Sent: Friday, April 7, 2023 1:00 PM
> To: David Marchand 
> Cc: dev@dpdk.org; tho...@monjalon.net; Yigit, Ferruh
> ; Anand, Harpreet ;
> Agarwal, Nikhil 
> Subject: Re: [PATCH 0/6] add support for CDX bus
> 
> 
> 
> On 4/7/2023 12:48 PM, David Marchand wrote:
> > Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
> >
> >
> > Hello,
> >
> > On Fri, Apr 7, 2023 at 8:02 AM Nipun Gupta  wrote:
> >>
> >> Support AMD CDX bus, for FPGA based CDX devices. The CDX
> >> devices are memory mapped on system bus for embedded CPUs.
> >>
> >> It uses sysfs interface and the vfio-cdx driver to discover
> >> and initialize the CDX devices.
> >>
> >> The patches are intended for DPDK 23.07 release, and have been sent
> >> as an RFC as patches are yet to be merged in Linux.
> >>
> >> Linux CDX bus patches has been added into linux next:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
> next.git/tree/drivers/cdx
> >>
> >> VFIO patches are also submitted in upstream:
> >> https://www.spinics.net/lists/kvm/msg310623.html
> >
> > Hard to tell just from this link what the status is.
> > Has it been reviewed?
> > When are you expecting this to get merged?
> 
> The CDX bus code has been merged and VFIO code is under review. Apart
> from this, we will soon have Open source Linux from AMD which has all
> the required patches for CDX in a week or so (I will provide the link
> once that is available).

The CDX bus and VFIO support is now available at Xilinx open-source tree:
https://github.com/Xilinx/linux-xlnx (drivers/cdx/ and drivers/vfio/cdx)

Regards,
Nipun


[PATCH v2 3/6] bus/cdx: add support for MSI

2023-04-13 Thread Nipun Gupta
MSI's are exposed to the devices using VFIO (vfio-cdx). This
patch uses the same to add support for MSI for the devices on
the cdx bus.

Signed-off-by: Nipun Gupta 
---
 drivers/bus/cdx/bus_cdx_driver.h   |  25 
 drivers/bus/cdx/cdx.c  |  11 ++
 drivers/bus/cdx/cdx_vfio.c | 182 -
 drivers/bus/cdx/version.map|   2 +
 lib/eal/common/eal_common_interrupts.c |  21 +++
 lib/eal/common/eal_interrupts.h|   1 +
 lib/eal/include/rte_interrupts.h   |  32 +
 lib/eal/version.map|   2 +
 8 files changed, 274 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/cdx/bus_cdx_driver.h b/drivers/bus/cdx/bus_cdx_driver.h
index 7edcb019eb..fdeaf46664 100644
--- a/drivers/bus/cdx/bus_cdx_driver.h
+++ b/drivers/bus/cdx/bus_cdx_driver.h
@@ -72,6 +72,7 @@ struct rte_cdx_device {
struct rte_cdx_id id;   /**< CDX ID. */
struct rte_mem_resource mem_resource[CDX_MAX_RESOURCE];
/**< CDX Memory Resource */
+   struct rte_intr_handle *intr_handle;/**< Interrupt handle */
 };
 
 /**
@@ -173,6 +174,30 @@ void rte_cdx_unmap_device(struct rte_cdx_device *dev);
 __rte_internal
 void rte_cdx_register(struct rte_cdx_driver *driver);
 
+/**
+ * Enables VFIO Interrupts for CDX bus devices.
+ *
+ * @param intr_handle
+ *   Pointer to the interrupt handle.
+ *
+ *  @return
+ *  0 on success, -1 on error.
+ */
+__rte_internal
+int rte_cdx_vfio_intr_enable(const struct rte_intr_handle *intr_handle);
+
+/**
+ * Disable VFIO Interrupts for CDX bus devices.
+ *
+ * @param intr_handle
+ *   Pointer to the interrupt handle.
+ *
+ *  @return
+ *  0 on success, -1 on error.
+ */
+__rte_internal
+int rte_cdx_vfio_intr_disable(const struct rte_intr_handle *intr_handle);
+
 /**
  * Helper for CDX device registration from driver (eth, crypto, raw) instance
  */
diff --git a/drivers/bus/cdx/cdx.c b/drivers/bus/cdx/cdx.c
index b1d8f8382f..f34736a54a 100644
--- a/drivers/bus/cdx/cdx.c
+++ b/drivers/bus/cdx/cdx.c
@@ -204,6 +204,15 @@ cdx_scan_one(const char *dirname, const char *dev_name)
goto err;
}
 
+   /* Allocate interrupt instance for cdx device */
+   dev->intr_handle =
+   rte_intr_instance_alloc(RTE_INTR_INSTANCE_F_PRIVATE);
+   if (dev->intr_handle == NULL) {
+   CDX_BUS_ERR("Failed to create interrupt instance for %s\n",
+   dev->device.name);
+   return -ENOMEM;
+   }
+
/*
 * Check if device is bound to 'vfio-cdx' driver, so that user-space
 * can gracefully access the device.
@@ -395,6 +404,8 @@ cdx_probe_one_driver(struct rte_cdx_driver *dr,
return ret;
 
 error_probe:
+   rte_intr_instance_free(dev->intr_handle);
+   dev->intr_handle = NULL;
cdx_vfio_unmap_resource(dev);
 error_map_device:
return ret;
diff --git a/drivers/bus/cdx/cdx_vfio.c b/drivers/bus/cdx/cdx_vfio.c
index ae11f589b3..1422b98503 100644
--- a/drivers/bus/cdx/cdx_vfio.c
+++ b/drivers/bus/cdx/cdx_vfio.c
@@ -60,6 +60,10 @@ struct mapped_cdx_resource {
 /** mapped cdx device list */
 TAILQ_HEAD(mapped_cdx_res_list, mapped_cdx_resource);
 
+/* irq set buffer length for MSI interrupts */
+#define MSI_IRQ_SET_BUF_LEN (sizeof(struct vfio_irq_set) + \
+ sizeof(int) * (RTE_MAX_RXTX_INTR_VEC_ID + 1))
+
 static struct rte_tailq_elem cdx_vfio_tailq = {
.name = "VFIO_CDX_RESOURCE_LIST",
 };
@@ -104,6 +108,27 @@ cdx_vfio_unmap_resource_primary(struct rte_cdx_device *dev)
char cdx_addr[PATH_MAX] = {0};
struct mapped_cdx_resource *vfio_res = NULL;
struct mapped_cdx_res_list *vfio_res_list;
+   int ret, vfio_dev_fd;
+
+   if (rte_intr_fd_get(dev->intr_handle) < 0)
+   return -1;
+
+   if (close(rte_intr_fd_get(dev->intr_handle)) < 0) {
+   CDX_BUS_ERR("Error when closing eventfd file descriptor for %s",
+   dev->device.name);
+   return -1;
+   }
+
+   vfio_dev_fd = rte_intr_dev_fd_get(dev->intr_handle);
+   if (vfio_dev_fd < 0)
+   return -1;
+
+   ret = rte_vfio_release_device(rte_cdx_get_sysfs_path(), 
dev->device.name,
+ vfio_dev_fd);
+   if (ret < 0) {
+   CDX_BUS_ERR("Cannot release VFIO device");
+   return ret;
+   }
 
vfio_res_list =
RTE_TAILQ_CAST(cdx_vfio_tailq.head, mapped_cdx_res_list);
@@ -126,6 +151,18 @@ cdx_vfio_unmap_resource_secondary(struct rte_cdx_device 
*dev)
 {
struct mapped_cdx_resource *vfio_res = NULL;
struct mapped_cdx_res_list *vfio_res_list;
+   int ret, vfio_dev_fd;
+
+   vfio_dev_fd = rte_intr_dev_fd_get(dev->intr_handle);
+   if (vfio_dev_fd < 0)
+   return -1;
+
+   ret = rte_vfio_release_device(rte_cdx_get_sysfs_path(), 
dev->device.n

[PATCH v2 2/6] bus/cdx: add dma map and unmap support

2023-04-13 Thread Nipun Gupta
CDX bus can use VFIO interface for mapping and unmapping
of DMA addresses in the IOMMU. This change adds the callback
support for map and unmap APIs as well as fetching the IOMMU
class.

Signed-off-by: Nipun Gupta 
---
 drivers/bus/cdx/cdx.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/drivers/bus/cdx/cdx.c b/drivers/bus/cdx/cdx.c
index bb23b32312..b1d8f8382f 100644
--- a/drivers/bus/cdx/cdx.c
+++ b/drivers/bus/cdx/cdx.c
@@ -506,12 +506,52 @@ cdx_find_device(const struct rte_device *start, 
rte_dev_cmp_t cmp,
return NULL;
 }
 
+static int
+cdx_dma_map(struct rte_device *dev, void *addr, uint64_t iova, size_t len)
+{
+   struct rte_cdx_device *cdx_dev = RTE_DEV_TO_CDX_DEV(dev);
+
+   if (!cdx_dev) {
+   rte_errno = EINVAL;
+   return -1;
+   }
+
+   return rte_vfio_container_dma_map(RTE_VFIO_DEFAULT_CONTAINER_FD,
+ (uintptr_t)addr, iova, len);
+}
+
+static int
+cdx_dma_unmap(struct rte_device *dev, void *addr, uint64_t iova, size_t len)
+{
+   struct rte_cdx_device *cdx_dev = RTE_DEV_TO_CDX_DEV(dev);
+
+   if (!cdx_dev) {
+   rte_errno = EINVAL;
+   return -1;
+   }
+
+   return rte_vfio_container_dma_unmap(RTE_VFIO_DEFAULT_CONTAINER_FD,
+   (uintptr_t)addr, iova, len);
+}
+
+static enum rte_iova_mode
+cdx_get_iommu_class(void)
+{
+   if (TAILQ_EMPTY(&rte_cdx_bus.device_list))
+   return RTE_IOVA_DC;
+
+   return RTE_IOVA_VA;
+}
+
 struct rte_cdx_bus rte_cdx_bus = {
.bus = {
.scan = cdx_scan,
.probe = cdx_probe,
.find_device = cdx_find_device,
.parse = cdx_parse,
+   .dma_map = cdx_dma_map,
+   .dma_unmap = cdx_dma_unmap,
+   .get_iommu_class = cdx_get_iommu_class,
},
.device_list = TAILQ_HEAD_INITIALIZER(rte_cdx_bus.device_list),
.driver_list = TAILQ_HEAD_INITIALIZER(rte_cdx_bus.driver_list),
-- 
2.17.1



[PATCH v2 0/6] add support for CDX bus

2023-04-13 Thread Nipun Gupta
Support AMD CDX bus, for FPGA based CDX devices. The CDX 
devices are memory mapped on system bus for embedded CPUs.

It uses sysfs interface and the vfio-cdx driver to discover
and initialize the CDX devices.

The patches are intended for DPDK 23.07 release, and have been sent
as an RFC as patches are yet to be merged in Linux.

The CDX bus and VFIO support is available at Xilinx open source tree:
https://github.com/Xilinx/linux-xlnx (drivers/cdx/ and drivers/vfio/cdx)

Linux CDX bus patches has been added into linux next:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/cdx

VFIO patches are also submitted in upstream:
https://www.spinics.net/lists/kvm/msg310623.html

CDX is a Hardware Architecture designed for AMD FPGA devices. It
consists of mechanism for interaction between FPGA, Firmware and 
the APUs (Application CPUs).
Firmware resides on RPU (Realtime CPUs) which interacts with
the FPGA program manager and the APUs. The RPU provides memory-mapped
interface (RPU if) which is used to communicate with APUs.

VFIO CDX driver provides the CDX device resources like MMIO and interrupts
to map to user-space. DPDK CDX bus uses sysfs interface and the vfio-cdx
driver to discover and initialize the CDX devices for user-space
applications.

Changes v1->v2:
- Moved file rte_cdx_bus.h to internal bus_cdx_driver.h
  and added this file to deivce_cdx_headers
- Moved cdx.h to private.h
- Removed rte_ prefix from the static symbols in .c files.

Changes RFC->v1:
- Marked few API's as internal which were not required
  to be provided to user.

Nipun Gupta (6):
  bus/cdx: introduce cdx bus
  bus/cdx: add dma map and unmap support
  bus/cdx: add support for MSI
  bus/cdx: support plug unplug and dev iterator
  bus: enable cdx bus
  config/arm: add AMD CDX

 MAINTAINERS|   5 +
 config/arm/arm64_cdx_linux_gcc |  17 +
 config/arm/meson.build |  14 +
 drivers/bus/cdx/bus_cdx_driver.h   | 227 
 drivers/bus/cdx/cdx.c  | 694 +
 drivers/bus/cdx/cdx_logs.h |  37 ++
 drivers/bus/cdx/cdx_vfio.c | 619 ++
 drivers/bus/cdx/meson.build|  12 +
 drivers/bus/cdx/private.h  |  49 ++
 drivers/bus/cdx/version.map|  13 +
 drivers/bus/meson.build|   1 +
 lib/eal/common/eal_common_interrupts.c |  21 +
 lib/eal/common/eal_interrupts.h|   1 +
 lib/eal/include/rte_interrupts.h   |  32 ++
 lib/eal/version.map|   2 +
 15 files changed, 1744 insertions(+)
 create mode 100644 config/arm/arm64_cdx_linux_gcc
 create mode 100644 drivers/bus/cdx/bus_cdx_driver.h
 create mode 100644 drivers/bus/cdx/cdx.c
 create mode 100644 drivers/bus/cdx/cdx_logs.h
 create mode 100644 drivers/bus/cdx/cdx_vfio.c
 create mode 100644 drivers/bus/cdx/meson.build
 create mode 100644 drivers/bus/cdx/private.h
 create mode 100644 drivers/bus/cdx/version.map

-- 
2.17.1



[PATCH v2 4/6] bus/cdx: support plug unplug and dev iterator

2023-04-13 Thread Nipun Gupta
This change adds support for plugging and unplugging
CDX devices on the CDX bus. Also, CDX dev iterator support
has been added for the CDX bus.

Signed-off-by: Nipun Gupta 
---
 drivers/bus/cdx/bus_cdx_driver.h |   1 +
 drivers/bus/cdx/cdx.c| 122 +++
 2 files changed, 123 insertions(+)

diff --git a/drivers/bus/cdx/bus_cdx_driver.h b/drivers/bus/cdx/bus_cdx_driver.h
index fdeaf46664..3d89e7c054 100644
--- a/drivers/bus/cdx/bus_cdx_driver.h
+++ b/drivers/bus/cdx/bus_cdx_driver.h
@@ -69,6 +69,7 @@ struct rte_cdx_id {
 struct rte_cdx_device {
RTE_TAILQ_ENTRY(rte_cdx_device) next;   /**< Next probed CDX device. */
struct rte_device device;   /**< Inherit core device */
+   struct rte_cdx_driver *driver;  /**< CDX driver used in probing 
*/
struct rte_cdx_id id;   /**< CDX ID. */
struct rte_mem_resource mem_resource[CDX_MAX_RESOURCE];
/**< CDX Memory Resource */
diff --git a/drivers/bus/cdx/cdx.c b/drivers/bus/cdx/cdx.c
index f34736a54a..e69ee503aa 100644
--- a/drivers/bus/cdx/cdx.c
+++ b/drivers/bus/cdx/cdx.c
@@ -68,6 +68,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -82,6 +83,15 @@
 #define CDX_BUS_NAME   cdx
 #define CDX_DEV_PREFIX "cdx-"
 
+enum cdx_params {
+   RTE_CDX_PARAM_NAME,
+};
+
+static const char * const cdx_params_keys[] = {
+   [RTE_CDX_PARAM_NAME] = "name",
+   NULL,
+};
+
 /**
  * @file
  * CDX probing using Linux sysfs.
@@ -400,6 +410,7 @@ cdx_probe_one_driver(struct rte_cdx_driver *dr,
} else {
dev->device.driver = &dr->driver;
}
+   dev->driver = dr;
 
return ret;
 
@@ -517,6 +528,71 @@ cdx_find_device(const struct rte_device *start, 
rte_dev_cmp_t cmp,
return NULL;
 }
 
+/* Remove a device from CDX bus */
+static void
+cdx_remove_device(struct rte_cdx_device *cdx_dev)
+{
+   TAILQ_REMOVE(&rte_cdx_bus.device_list, cdx_dev, next);
+}
+
+/*
+ * If vendor/device ID match, call the remove() function of the
+ * driver.
+ */
+static int
+cdx_detach_dev(struct rte_cdx_device *dev)
+{
+   struct rte_cdx_driver *dr;
+   int ret = 0;
+
+   if (dev == NULL)
+   return -EINVAL;
+
+   dr = dev->driver;
+
+   CDX_BUS_DEBUG("detach device %s using driver: %s",
+   dev->device.name, dr->driver.name);
+
+   if (dr->remove) {
+   ret = dr->remove(dev);
+   if (ret < 0)
+   return ret;
+   }
+
+   /* clear driver structure */
+   dev->driver = NULL;
+   dev->device.driver = NULL;
+
+   rte_cdx_unmap_device(dev);
+
+   rte_intr_instance_free(dev->intr_handle);
+   dev->intr_handle = NULL;
+
+   return 0;
+}
+
+static int
+cdx_plug(struct rte_device *dev)
+{
+   return cdx_probe_all_drivers(RTE_DEV_TO_CDX_DEV(dev));
+}
+
+static int
+cdx_unplug(struct rte_device *dev)
+{
+   struct rte_cdx_device *cdx_dev;
+   int ret;
+
+   cdx_dev = RTE_DEV_TO_CDX_DEV(dev);
+   ret = cdx_detach_dev(cdx_dev);
+   if (ret == 0) {
+   cdx_remove_device(cdx_dev);
+   rte_devargs_remove(dev->devargs);
+   free(cdx_dev);
+   }
+   return ret;
+}
+
 static int
 cdx_dma_map(struct rte_device *dev, void *addr, uint64_t iova, size_t len)
 {
@@ -554,15 +630,61 @@ cdx_get_iommu_class(void)
return RTE_IOVA_VA;
 }
 
+static int
+cdx_dev_match(const struct rte_device *dev,
+   const void *_kvlist)
+{
+   const struct rte_kvargs *kvlist = _kvlist;
+   const char *key = cdx_params_keys[RTE_CDX_PARAM_NAME];
+   const char *name;
+
+   /* no kvlist arg, all devices match */
+   if (kvlist == NULL)
+   return 0;
+
+   /* if key is present in kvlist and does not match, filter device */
+   name = rte_kvargs_get(kvlist, key);
+   if (name != NULL && strcmp(name, dev->name))
+   return -1;
+
+   return 0;
+}
+
+static void *
+cdx_dev_iterate(const void *start,
+   const char *str,
+   const struct rte_dev_iterator *it __rte_unused)
+{
+   rte_bus_find_device_t find_device;
+   struct rte_kvargs *kvargs = NULL;
+   struct rte_device *dev;
+
+   if (str != NULL) {
+   kvargs = rte_kvargs_parse(str, cdx_params_keys);
+   if (kvargs == NULL) {
+   CDX_BUS_ERR("cannot parse argument list %s", str);
+   rte_errno = EINVAL;
+   return NULL;
+   }
+   }
+   find_device = rte_cdx_bus.bus.find_device;
+   dev = find_device(start, cdx_dev_match, kvargs);
+   rte_kvargs_free(kvargs);
+   return dev;
+}
+
 struct rte_cdx_bus rte_cdx_bus = {
.bus = {
.scan = cdx_scan,
.probe = cdx_probe,
.find_device = cdx_find_device,
+ 

[PATCH v2 1/6] bus/cdx: introduce cdx bus

2023-04-13 Thread Nipun Gupta
CDX bus supports multiple type of devices, which can be
exposed to user-space via vfio-cdx.

vfio-cdx provides the MMIO IO_MEMORY regions as well as the
DMA interface for the device (IOMMU).

This support aims to enable the DPDK to support the cdx
devices in user-space using VFIO interface.

Signed-off-by: Nipun Gupta 
---
 MAINTAINERS  |   5 +
 drivers/bus/cdx/bus_cdx_driver.h | 201 
 drivers/bus/cdx/cdx.c| 521 +++
 drivers/bus/cdx/cdx_logs.h   |  37 +++
 drivers/bus/cdx/cdx_vfio.c   | 437 ++
 drivers/bus/cdx/meson.build  |  13 +
 drivers/bus/cdx/private.h|  49 +++
 drivers/bus/cdx/version.map  |  11 +
 8 files changed, 1274 insertions(+)
 create mode 100644 drivers/bus/cdx/bus_cdx_driver.h
 create mode 100644 drivers/bus/cdx/cdx.c
 create mode 100644 drivers/bus/cdx/cdx_logs.h
 create mode 100644 drivers/bus/cdx/cdx_vfio.c
 create mode 100644 drivers/bus/cdx/meson.build
 create mode 100644 drivers/bus/cdx/private.h
 create mode 100644 drivers/bus/cdx/version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index 8df23e5099..1f9b6af9b9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -569,6 +569,11 @@ M: Parav Pandit 
 M: Xueming Li 
 F: drivers/bus/auxiliary/
 
+CDX bus driver
+M: Nipun Gupta 
+M: Nikhil Agarwal 
+F: drivers/bus/cdx/
+
 Intel FPGA bus
 M: Rosen Xu 
 F: drivers/bus/ifpga/
diff --git a/drivers/bus/cdx/bus_cdx_driver.h b/drivers/bus/cdx/bus_cdx_driver.h
new file mode 100644
index 00..7edcb019eb
--- /dev/null
+++ b/drivers/bus/cdx/bus_cdx_driver.h
@@ -0,0 +1,201 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright (C) 2022-2023, Advanced Micro Devices, Inc.
+ */
+
+#ifndef _BUS_CDX_DRIVER_H_
+#define _BUS_CDX_DRIVER_H_
+
+/**
+ * @file
+ *
+ * CDX bus interface
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Forward declarations */
+struct rte_cdx_device;
+struct rte_cdx_driver;
+
+#define CDX_MAX_RESOURCE 4
+
+/** List of CDX devices */
+RTE_TAILQ_HEAD(rte_cdx_device_list, rte_cdx_device);
+/** List of CDX drivers */
+RTE_TAILQ_HEAD(rte_cdx_driver_list, rte_cdx_driver);
+
+/* CDX Bus iterators */
+#define FOREACH_DEVICE_ON_CDXBUS(p)\
+   RTE_TAILQ_FOREACH(p, &rte_cdx_bus.device_list, next)
+
+#define FOREACH_DRIVER_ON_CDXBUS(p)\
+   RTE_TAILQ_FOREACH(p, &rte_cdx_bus.driver_list, next)
+
+/** Any CDX device identifier (vendor, device) */
+#define RTE_CDX_ANY_ID (0x)
+
+#define RTE_PMD_REGISTER_CDX_TABLE(name, table) \
+static const char DRV_EXP_TAG(name, cdx_tbl_export)[] __rte_used = \
+RTE_STR(table)
+
+/**
+ * A structure describing an ID for a CDX driver. Each driver provides a
+ * table of these IDs for each device that it supports.
+ */
+struct rte_cdx_id {
+   uint16_t vendor_id; /**< Vendor ID. */
+   uint16_t device_id; /**< Device ID. */
+};
+
+/**
+ * A structure describing a CDX device.
+ */
+struct rte_cdx_device {
+   RTE_TAILQ_ENTRY(rte_cdx_device) next;   /**< Next probed CDX device. */
+   struct rte_device device;   /**< Inherit core device */
+   struct rte_cdx_id id;   /**< CDX ID. */
+   struct rte_mem_resource mem_resource[CDX_MAX_RESOURCE];
+   /**< CDX Memory Resource */
+};
+
+/**
+ * @internal
+ * Helper macro for drivers that need to convert to struct rte_cdx_device.
+ */
+#define RTE_DEV_TO_CDX_DEV(ptr) \
+   container_of(ptr, struct rte_cdx_device, device)
+
+#define RTE_DEV_TO_CDX_DEV_CONST(ptr) \
+   container_of(ptr, const struct rte_cdx_device, device)
+
+#define RTE_ETH_DEV_TO_CDX_DEV(eth_dev)
RTE_DEV_TO_CDX_DEV((eth_dev)->device)
+
+#ifdef __cplusplus
+/** C++ macro used to help building up tables of device IDs */
+#define RTE_CDX_DEVICE(vend, dev)  \
+   (vend), \
+   (dev)
+#else
+/** Macro used to help building up tables of device IDs */
+#define RTE_CDX_DEVICE(vend, dev)  \
+   .vendor_id = (vend),\
+   .device_id = (dev)
+#endif
+
+/**
+ * Initialisation function for the driver called during CDX probing.
+ */
+typedef int (rte_cdx_probe_t)(struct rte_cdx_driver *, struct rte_cdx_device 
*);
+
+/**
+ * Uninitialisation function for the driver called during hotplugging.
+ */
+typedef int (rte_cdx_remove_t)(struct rte_cdx_device *);
+
+/**
+ * A structure describing a CDX driver.
+ */
+struct rte_cdx_driver {
+   RTE_TAILQ_ENTRY(rte_cdx_driver) next;   /**< Next in list. */
+   struct rte_driver driver;   /**< Inherit core driver. */
+   struct rte_cdx_bus *bus;/**< CDX bus reference. */
+   rte_cdx_probe_t *probe; /**< Device probe function. */
+   rte_cdx_remove_t *remove;   

[PATCH v2 5/6] bus: enable cdx bus

2023-04-13 Thread Nipun Gupta
enable the compilation of cdx bus

Signed-off-by: Nipun Gupta 
---
 drivers/bus/meson.build | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bus/meson.build b/drivers/bus/meson.build
index 6d2520c543..a78b4283bf 100644
--- a/drivers/bus/meson.build
+++ b/drivers/bus/meson.build
@@ -3,6 +3,7 @@
 
 drivers = [
 'auxiliary',
+'cdx',
 'dpaa',
 'fslmc',
 'ifpga',
-- 
2.17.1



[PATCH v2 6/6] config/arm: add AMD CDX

2023-04-13 Thread Nipun Gupta
Adding support for AMD CDX devices

Signed-off-by: Nipun Gupta 
---
 config/arm/arm64_cdx_linux_gcc | 17 +
 config/arm/meson.build | 14 ++
 2 files changed, 31 insertions(+)
 create mode 100644 config/arm/arm64_cdx_linux_gcc

diff --git a/config/arm/arm64_cdx_linux_gcc b/config/arm/arm64_cdx_linux_gcc
new file mode 100644
index 00..8e6d619dae
--- /dev/null
+++ b/config/arm/arm64_cdx_linux_gcc
@@ -0,0 +1,17 @@
+[binaries]
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-g++']
+ar = 'aarch64-linux-gnu-ar'
+as = 'aarch64-linux-gnu-as'
+strip = 'aarch64-linux-gnu-strip'
+pkgconfig = 'aarch64-linux-gnu-pkg-config'
+pcap-config = ''
+
+[host_machine]
+system = 'linux'
+cpu_family = 'aarch64'
+cpu = 'armv8-a'
+endian = 'little'
+
+[properties]
+platform = 'cdx'
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 5213434ca4..39b8929534 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -305,6 +305,18 @@ soc_bluefield = {
 'numa': false
 }
 
+soc_cdx = {
+'description': 'AMD CDX',
+'implementer': '0x41',
+'part_number': '0xd42',
+'flags': [
+['RTE_MACHINE', '"cdx"'],
+['RTE_MAX_LCORE', 16],
+['RTE_MAX_NUMA_NODES', 1]
+],
+'numa': false
+}
+
 soc_centriq2400 = {
 'description': 'Qualcomm Centriq 2400',
 'implementer': '0x51',
@@ -463,6 +475,7 @@ generic_aarch32: Generic un-optimized build for armv8 
aarch32 execution mode.
 armada:  Marvell ARMADA
 bluefield:   NVIDIA BlueField
 bluefield3:  NVIDIA BlueField-3
+cdx: AMD CDX
 centriq2400: Qualcomm Centriq 2400
 cn9k:Marvell OCTEON 9
 cn10k:   Marvell OCTEON 10
@@ -490,6 +503,7 @@ socs = {
 'armada': soc_armada,
 'bluefield': soc_bluefield,
 'bluefield3': soc_bluefield3,
+'cdx': soc_cdx,
 'centriq2400': soc_centriq2400,
 'cn9k': soc_cn9k,
 'cn10k' : soc_cn10k,
-- 
2.17.1



RE: [PATCH v2 1/3] eal: add x86 cpuid support for monitorx

2023-04-13 Thread Tummala, Sivaprasad
[AMD Official Use Only - General]

Hi David, 

> -Original Message-
> From: David Marchand 
> Sent: Thursday, April 13, 2023 5:30 PM
> To: Tummala, Sivaprasad 
> Cc: david.h...@intel.com; dev@dpdk.org; Thomas Monjalon
> ; Burakov, Anatoly 
> Subject: Re: [PATCH v2 1/3] eal: add x86 cpuid support for monitorx
> 
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
> 
> 
> On Thu, Apr 13, 2023 at 1:54 PM Sivaprasad Tummala
>  wrote:
> >
> > Add a new CPUID flag to indicate support for monitorx instruction on
> > AMD Epyc processors.
> >
> > Signed-off-by: Sivaprasad Tummala 
> > ---
> >  lib/eal/include/generic/rte_cpuflags.h | 2 ++
> >  lib/eal/x86/include/rte_cpuflags.h | 1 +
> >  lib/eal/x86/rte_cpuflags.c | 3 +++
> >  3 files changed, 6 insertions(+)
> >
> > diff --git a/lib/eal/include/generic/rte_cpuflags.h
> > b/lib/eal/include/generic/rte_cpuflags.h
> > index d35551e931..db653a8dd7 100644
> > --- a/lib/eal/include/generic/rte_cpuflags.h
> > +++ b/lib/eal/include/generic/rte_cpuflags.h
> > @@ -26,6 +26,8 @@ struct rte_cpu_intrinsics {
> > /**< indicates support for rte_power_pause function */
> > uint32_t power_monitor_multi : 1;
> > /**< indicates support for rte_power_monitor_multi function */
> > +   uint32_t amd_power_monitorx : 1;
> > +   /**< indicates amd support for rte_power_monitor function */
> 
> I did not look at the patch detail, I just stopped at this part.
> What makes the AMD monitorx stuff special that it needs to be exposed in the
> generic API?

Monitorx is different ISA /opcode (0F 01 FA) as compared to UMonitor (0F 01 
C8). This need to be distinguished 
on specific x86 platforms. Hence in the current power intrinsics, for x86 we 
require a new flag to 
distinguish MonitorX and UMonitor and invoke the appropriate x86 ISA in the 
datapath.

Thanks & Regards,
Sivaprasad


[RFC PATCH 0/1] add DTS smoke tests

2023-04-13 Thread jspewock
From: Jeremy Spewock 

This patch series adds a set of smoke tests to be run at
the beginning of DTS execution. The point is to validate
the user’s setup before running “real” tests. This helps
save time by bailing out of DTS early when the setup is
not valid, and also prevents DTS displaying “false failures”
associated with an incorrect DTS setup.

More specificially, these tests will verify the following:
* DPDK fast-tests suite
* DPDK driver-test suite
* Devices are bound to the correct driver
* General information about the SUT (kernel version, compiler version,
etc.)
* DPDK testpmd starts, stops, and receives packets

Jeremy Spewock (1):
  dts: add smoke tests

 dts/conf.yaml  |  7 ++-
 dts/framework/config/__init__.py   | 15 ++
 dts/framework/config/conf_yaml_schema.json | 16 +-
 dts/framework/dts.py   | 19 ++-
 dts/framework/exception.py | 11 
 dts/framework/test_result.py   | 13 +++--
 dts/framework/test_suite.py| 24 -
 dts/tests/TestSuite_smoke_tests.py | 63 ++
 8 files changed, 159 insertions(+), 9 deletions(-)
 create mode 100644 dts/tests/TestSuite_smoke_tests.py

-- 
2.40.0



[RFC PATCH 1/1] dts: add smoke tests

2023-04-13 Thread jspewock
From: Jeremy Spewock 

Adds a new test suite for running smoke tests that verify general
configuration aspects of the system under test. If any of these tests
fail, the DTS execution terminates as part of a "fail-fast" model.

Signed-off-by: Jeremy Spewock 
---
 dts/conf.yaml  |  7 ++-
 dts/framework/config/__init__.py   | 15 ++
 dts/framework/config/conf_yaml_schema.json | 16 +-
 dts/framework/dts.py   | 19 ++-
 dts/framework/exception.py | 11 
 dts/framework/test_result.py   | 13 +++--
 dts/framework/test_suite.py| 24 -
 dts/tests/TestSuite_smoke_tests.py | 63 ++
 8 files changed, 159 insertions(+), 9 deletions(-)
 create mode 100644 dts/tests/TestSuite_smoke_tests.py

diff --git a/dts/conf.yaml b/dts/conf.yaml
index a9bd8a3e..8caef719 100644
--- a/dts/conf.yaml
+++ b/dts/conf.yaml
@@ -10,13 +10,18 @@ executions:
 compiler_wrapper: ccache
 perf: false
 func: true
+nic: #physical devices to be used for testing
+  address: ":00:10.1"
+  driver: "vfio-pci"
 test_suites:
+  - smoke_tests
   - hello_world
 system_under_test: "SUT 1"
 nodes:
   - name: "SUT 1"
-hostname: sut1.change.me.localhost
+hostname: host.example.name
 user: root
+password: ""
 arch: x86_64
 os: linux
 lcores: ""
diff --git a/dts/framework/config/__init__.py b/dts/framework/config/__init__.py
index ebb0823f..78d23422 100644
--- a/dts/framework/config/__init__.py
+++ b/dts/framework/config/__init__.py
@@ -106,6 +106,18 @@ def from_dict(d: dict) -> "NodeConfiguration":
 hugepages=hugepage_config,
 )
 
+@dataclass(slots=True, frozen=True)
+class NICConfiguration:
+address: str
+driver: str
+
+@staticmethod
+def from_dict(d:dict) -> "NICConfiguration":
+return NICConfiguration(
+address=d.get("address"),
+driver=d.get("driver")
+)
+
 
 @dataclass(slots=True, frozen=True)
 class BuildTargetConfiguration:
@@ -157,6 +169,7 @@ class ExecutionConfiguration:
 func: bool
 test_suites: list[TestSuiteConfig]
 system_under_test: NodeConfiguration
+nic: NICConfiguration
 
 @staticmethod
 def from_dict(d: dict, node_map: dict) -> "ExecutionConfiguration":
@@ -166,6 +179,7 @@ def from_dict(d: dict, node_map: dict) -> 
"ExecutionConfiguration":
 test_suites: list[TestSuiteConfig] = list(
 map(TestSuiteConfig.from_dict, d["test_suites"])
 )
+nic_conf: NICConfiguration = NICConfiguration.from_dict(d['nic'])
 sut_name = d["system_under_test"]
 assert sut_name in node_map, f"Unknown SUT {sut_name} in execution {d}"
 
@@ -174,6 +188,7 @@ def from_dict(d: dict, node_map: dict) -> 
"ExecutionConfiguration":
 perf=d["perf"],
 func=d["func"],
 test_suites=test_suites,
+nic=nic_conf,
 system_under_test=node_map[sut_name],
 )
 
diff --git a/dts/framework/config/conf_yaml_schema.json 
b/dts/framework/config/conf_yaml_schema.json
index ca2d4a1e..c98a9370 100644
--- a/dts/framework/config/conf_yaml_schema.json
+++ b/dts/framework/config/conf_yaml_schema.json
@@ -97,7 +97,8 @@
 "test_suite": {
   "type": "string",
   "enum": [
-"hello_world"
+"hello_world",
+"smoke_tests"
   ]
 },
 "test_target": {
@@ -211,6 +212,19 @@
   ]
 }
   },
+  "nic": {
+"type": "object",
+"properties": {
+  "address": {
+"type":"string",
+"description": "PCI address of a physical device to test"
+  },
+  "driver": {
+"type": "string",
+"description": "The name of the driver that the physical 
device should be bound to"
+  }
+}
+  },
   "system_under_test": {
 "$ref": "#/definitions/node_name"
   }
diff --git a/dts/framework/dts.py b/dts/framework/dts.py
index 05022845..0d03e158 100644
--- a/dts/framework/dts.py
+++ b/dts/framework/dts.py
@@ -5,6 +5,8 @@
 
 import sys
 
+from .exception import BlockingTestSuiteError
+
 from .config import CONFIGURATION, BuildTargetConfiguration, 
ExecutionConfiguration
 from .logger import DTSLOG, getLogger
 from .test_result import BuildTargetResult, DTSResult, ExecutionResult, Result
@@ -49,6 +51,7 @@ def run_all() -> None:
 nodes[sut_node.name] = sut_node
 
 if sut_node:
+#SMOKE TEST EXECUTION GOES HERE!
 _run_execution(sut_node, execution, result)
 
 except Exception as e:
@@ -118,7 +121,7 @@ def _run_build_target(
 
 try:
 sut_node.set_up_build_target(build_target)
-result.dpdk_version = sut_node.dpdk_version
+# result.dpdk_version = sut_node.dpdk_version
 

[PATCH] usertools: add tool to generate balanced rss traffic flows

2023-04-13 Thread Robin Jarry
From: 6WIND 

usage: dpdk-rss-flows.py [-h] [-s SPORT_RANGE] [-d DPORT_RANGE] [-r]
 [-k RSS_KEY] [-t RETA_SIZE] [-j]
 RX_QUEUES SRC DST

Craft IP{v6}/{TCP/UDP} traffic flows that will evenly spread over a
given number of RX queues according to the RSS algorithm.

positional arguments:
  RX_QUEUES The number of RX queues to fill.
  SRC   The source IP network/address.
  DST   The destination IP network/address.

options:
  -h, --helpshow this help message and exit
  -s SPORT_RANGE, --sport-range SPORT_RANGE
The layer 4 (TCP/UDP) source port range. Can
be a single fixed value or a range
-.
  -d DPORT_RANGE, --dport-range DPORT_RANGE
The layer 4 (TCP/UDP) destination port range.
Can be a single fixed value or a range
-.
  -r, --check-reverse-traffic
The reversed traffic (source <-> dest) should
also be evenly balanced in the queues.
  -k RSS_KEY, --rss-key RSS_KEY
The random key byte-stream used to compute the
RSS hash. This option supports either a
supported driver name or the hex value of the
key (default: intel).
  -t RETA_SIZE, --reta-size RETA_SIZE
Size of the redirection table or "RETA"
(default: 128).
  -j, --jsonOutput in parseable JSON format.

Examples:

  ~$ dpdk-rss-flows.py 8 28.0.0.0/24 40.0.0.0/24
  SRC_IP  DST_IP   QUEUE
  28.0.0.140.0.0.1 5
  28.0.0.140.0.0.2 4
  28.0.0.140.0.0.3 2
  28.0.0.140.0.0.6 3
  28.0.0.140.0.0.8 0
  28.0.0.140.0.0.9 6
  28.0.0.140.0.0.107
  28.0.0.140.0.0.111

  ~$ dpdk-rss-flows.py 8 28.0.0.0/24 40.0.0.0/24 -r
  SRC_IP  DST_IP   QUEUEQUEUE_REVERSE
  28.0.0.140.0.0.1 53
  28.0.0.140.0.0.2 42
  28.0.0.140.0.0.8 06
  28.0.0.140.0.0.9 67
  28.0.0.140.0.0.1624
  28.0.0.140.0.0.1935
  28.0.0.140.0.0.2410
  28.0.0.140.0.0.2571

  ~$ dpdk-rss-flows.py 8 28.0.0.0/24 40.0.0.0/24 -s 32000-64000 -d 53
  SRC_IP  SPORTDST_IP  DPORTQUEUE
  28.0.0.13200040.0.0.153   0
  28.0.0.13200140.0.0.153   1
  28.0.0.13200440.0.0.153   4
  28.0.0.13200540.0.0.153   5
  28.0.0.13200840.0.0.153   2
  28.0.0.13200940.0.0.153   3
  28.0.0.13201240.0.0.153   6
  28.0.0.13201340.0.0.153   7

  ~$ dpdk-rss-flows.py 4 2a01:cb00:f8b:9700::/64 2620:52:0:2592::/64 -rj
  [
{
  "queue": 0,
  "queue_reverse": 3,
  "src_ip": "2a01:cb00:f8b:9700::1",
  "dst_ip": "2620:52:0:2592::1",
  "src_port": 0,
  "dst_port": 0
},
{
  "queue": 3,
  "queue_reverse": 0,
  "src_ip": "2a01:cb00:f8b:9700::1",
  "dst_ip": "2620:52:0:2592::2",
  "src_port": 0,
  "dst_port": 0
},
{
  "queue": 2,
  "queue_reverse": 1,
  "src_ip": "2a01:cb00:f8b:9700::1",
  "dst_ip": "2620:52:0:2592::3",
  "src_port": 0,
  "dst_port": 0
},
{
  "queue": 1,
  "queue_reverse": 2,
  "src_ip": "2a01:cb00:f8b:9700::1",
  "dst_ip": "2620:52:0:2592::1a",
  "src_port": 0,
  "dst_port": 0
}
  ]

Cc: Olivier Matz 
Cc: Jean-Mickael Guerin 
Signed-off-by: Robin Jarry 
---
 usertools/dpdk-rss-flows.py | 374 
 usertools/meson.build   |   1 +
 2 files changed, 375 insertions(+)
 create mode 100755 usertools/dpdk-rss-flows.py

diff --git a/usertools/dpdk-rss-flows.py b/usertools/dpdk-rss-flows.py
new file mode 100755
index ..080d20b11d2f
--- /dev/null
+++ b/usertools/dpdk-rss-flows.py
@@ -0,0 +1,374 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright (c) 2014 6WIND S.A.
+# Copyright (c) 2023 Robin Jarry
+
+"""
+Craft IP{v6}/{TCP/UDP} traffic flows that will evenly spread over a given
+number of RX queues according to the RSS algorithm.
+"""
+
+import argparse
+import binascii
+import ctypes
+import ipaddress
+import json
+import struct
+import typing
+
+
+NO_PORT = (0,)
+
+# fmt: off
+# rss_intel_key, see drivers/net/ixgbe/ixgbe_rxtx.c
+RSS_KEY_INTEL = bytes(
+(
+0x6D, 0x5A, 0x56, 0xDA, 0x25, 0x5B, 0x0E, 0xC2,
+0x41, 0x67, 0x25, 0x3D, 0x43, 0xA3, 0x8F, 0xB0,
+0xD0, 0xCA, 0x2B, 0xCB, 0xAE, 0x7B, 0x30, 0xB4,
+0x77, 0xCB, 0x2D, 0xA3, 0x80, 0x30, 0xF2, 0x0C,
+0x6A, 0x42, 0xB7, 0x3B, 0xBE, 0xAC, 0x01, 0xFA,
+)
+)
+# rss_hash_default_key, see drivers/net/mlx5/mlx5_rxq.c
+RSS_KEY_MLX = bytes(
+(
+0x2C, 0xC6, 0x81, 

[PATCH v5 02/14] eal: use rtm and xtest intrinsics

2023-04-13 Thread Tyler Retzlaff
Inline assembly is not supported for MSVC x64. Convert code to use
_xend, _xabort and _xtest intrinsics.

Signed-off-by: Tyler Retzlaff 
Acked-by: Bruce Richardson 
Acked-by: Konstantin Ananyev 
---
 config/x86/meson.build|  6 ++
 lib/eal/x86/include/rte_rtm.h | 18 +-
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/config/x86/meson.build b/config/x86/meson.build
index 54345c4..4c0b06c 100644
--- a/config/x86/meson.build
+++ b/config/x86/meson.build
@@ -30,6 +30,12 @@ if cc.get_define('__SSE4_2__', args: machine_args) == ''
 machine_args += '-msse4'
 endif
 
+# enable restricted transactional memory intrinsics
+# https://gcc.gnu.org/onlinedocs/gcc/x86-transactional-memory-intrinsics.html
+if cc.get_id() != 'msvc'
+machine_args += '-mrtm'
+endif
+
 base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
 foreach f:base_flags
 compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
index 36bf498..b84e58e 100644
--- a/lib/eal/x86/include/rte_rtm.h
+++ b/lib/eal/x86/include/rte_rtm.h
@@ -5,6 +5,7 @@
 #ifndef _RTE_RTM_H_
 #define _RTE_RTM_H_ 1
 
+#include 
 
 /* Official RTM intrinsics interface matching gcc/icc, but works
on older gcc compatible compilers and binutils. */
@@ -28,31 +29,22 @@
 static __rte_always_inline
 unsigned int rte_xbegin(void)
 {
-   unsigned int ret = RTE_XBEGIN_STARTED;
-
-   asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
-   return ret;
+   return _xbegin();
 }
 
 static __rte_always_inline
 void rte_xend(void)
 {
-asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+   _xend();
 }
 
 /* not an inline function to workaround a clang bug with -O0 */
-#define rte_xabort(status) do { \
-   asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
-} while (0)
+#define rte_xabort(status) _xabort(status)
 
 static __rte_always_inline
 int rte_xtest(void)
 {
-   unsigned char out;
-
-   asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
-   "=r" (out) :: "memory");
-   return out;
+   return _xtest();
 }
 
 #ifdef __cplusplus
-- 
1.8.3.1



[PATCH v5 03/14] eal: use barrier intrinsics

2023-04-13 Thread Tyler Retzlaff
Inline assembly is not supported for MSVC x64 instead expand
rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
_m_mfence intrinsics.

Signed-off-by: Tyler Retzlaff 
Acked-by: Bruce Richardson 
Acked-by: Konstantin Ananyev 
---
 lib/eal/include/generic/rte_atomic.h | 4 
 lib/eal/x86/include/rte_atomic.h | 4 
 2 files changed, 8 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h 
b/lib/eal/include/generic/rte_atomic.h
index 234b268..e973184 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -116,9 +116,13 @@
  * Guarantees that operation reordering does not occur at compile time
  * for operations directly before and after the barrier.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #definerte_compiler_barrier() do { \
asm volatile ("" : : : "memory");   \
 } while(0)
+#else
+#define rte_compiler_barrier() _ReadWriteBarrier()
+#endif
 
 /**
  * Synchronization fence between threads based on the specified memory order.
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index f2ee1a9..569d3ab 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -66,11 +66,15 @@
 static __rte_always_inline void
 rte_smp_mb(void)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifdef RTE_ARCH_I686
asm volatile("lock addl $0, -128(%%esp); " ::: "memory");
 #else
asm volatile("lock addl $0, -128(%%rsp); " ::: "memory");
 #endif
+#else
+   _mm_mfence();
+#endif
 }
 
 #define rte_io_mb() rte_mb()
-- 
1.8.3.1



[PATCH v5 00/14] msvc integration changes

2023-04-13 Thread Tyler Retzlaff
In accordance with draft plan
http://mails.dpdk.org/archives/web/2023-February/002023.html
introduces conditionally compiled code to enable building with MSVC that
_does not_ require C99/C11 meaning it can be integrated now.

This series covers minimal changes for item #2 in draft plan for EAL
dependencies kvargs, telemetry and consumed EAL public headers.

Note if any patch in the series requires in-depth discussion I'll
detach it from this series for separate submission & more focused
discussion so it doesn't block the entire series.

Note other "common" intrinsics were investigated for viability but
were not adopted either because they were not available on older
versions of gcc or because they generate different code for msvc
vs gcc.

v5:
  * remove accidental line removal in barrier patch
  * update prefetch patch to use intrinsics for all toolchains
  * remove x86 specific changes for byte swap patch since
msvc intrinsics are processor agnostic always use
intrinsics from generic include
  * expand __rte_packed empty for msvc packing will be addressed
in a separate series

v4:
  * update rdtsc patch to use gcc intrinsics
  * update rtm patch to use gcc intrinsics
  * drop patch disable json print formatting, we will utilize
series removing VLAs from Bruce
  * added patch using prefetch intrinsics for msvc
  * added patch using byte swap intrinsics for msvc
  * added patch hiding typdefs for msvc using gcc vector
extension
  * added patch defining MSVC as little endian always

v3:
  * v3 does not group together conditional blocks when experimented
with it didn't reduce conditionals enough to make it worth
while. once msvc tests are at a running point i suggest
a narrow targeted discussion about code organization without
blocking this series
  * v3 does not attempt to refactor to use intrinsics for non-msvc
compilers. again this should be done as a separate follow-up
series later if desired
  * fix expansion of likely and unlikely macros
  * remove unnecessary define for rte_smp_{r,w}mb it is sufficient
for these to be compiler barriers on x86
  * add a new patch to use __cpuid and __cpuidex intrinsics when
building with msvc
  * add a new patch to use _umonitor, _umwait and _tpause intrinsics
when building with msvc

v2:
  * use _mm_{l,s,m}fence intrinsics for rte_smp_{r,w,}mb macros
are intended to be memory barriers not compiler barriers on
x86_64

Tyler Retzlaff (14):
  eal: use rdtsc intrinsic
  eal: use rtm and xtest intrinsics
  eal: use barrier intrinsics
  eal: use cpuid and cpuidex intrinsics
  eal: use umonitor umwait and tpause intrinsics
  eal: use prefetch intrinsics
  eal: use byte swap intrinsics
  eal: typedef cpu flag enum as int
  eal: hide GCC extension based alignment markers
  eal: hide typedefs based on GCC vector extensions
  eal: expand most macros to empty when using MSVC
  eal: exclude exposure of rte atomic APIs for MSVC builds
  telemetry: avoid expanding versioned symbol macros on MSVC
  eal: always define MSVC as little endian

 config/x86/meson.build  |  6 
 lib/eal/include/generic/rte_atomic.h| 11 
 lib/eal/include/generic/rte_byteorder.h | 13 +
 lib/eal/include/generic/rte_cpuflags.h  | 12 
 lib/eal/include/generic/rte_vect.h  |  4 +++
 lib/eal/include/rte_branch_prediction.h |  8 ++
 lib/eal/include/rte_common.h| 49 +
 lib/eal/include/rte_compat.h| 20 ++
 lib/eal/x86/include/rte_atomic.h|  8 ++
 lib/eal/x86/include/rte_byteorder.h |  4 +++
 lib/eal/x86/include/rte_cycles.h| 14 ++
 lib/eal/x86/include/rte_prefetch.h  | 25 ++---
 lib/eal/x86/include/rte_rtm.h   | 18 
 lib/eal/x86/rte_cpuflags.c  |  4 +++
 lib/eal/x86/rte_cpuid.h |  7 +
 lib/eal/x86/rte_cycles.c| 36 
 lib/eal/x86/rte_hypervisor.c|  4 +++
 lib/eal/x86/rte_power_intrinsics.c  | 12 
 lib/telemetry/telemetry_data.c  | 16 +++
 19 files changed, 243 insertions(+), 28 deletions(-)

-- 
1.8.3.1



[PATCH v5 01/14] eal: use rdtsc intrinsic

2023-04-13 Thread Tyler Retzlaff
Inline assembly is not supported for MSVC x64. Convert code to use
__rdtsc intrinsic.

Signed-off-by: Tyler Retzlaff 
Acked-by: Konstantin Ananyev 
---
 lib/eal/x86/include/rte_cycles.h | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
index a461a4d..cca5122 100644
--- a/lib/eal/x86/include/rte_cycles.h
+++ b/lib/eal/x86/include/rte_cycles.h
@@ -6,6 +6,12 @@
 #ifndef _RTE_CYCLES_X86_64_H_
 #define _RTE_CYCLES_X86_64_H_
 
+#ifndef RTE_TOOLCHAIN_MSVC
+#include 
+#else
+#include 
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -23,6 +29,7 @@
 static inline uint64_t
 rte_rdtsc(void)
 {
+#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
union {
uint64_t tsc_64;
RTE_STD_C11
@@ -32,7 +39,6 @@
};
} tsc;
 
-#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
if (unlikely(rte_cycles_vmware_tsc_map)) {
/* ecx = 0x1 corresponds to the physical TSC for VMware */
asm volatile("rdpmc" :
@@ -42,11 +48,7 @@
return tsc.tsc_64;
}
 #endif
-
-   asm volatile("rdtsc" :
-"=a" (tsc.lo_32),
-"=d" (tsc.hi_32));
-   return tsc.tsc_64;
+   return __rdtsc();
 }
 
 static inline uint64_t
-- 
1.8.3.1



[PATCH v5 04/14] eal: use cpuid and cpuidex intrinsics

2023-04-13 Thread Tyler Retzlaff
Inline assembly is not supported for MSVC x64 instead use __cpuid
and __cpuidex intrinsics.

Signed-off-by: Tyler Retzlaff 
---
 lib/eal/x86/rte_cpuflags.c   |  4 
 lib/eal/x86/rte_cpuid.h  |  7 +++
 lib/eal/x86/rte_cycles.c | 36 
 lib/eal/x86/rte_hypervisor.c |  4 
 4 files changed, 51 insertions(+)

diff --git a/lib/eal/x86/rte_cpuflags.c b/lib/eal/x86/rte_cpuflags.c
index d6b5182..e3624e7 100644
--- a/lib/eal/x86/rte_cpuflags.c
+++ b/lib/eal/x86/rte_cpuflags.c
@@ -165,9 +165,13 @@ struct feature_entry {
if (maxleaf < feat->leaf)
return 0;
 
+#ifndef RTE_TOOLCHAIN_MSVC
 __cpuid_count(feat->leaf, feat->subleaf,
 regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+   __cpuidex(regs, feat->leaf, feat->subleaf);
+#endif
 
/* check if the feature is enabled */
return (regs[feat->reg] >> feat->bit) & 1;
diff --git a/lib/eal/x86/rte_cpuid.h b/lib/eal/x86/rte_cpuid.h
index b773ad9..c6abaad 100644
--- a/lib/eal/x86/rte_cpuid.h
+++ b/lib/eal/x86/rte_cpuid.h
@@ -5,7 +5,9 @@
 #ifndef RTE_CPUID_H
 #define RTE_CPUID_H
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #include 
+#endif
 
 enum cpu_register_t {
RTE_REG_EAX = 0,
@@ -16,4 +18,9 @@ enum cpu_register_t {
 
 typedef uint32_t cpuid_registers_t[4];
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s);
+#endif
+
 #endif /* RTE_CPUID_H */
diff --git a/lib/eal/x86/rte_cycles.c b/lib/eal/x86/rte_cycles.c
index 0e695ca..db56d39 100644
--- a/lib/eal/x86/rte_cycles.c
+++ b/lib/eal/x86/rte_cycles.c
@@ -4,7 +4,11 @@
 
 #include 
 #include 
+#ifndef RTE_TOOLCHAIN_MSVC
 #include 
+#else
+#define bit_AVX (1 << 28)
+#endif
 
 
 #include "eal_private.h"
@@ -82,9 +86,25 @@
return 0;
 }
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s)
+{
+   uint32_t cpuinfo[4];
+
+   __cpuid(cpuinfo, e);
+   if (s)
+   *s = cpuinfo[1];
+   return cpuinfo[0];
+}
+#endif
+
 uint64_t
 get_tsc_freq_arch(void)
 {
+#ifdef RTE_TOOLCHAIN_MSVC
+   int cpuinfo[4];
+#endif
uint64_t tsc_hz = 0;
uint32_t a, b, c, d, maxleaf;
uint8_t mult, model;
@@ -97,14 +117,30 @@
maxleaf = __get_cpuid_max(0, NULL);
 
if (maxleaf >= 0x15) {
+#ifndef RTE_TOOLCHAIN_MSVC
__cpuid(0x15, a, b, c, d);
+#else
+   __cpuid(cpuinfo, 0x15);
+   a = cpuinfo[0];
+   b = cpuinfo[1];
+   c = cpuinfo[2];
+   d = cpuinfo[3];
+#endif
 
/* EBX : TSC/Crystal ratio, ECX : Crystal Hz */
if (b && c)
return c * (b / a);
}
 
+#ifndef RTE_TOOLCHAIN_MSVC
__cpuid(0x1, a, b, c, d);
+#else
+   __cpuid(cpuinfo, 0x1);
+   a = cpuinfo[0];
+   b = cpuinfo[1];
+   c = cpuinfo[2];
+   d = cpuinfo[3];
+#endif
model = rte_cpu_get_model(a);
 
if (check_model_wsm_nhm(model))
diff --git a/lib/eal/x86/rte_hypervisor.c b/lib/eal/x86/rte_hypervisor.c
index c38cfc0..a9c2017 100644
--- a/lib/eal/x86/rte_hypervisor.c
+++ b/lib/eal/x86/rte_hypervisor.c
@@ -23,9 +23,13 @@ enum rte_hypervisor
if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_HYPERVISOR))
return RTE_HYPERVISOR_NONE;
 
+#ifndef RTE_TOOLCHAIN_MSVC
__cpuid(HYPERVISOR_INFO_LEAF,
regs[RTE_REG_EAX], regs[RTE_REG_EBX],
regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+   __cpuid(regs, HYPERVISOR_INFO_LEAF);
+#endif
for (reg = 1; reg < 4; reg++)
memcpy(name + (reg - 1) * 4, ®s[reg], 4);
name[12] = '\0';
-- 
1.8.3.1



[PATCH v5 05/14] eal: use umonitor umwait and tpause intrinsics

2023-04-13 Thread Tyler Retzlaff
Inline assembly is not supported for MSVC x64 instead use _umonitor,
_umwait and _tpause intrinsics.

Signed-off-by: Tyler Retzlaff 
---
 lib/eal/x86/rte_power_intrinsics.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/lib/eal/x86/rte_power_intrinsics.c 
b/lib/eal/x86/rte_power_intrinsics.c
index f749da9..7d83c24 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -109,9 +109,13 @@
 */
 
/* set address for UMONITOR */
+#ifndef RTE_TOOLCHAIN_MSVC
asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
:
: "D"(pmc->addr));
+#else
+   _umonitor(pmc->addr);
+#endif
 
/* now that we've put this address into monitor, we can unlock */
rte_spinlock_unlock(&s->lock);
@@ -123,10 +127,14 @@
goto end;
 
/* execute UMWAIT */
+#ifndef RTE_TOOLCHAIN_MSVC
asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
: /* ignore rflags */
: "D"(0), /* enter C0.2 */
  "a"(tsc_l), "d"(tsc_h));
+#else
+   _umwait(tsc_l, tsc_h);
+#endif
 
 end:
/* erase sleep address */
@@ -153,10 +161,14 @@
return -ENOTSUP;
 
/* execute TPAUSE */
+#ifndef RTE_TOOLCHAIN_MSVC
asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
: /* ignore rflags */
: "D"(0), /* enter C0.2 */
"a"(tsc_l), "d"(tsc_h));
+#else
+   _tpause(tsc_l, tsc_h);
+#endif
 
return 0;
 }
-- 
1.8.3.1



[PATCH v5 07/14] eal: use byte swap intrinsics

2023-04-13 Thread Tyler Retzlaff
Inline assembly is not supported for MSVC x64 instead expand
use _byteswap_u{ushort,ulong,uint64} intrinsics instead.

Signed-off-by: Tyler Retzlaff 
---
 lib/eal/include/generic/rte_byteorder.h | 11 +++
 lib/eal/x86/include/rte_byteorder.h |  4 
 2 files changed, 15 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h 
b/lib/eal/include/generic/rte_byteorder.h
index a67e1d7..1e32a1b 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -234,6 +234,7 @@
 #endif /* __DOXYGEN__ */
 
 #ifdef RTE_FORCE_INTRINSICS
+#ifndef RTE_TOOLCHAIN_MSVC
 #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)
 #define rte_bswap16(x) __builtin_bswap16(x)
 #endif
@@ -241,6 +242,16 @@
 #define rte_bswap32(x) __builtin_bswap32(x)
 
 #define rte_bswap64(x) __builtin_bswap64(x)
+#else
+/*
+ * note: we may want to #pragma intrsinsic(_byteswap_u{short,long,uint64})
+ */
+#define rte_bswap16(x) _byteswap_ushort(x)
+
+#define rte_bswap32(x) _byteswap_ulong(x)
+
+#define rte_bswap64(x) _byteswap_uint64(x)
+#endif
 
 #endif
 
diff --git a/lib/eal/x86/include/rte_byteorder.h 
b/lib/eal/x86/include/rte_byteorder.h
index a2dfecc..3d6e58e 100644
--- a/lib/eal/x86/include/rte_byteorder.h
+++ b/lib/eal/x86/include/rte_byteorder.h
@@ -18,6 +18,7 @@
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 
+#ifndef RTE_TOOLCHAIN_MSVC
 /*
  * An architecture-optimized byte swap for a 16-bit value.
  *
@@ -69,6 +70,7 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
   rte_arch_bswap16(x)))
 #endif
 #endif
+#endif
 
 #define rte_cpu_to_le_16(x) (x)
 #define rte_cpu_to_le_32(x) (x)
@@ -86,11 +88,13 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 #define rte_be_to_cpu_32(x) rte_bswap32(x)
 #define rte_be_to_cpu_64(x) rte_bswap64(x)
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifdef RTE_ARCH_I686
 #include "rte_byteorder_32.h"
 #else
 #include "rte_byteorder_64.h"
 #endif
+#endif
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1



[PATCH v5 06/14] eal: use prefetch intrinsics

2023-04-13 Thread Tyler Retzlaff
Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
and _mm_cldemote intrinsics.

Signed-off-by: Tyler Retzlaff 
---
 lib/eal/x86/include/rte_prefetch.h | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/lib/eal/x86/include/rte_prefetch.h 
b/lib/eal/x86/include/rte_prefetch.h
index 7fd01c4..239e611 100644
--- a/lib/eal/x86/include/rte_prefetch.h
+++ b/lib/eal/x86/include/rte_prefetch.h
@@ -9,30 +9,38 @@
 extern "C" {
 #endif
 
+#include 
+
 #include 
 #include 
 #include "generic/rte_prefetch.h"
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wcast-qual"
+
 static inline void rte_prefetch0(const volatile void *p)
 {
-   asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char 
*)p));
+   _mm_prefetch((const void *)p, _MM_HINT_T0);
 }
 
 static inline void rte_prefetch1(const volatile void *p)
 {
-   asm volatile ("prefetcht1 %[p]" : : [p] "m" (*(const volatile char 
*)p));
+   _mm_prefetch((const void *)p, _MM_HINT_T1);
 }
 
 static inline void rte_prefetch2(const volatile void *p)
 {
-   asm volatile ("prefetcht2 %[p]" : : [p] "m" (*(const volatile char 
*)p));
+   _mm_prefetch((const void *)p, _MM_HINT_T2);
 }
 
 static inline void rte_prefetch_non_temporal(const volatile void *p)
 {
-   asm volatile ("prefetchnta %[p]" : : [p] "m" (*(const volatile char 
*)p));
+   _mm_prefetch((const void *)p, _MM_HINT_NTA);
 }
 
+#pragma GCC diagnostic pop
+
+#ifndef RTE_TOOLCHAIN_MSVC
 /*
  * We use raw byte codes for now as only the newest compiler
  * versions support this instruction natively.
@@ -43,6 +51,15 @@ static inline void rte_prefetch_non_temporal(const volatile 
void *p)
 {
asm volatile(".byte 0x0f, 0x1c, 0x06" :: "S" (p));
 }
+#else
+__rte_experimental
+static inline void
+rte_cldemote(const volatile void *p)
+{
+   _mm_cldemote(p);
+}
+#endif
+
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1



[PATCH v5 09/14] eal: hide GCC extension based alignment markers

2023-04-13 Thread Tyler Retzlaff
When compiling with MSVC don't expose typedefs used as alignment
markers.

Signed-off-by: Tyler Retzlaff 
---
 lib/eal/include/rte_common.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 15765b4..2f464e3 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -460,6 +460,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), 
used)) func(void)
 
 /*** Structure alignment markers /
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /** Generic marker for any place in a structure. */
 __extension__ typedef void*RTE_MARKER[0];
 /** Marker for 1B alignment in a structure. */
@@ -471,6 +473,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), 
used)) func(void)
 /** Marker for 8B alignment in a structure. */
 __extension__ typedef uint64_t RTE_MARKER64[0];
 
+#endif
+
 /**
  * Combines 32b inputs most significant set bits into the least
  * significant bits to construct a value with the same MSBs as x
-- 
1.8.3.1



[PATCH v5 10/14] eal: hide typedefs based on GCC vector extensions

2023-04-13 Thread Tyler Retzlaff
When compiling with MSVC don't expose typedefs based on GCC vector
extensions.

Signed-off-by: Tyler Retzlaff 
---
 lib/eal/include/generic/rte_vect.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/generic/rte_vect.h 
b/lib/eal/include/generic/rte_vect.h
index 3fec2bf..777510c 100644
--- a/lib/eal/include/generic/rte_vect.h
+++ b/lib/eal/include/generic/rte_vect.h
@@ -17,6 +17,8 @@
 
 #include 
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /* Unsigned vector types */
 
 /**
@@ -186,6 +188,8 @@
  */
 typedef int64_t rte_v256s64_t __attribute__((vector_size(32), aligned(32)));
 
+#endif
+
 /**
  * The max SIMD bitwidth value to limit vector path selection.
  */
-- 
1.8.3.1



[PATCH v5 08/14] eal: typedef cpu flag enum as int

2023-04-13 Thread Tyler Retzlaff
Forward declaration of a enum is a non-standard extension and is not
supported by MSVC. Use an int instead.

Abstract the use of the int/enum rte_cpu_flag_t in function parameter
lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t
identifier.

Remove the use of __extension__ on function prototypes where
rte_cpu_flag_t appeared in parameter lists, it is sufficient to have the
conditionally compiled __extension__ at the non-standard forward
declaration site.

Signed-off-by: Tyler Retzlaff 
---
 lib/eal/include/generic/rte_cpuflags.h | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lib/eal/include/generic/rte_cpuflags.h 
b/lib/eal/include/generic/rte_cpuflags.h
index d35551e..87ab03c 100644
--- a/lib/eal/include/generic/rte_cpuflags.h
+++ b/lib/eal/include/generic/rte_cpuflags.h
@@ -44,8 +44,12 @@ struct rte_cpu_intrinsics {
 /**
  * Enumeration of all CPU features supported
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 __extension__
-enum rte_cpu_flag_t;
+typedef enum rte_cpu_flag_t rte_cpu_flag_t;
+#else
+typedef int rte_cpu_flag_t;
+#endif
 
 /**
  * Get name of CPU flag
@@ -56,9 +60,8 @@ struct rte_cpu_intrinsics {
  * flag name
  * NULL if flag ID is invalid
  */
-__extension__
 const char *
-rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_name(rte_cpu_flag_t feature);
 
 /**
  * Function for checking a CPU flag availability
@@ -70,9 +73,8 @@ struct rte_cpu_intrinsics {
  * 0 if flag is not available
  * -ENOENT if flag is invalid
  */
-__extension__
 int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_enabled(rte_cpu_flag_t feature);
 
 /**
  * This function checks that the currently used CPU supports the CPU features
-- 
1.8.3.1



[PATCH v5 12/14] eal: exclude exposure of rte atomic APIs for MSVC builds

2023-04-13 Thread Tyler Retzlaff
It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of the rte_atomic APIs from day 1.

Signed-off-by: Tyler Retzlaff 
---
 lib/eal/include/generic/rte_atomic.h | 7 +++
 lib/eal/x86/include/rte_atomic.h | 4 
 2 files changed, 11 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h 
b/lib/eal/include/generic/rte_atomic.h
index e973184..1964697 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -131,6 +131,8 @@
 
 /*- 16 bit atomic operations 
-*/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Atomic compare and set.
  *
@@ -1038,8 +1040,11 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 }
 #endif
 
+#endif
+
 /* 128 bit atomic operations 
-*/
 
+
 /**
  * 128-bit integer structure.
  */
@@ -1049,8 +1054,10 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
union {
uint64_t val[2];
 #ifdef RTE_ARCH_64
+#ifndef RTE_TOOLCHAIN_MSVC
__extension__ __int128 int128;
 #endif
+#endif
};
 } __rte_aligned(16) rte_int128_t;
 
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index 569d3ab..adf3309 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -83,6 +83,8 @@
 
 #define rte_io_rmb() rte_compiler_barrier()
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Synchronization fence between threads based on the specified memory order.
  *
@@ -279,6 +281,8 @@ static inline int rte_atomic32_dec_and_test(rte_atomic32_t 
*v)
 #include "rte_atomic_64.h"
 #endif
 
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.8.3.1



[PATCH v5 14/14] eal: always define MSVC as little endian

2023-04-13 Thread Tyler Retzlaff
The MSVC compiler does not target big endian platforms so define
little endian always.

Signed-off-by: Tyler Retzlaff 
---
 lib/eal/include/generic/rte_byteorder.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h 
b/lib/eal/include/generic/rte_byteorder.h
index 1e32a1b..375f118 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -45,6 +45,8 @@
 #define RTE_BYTE_ORDER RTE_BIG_ENDIAN
 #elif defined __LITTLE_ENDIAN__
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
+#elif defined RTE_TOOLCHAIN_MSVC
+#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 #if !defined(RTE_BYTE_ORDER)
 #error Unknown endianness.
-- 
1.8.3.1



[PATCH v5 11/14] eal: expand most macros to empty when using MSVC

2023-04-13 Thread Tyler Retzlaff
For now expand a lot of common rte macros empty. The catch here is we
need to test that most of the macros do what they should but at the same
time they are blocking work needed to bootstrap of the unit tests.

Later we will return and provide (where possible) expansions that work
correctly for msvc and where not possible provide some alternate macros
to achieve the same outcome.

Signed-off-by: Tyler Retzlaff 
---
 lib/eal/include/rte_branch_prediction.h |  8 ++
 lib/eal/include/rte_common.h| 45 +
 lib/eal/include/rte_compat.h| 20 +++
 3 files changed, 73 insertions(+)

diff --git a/lib/eal/include/rte_branch_prediction.h 
b/lib/eal/include/rte_branch_prediction.h
index 0256a9d..d9a0224 100644
--- a/lib/eal/include/rte_branch_prediction.h
+++ b/lib/eal/include/rte_branch_prediction.h
@@ -25,7 +25,11 @@
  *
  */
 #ifndef likely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define likely(x)  __builtin_expect(!!(x), 1)
+#else
+#define likely(x)  (x)
+#endif
 #endif /* likely */
 
 /**
@@ -39,7 +43,11 @@
  *
  */
 #ifndef unlikely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define unlikely(x)__builtin_expect(!!(x), 0)
+#else
+#define unlikely(x)(x)
+#endif
 #endif /* unlikely */
 
 #ifdef __cplusplus
diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 2f464e3..1bdaa2d 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -65,7 +65,11 @@
 /**
  * Force alignment
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_aligned(a) __attribute__((__aligned__(a)))
+#else
+#define __rte_aligned(a)
+#endif
 
 #ifdef RTE_ARCH_STRICT_ALIGN
 typedef uint64_t unaligned_uint64_t __rte_aligned(1);
@@ -80,16 +84,29 @@
 /**
  * Force a structure to be packed
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_packed __attribute__((__packed__))
+#else
+#define __rte_packed
+#endif
 
 /**
  * Macro to mark a type that is not subject to type-based aliasing rules
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_may_alias __attribute__((__may_alias__))
+#else
+#define __rte_may_alias
+#endif
 
 /*** Macro to mark functions and fields scheduled for removal */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_deprecated   __attribute__((__deprecated__))
 #define __rte_deprecated_msg(msg)  __attribute__((__deprecated__(msg)))
+#else
+#define __rte_deprecated
+#define __rte_deprecated_msg(msg)
+#endif
 
 /**
  *  Macro to mark macros and defines scheduled for removal
@@ -110,14 +127,22 @@
 /**
  * Force symbol to be generated even if it appears to be unused.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_used __attribute__((used))
+#else
+#define __rte_used
+#endif
 
 /*** Macros to eliminate unused variable warnings /
 
 /**
  * short definition to mark a function parameter unused
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_unused __attribute__((__unused__))
+#else
+#define __rte_unused
+#endif
 
 /**
  * Mark pointer as restricted with regard to pointer aliasing.
@@ -141,6 +166,7 @@
  * even if the underlying stdio implementation is ANSI-compliant,
  * so this must be overridden.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #if RTE_CC_IS_GNU
 #define __rte_format_printf(format_index, first_arg) \
__attribute__((format(gnu_printf, format_index, first_arg)))
@@ -148,6 +174,9 @@
 #define __rte_format_printf(format_index, first_arg) \
__attribute__((format(printf, format_index, first_arg)))
 #endif
+#else
+#define __rte_format_printf(format_index, first_arg)
+#endif
 
 /**
  * Tells compiler that the function returns a value that points to
@@ -222,7 +251,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), 
used)) func(void)
 /**
  * Hint never returning function
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_noreturn __attribute__((noreturn))
+#else
+#define __rte_noreturn
+#endif
 
 /**
  * Issue a warning in case the function's return value is ignored.
@@ -247,12 +280,20 @@ static void __attribute__((destructor(RTE_PRIO(prio)), 
used)) func(void)
  *  }
  * @endcode
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_warn_unused_result __attribute__((warn_unused_result))
+#else
+#define __rte_warn_unused_result
+#endif
 
 /**
  * Force a function to be inlined
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_always_inline inline __attribute__((always_inline))
+#else
+#define __rte_always_inline
+#endif
 
 /**
  * Force a function to be noinlined
@@ -437,7 +478,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), 
used)) func(void)
 #define RTE_CACHE_LINE_MIN_SIZE 64
 
 /** Force alignment to cache line. */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
+#else
+#define __rte_cache_aligned
+#endif
 
 /** Force minimum cache line alignment. */
 #define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_LINE_MIN_SIZE)
diff --git a/lib/eal/include/rte_compat.h b/lib/eal/include/rte_compat.h
index fc9fbaa..6a4b5ee 100644
--- a/lib/eal/include/rte_compat.h

[PATCH v5 13/14] telemetry: avoid expanding versioned symbol macros on MSVC

2023-04-13 Thread Tyler Retzlaff
Windows does not support versioned symbols. Fortunately Windows also
doesn't have an exported stable ABI.

Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
functions.

Windows does have a way to achieve similar versioning for symbols but it
is not a simple #define so it will be done as a work package later.

Signed-off-by: Tyler Retzlaff 
Acked-by: Bruce Richardson 
---
 lib/telemetry/telemetry_data.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 2bac2de..284c16e 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -82,8 +82,16 @@
 /* mark the v23 function as the older version, and v24 as the default version 
*/
 VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
int64_t x), rte_tel_data_add_array_int_v24);
+#else
+int
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
+{
+   return rte_tel_data_add_array_int_v24(d, x);
+}
+#endif
 
 int
 rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
@@ -220,8 +228,16 @@
 /* mark the v23 function as the older version, and v24 as the default version 
*/
 VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+#else
+int
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t 
val)
+{
+   return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+#endif
 
 int
 rte_tel_data_add_dict_uint(struct rte_tel_data *d,
-- 
1.8.3.1



[PATCH v1 0/5] fix RX data buffer size

2023-04-13 Thread Wenjun Wu
This patch set fixes RX data buffer size in ice, i40e, iavf and idpf driver.

1. Limit the maximum buffer size to no more than 16K - 128.
2. Align max buffer size to 128, or replace RTE_ALIGN with
RTE_ALIGN_FLOOR according to [1].

[1] Commit c9c45beb1b97 ("net/iavf: fix Rx queue buffer size alignment")

Wenjun Wu (5):
  net/i40e: fix RX data buffer size
  net/ice: fix RX data buffer size
  net/iavf: fix RX data buffer size
  net/idpf: fix RX data buffer size
  net/cpfl: fix RX data buffer size

 drivers/common/idpf/idpf_common_rxtx.h | 3 +++
 drivers/net/cpfl/cpfl_rxtx.c   | 3 ++-
 drivers/net/i40e/i40e_rxtx.c   | 2 ++
 drivers/net/i40e/i40e_rxtx.h   | 3 +++
 drivers/net/iavf/iavf_rxtx.c   | 1 +
 drivers/net/iavf/iavf_rxtx.h   | 3 +++
 drivers/net/ice/ice_dcf_ethdev.c   | 3 ++-
 drivers/net/ice/ice_rxtx.c | 3 ++-
 drivers/net/ice/ice_rxtx.h | 3 +++
 drivers/net/idpf/idpf_rxtx.c   | 6 --
 10 files changed, 25 insertions(+), 5 deletions(-)

-- 
2.34.1



[PATCH v1 1/5] net/i40e: fix RX data buffer size

2023-04-13 Thread Wenjun Wu
No matter what the mbuf size is, the data buffer size should not
be greater than 16K - 128.

Fixes: 4861cde46116 ("i40e: new poll mode driver")
Cc: sta...@dpdk.org

Signed-off-by: Wenjun Wu 
---
 drivers/net/i40e/i40e_rxtx.c | 2 ++
 drivers/net/i40e/i40e_rxtx.h | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 788ffb51c2..fbbefb5015 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -2904,6 +2904,8 @@ i40e_rx_queue_config(struct i40e_rx_queue *rxq)
rxq->rx_hdr_len = 0;
rxq->rx_buf_len = RTE_ALIGN_FLOOR(buf_size,
(1 << I40E_RXQ_CTX_DBUFF_SHIFT));
+   rxq->rx_buf_len = RTE_MIN(rxq->rx_buf_len,
+ I40E_RX_MAX_DATA_BUF_SIZE);
rxq->hs_mode = i40e_header_split_none;
break;
}
diff --git a/drivers/net/i40e/i40e_rxtx.h b/drivers/net/i40e/i40e_rxtx.h
index 5e6eecc501..0376c219be 100644
--- a/drivers/net/i40e/i40e_rxtx.h
+++ b/drivers/net/i40e/i40e_rxtx.h
@@ -21,6 +21,9 @@
 /* In none-PXE mode QLEN must be whole number of 32 descriptors. */
 #defineI40E_ALIGN_RING_DESC32
 
+/* Max data buffer size must be 16K - 128 bytes */
+#define I40E_RX_MAX_DATA_BUF_SIZE  (16 * 1024 - 128)
+
 #defineI40E_MIN_RING_DESC  64
 #defineI40E_MAX_RING_DESC  4096
 
-- 
2.34.1



[PATCH v1 2/5] net/ice: fix RX data buffer size

2023-04-13 Thread Wenjun Wu
This patch does two fixes.

1. No matter what the mbuf size is, the data buffer size should not
be greater than 16K - 128.

2. Replace RTE_ALIGN with RTE_ALIGN_FLOOR according to [1].

[1] Commit c9c45beb1b97 ("net/iavf: fix Rx queue buffer size alignment")

Fixes: 50370662b727 ("net/ice: support device and queue ops")
Fixes: 1b009275e2c8 ("net/ice: add Rx queue init in DCF")
Cc: sta...@dpdk.org

Signed-off-by: Wenjun Wu 
---
 drivers/net/ice/ice_dcf_ethdev.c | 3 ++-
 drivers/net/ice/ice_rxtx.c   | 3 ++-
 drivers/net/ice/ice_rxtx.h   | 3 +++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index dcbf2af5b0..7304ea721c 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -115,7 +115,8 @@ ice_dcf_init_rxq(struct rte_eth_dev *dev, struct 
ice_rx_queue *rxq)
 
buf_size = rte_pktmbuf_data_room_size(rxq->mp) - RTE_PKTMBUF_HEADROOM;
rxq->rx_hdr_len = 0;
-   rxq->rx_buf_len = RTE_ALIGN(buf_size, (1 << ICE_RLAN_CTX_DBUF_S));
+   rxq->rx_buf_len = RTE_ALIGN_FLOOR(buf_size, (1 << ICE_RLAN_CTX_DBUF_S));
+   rxq->rx_buf_len = RTE_MIN(rxq->rx_buf_len, ICE_RX_MAX_DATA_BUF_SIZE);
max_pkt_len = RTE_MIN(ICE_SUPPORT_CHAIN_NUM * rxq->rx_buf_len,
  dev->data->mtu + ICE_ETH_OVERHEAD);
 
diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
index 0ea0045836..560c1a4af7 100644
--- a/drivers/net/ice/ice_rxtx.c
+++ b/drivers/net/ice/ice_rxtx.c
@@ -259,7 +259,8 @@ ice_program_hw_rx_queue(struct ice_rx_queue *rxq)
/* Set buffer size as the head split is disabled. */
buf_size = (uint16_t)(rte_pktmbuf_data_room_size(rxq->mp) -
  RTE_PKTMBUF_HEADROOM);
-   rxq->rx_buf_len = RTE_ALIGN(buf_size, (1 << ICE_RLAN_CTX_DBUF_S));
+   rxq->rx_buf_len = RTE_ALIGN_FLOOR(buf_size, (1 << ICE_RLAN_CTX_DBUF_S));
+   rxq->rx_buf_len = RTE_MIN(rxq->rx_buf_len, ICE_RX_MAX_DATA_BUF_SIZE);
rxq->max_pkt_len =
RTE_MIN((uint32_t)ICE_SUPPORT_CHAIN_NUM * rxq->rx_buf_len,
frame_size);
diff --git a/drivers/net/ice/ice_rxtx.h b/drivers/net/ice/ice_rxtx.h
index 94f6bcf3d1..89569029e1 100644
--- a/drivers/net/ice/ice_rxtx.h
+++ b/drivers/net/ice/ice_rxtx.h
@@ -51,6 +51,9 @@ extern int ice_timestamp_dynfield_offset;
 /* Max header size can be 2K - 64 bytes */
 #define ICE_RX_HDR_BUF_SIZE(2048 - 64)
 
+/* Max data buffer size must be 16K - 128 bytes */
+#define ICE_RX_MAX_DATA_BUF_SIZE   (16 * 1024 - 128)
+
 #define ICE_HEADER_SPLIT_ENA   BIT(0)
 
 typedef void (*ice_rx_release_mbufs_t)(struct ice_rx_queue *rxq);
-- 
2.34.1



[PATCH v1 3/5] net/iavf: fix RX data buffer size

2023-04-13 Thread Wenjun Wu
No matter what the mbuf size is, the data buffer size should not
be greater than 16K - 128.

Fixes: 69dd4c3d0898 ("net/avf: enable queue and device")
Cc: sta...@dpdk.org

Signed-off-by: Wenjun Wu 
---
 drivers/net/iavf/iavf_rxtx.c | 1 +
 drivers/net/iavf/iavf_rxtx.h | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
index b1d0fbceb6..0db3aabd92 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -697,6 +697,7 @@ iavf_dev_rx_queue_setup(struct rte_eth_dev *dev, uint16_t 
queue_idx,
 
len = rte_pktmbuf_data_room_size(rxq->mp) - RTE_PKTMBUF_HEADROOM;
rxq->rx_buf_len = RTE_ALIGN_FLOOR(len, (1 << IAVF_RXQ_CTX_DBUFF_SHIFT));
+   rxq->rx_buf_len = RTE_MIN(rxq->rx_buf_len, IAVF_RX_MAX_DATA_BUF_SIZE);
 
/* Allocate the software ring. */
len = nb_desc + IAVF_RX_MAX_BURST;
diff --git a/drivers/net/iavf/iavf_rxtx.h b/drivers/net/iavf/iavf_rxtx.h
index 09e2127db0..f205a2aaf1 100644
--- a/drivers/net/iavf/iavf_rxtx.h
+++ b/drivers/net/iavf/iavf_rxtx.h
@@ -16,6 +16,9 @@
 /* used for Rx Bulk Allocate */
 #define IAVF_RX_MAX_BURST 32
 
+/* Max data buffer size must be 16K - 128 bytes */
+#define IAVF_RX_MAX_DATA_BUF_SIZE (16 * 1024 - 128)
+
 /* used for Vector PMD */
 #define IAVF_VPMD_RX_MAX_BURST32
 #define IAVF_VPMD_TX_MAX_BURST32
-- 
2.34.1



[PATCH v1 4/5] net/idpf: fix RX data buffer size

2023-04-13 Thread Wenjun Wu
This patch does two fixes.

1. No matter what the mbuf size is, the data buffer size should not
be greater than 16K - 128.

2. Align data buffer size to 128.

Fixes: 9c47c29739a1 ("net/idpf: add Rx queue setup")
Cc: sta...@dpdk.org

Signed-off-by: Wenjun Wu 
---
 drivers/common/idpf/idpf_common_rxtx.h | 3 +++
 drivers/net/idpf/idpf_rxtx.c   | 6 --
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/common/idpf/idpf_common_rxtx.h 
b/drivers/common/idpf/idpf_common_rxtx.h
index 11260d07f9..6cb83fc0a6 100644
--- a/drivers/common/idpf/idpf_common_rxtx.h
+++ b/drivers/common/idpf/idpf_common_rxtx.h
@@ -34,6 +34,9 @@
 #define IDPF_MAX_TSO_FRAME_SIZE262143
 #define IDPF_TX_MAX_MTU_SEG 10
 
+#define IDPF_RLAN_CTX_DBUF_S   7
+#define IDPF_RX_MAX_DATA_BUF_SIZE  (16 * 1024 - 128)
+
 #define IDPF_TX_CKSUM_OFFLOAD_MASK (   \
RTE_MBUF_F_TX_IP_CKSUM |\
RTE_MBUF_F_TX_L4_MASK | \
diff --git a/drivers/net/idpf/idpf_rxtx.c b/drivers/net/idpf/idpf_rxtx.c
index 414f9a37f6..3e3d81ca6d 100644
--- a/drivers/net/idpf/idpf_rxtx.c
+++ b/drivers/net/idpf/idpf_rxtx.c
@@ -155,7 +155,8 @@ idpf_rx_split_bufq_setup(struct rte_eth_dev *dev, struct 
idpf_rx_queue *rxq,
bufq->adapter = adapter;
 
len = rte_pktmbuf_data_room_size(bufq->mp) - RTE_PKTMBUF_HEADROOM;
-   bufq->rx_buf_len = len;
+   bufq->rx_buf_len = RTE_ALIGN_FLOOR(len, (1 << IDPF_RLAN_CTX_DBUF_S));
+   bufq->rx_buf_len = RTE_MIN(bufq->rx_buf_len, IDPF_RX_MAX_DATA_BUF_SIZE);
 
/* Allocate a little more to support bulk allocate. */
len = nb_desc + IDPF_RX_MAX_BURST;
@@ -275,7 +276,8 @@ idpf_rx_queue_setup(struct rte_eth_dev *dev, uint16_t 
queue_idx,
rxq->offloads = idpf_rx_offload_convert(offloads);
 
len = rte_pktmbuf_data_room_size(rxq->mp) - RTE_PKTMBUF_HEADROOM;
-   rxq->rx_buf_len = len;
+   rxq->rx_buf_len = RTE_ALIGN_FLOOR(len, (1 << IDPF_RLAN_CTX_DBUF_S));
+   rxq->rx_buf_len = RTE_MIN(rxq->rx_buf_len, IDPF_RX_MAX_DATA_BUF_SIZE);
 
/* Allocate a little more to support bulk allocate. */
len = nb_desc + IDPF_RX_MAX_BURST;
-- 
2.34.1



[PATCH v1 5/5] net/cpfl: fix RX data buffer size

2023-04-13 Thread Wenjun Wu
This patch does two fixes.

1. No matter what the mbuf size is, the data buffer size should not
be greater than 16K - 128.

2. Align data buffer size to 128.

Signed-off-by: Wenjun Wu 
---
 drivers/net/cpfl/cpfl_rxtx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/cpfl/cpfl_rxtx.c b/drivers/net/cpfl/cpfl_rxtx.c
index de59b31b3d..75021c3c54 100644
--- a/drivers/net/cpfl/cpfl_rxtx.c
+++ b/drivers/net/cpfl/cpfl_rxtx.c
@@ -155,7 +155,8 @@ cpfl_rx_split_bufq_setup(struct rte_eth_dev *dev, struct 
idpf_rx_queue *rxq,
bufq->adapter = base;
 
len = rte_pktmbuf_data_room_size(bufq->mp) - RTE_PKTMBUF_HEADROOM;
-   bufq->rx_buf_len = len;
+   bufq->rx_buf_len = RTE_ALIGN_FLOOR(len, (1 << IDPF_RLAN_CTX_DBUF_S));
+   bufq->rx_buf_len = RTE_MIN(bufq->rx_buf_len, IDPF_RX_MAX_DATA_BUF_SIZE);
 
/* Allocate a little more to support bulk allocate. */
len = nb_desc + IDPF_RX_MAX_BURST;
-- 
2.34.1



Re: Regarding DPDK API's like rte_timer_subsystem_init/rte_hash_create etc. in VPP

2023-04-13 Thread Prashant Upadhyaya
On Fri, Mar 31, 2023 at 4:19 PM Bruce Richardson
 wrote:
>
> On Fri, Mar 31, 2023 at 03:11:18PM +0530, Prashant Upadhyaya wrote:
> > On Thu, Mar 30, 2023 at 7:34 PM Bruce Richardson
> >  wrote:
> > >
> > > On Thu, Mar 30, 2023 at 07:07:23PM +0530, Prashant Upadhyaya wrote:
> > > > On Thu, Mar 30, 2023 at 6:47 PM Bruce Richardson
> > > >  wrote:
> > > > >
> > > > > On Thu, Mar 30, 2023 at 06:42:58PM +0530, Prashant Upadhyaya wrote:
> > > > > > On Thu, Mar 30, 2023 at 2:50 PM Bruce Richardson
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Thu, Mar 30, 2023 at 01:57:52PM +0530, Prashant Upadhyaya 
> > > > > > > wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > >
> > > > > > > FYI, when replying on list, it's best not to top-post, but put 
> > > > > > > your replies
> > > > > > > below the email snippet you are replying to.
> > > > > > >
> > > > > > > > The hash creation API throws the following error --
> > > > > > > > RING: Cannot reserve memory for tailq
> > > > > > > > HASH: memory allocation failed
> > > > > > > >
> > > > > > > > The timer subsystem init api throws this error --
> > > > > > > > EAL: memzone_reserve_aligned_thread_unsafe(): Number of 
> > > > > > > > requested
> > > > > > > > memzone segments exceeds RTE_MAX_MEMZONE
> > > > > > > >
> > > > > > >
> > > > > > > Can you try increasing RTE_MAX_MEMZONE. It' defined in DPDK's 
> > > > > > > rte_config.h
> > > > > > > file, so edit that and then rebuild DPDK. [If you are using the 
> > > > > > > built-in
> > > > > > > DPDK from VPP, you may need to do a patch for this, add it into 
> > > > > > > the VPP
> > > > > > > patches direction and then do a VPP rebuild.]
> > > > > > >
> > > > > > > Let's see if we can get rid of at least one of the error 
> > > > > > > messages. :-)
> > > > > > >
> > > > > > > /Bruce
> > > > > > >
> > > > > > > > I did check the code and apparently the memzone and rte zmalloc
> > > > > > > > related api's are not being able to allocate memory.
> > > > > > > >
> > > > > > > > Regards
> > > > > > > > -Prashant
> > > > > > > >
> > > > > > > > On Thu, Mar 30, 2023 at 1:30 PM Bruce Richardson
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Mar 30, 2023 at 10:30:24AM +0530, Prashant Upadhyaya 
> > > > > > > > > wrote:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > While trying to port some code to VPP (which uses DPDK as 
> > > > > > > > > > the backend
> > > > > > > > > > driver), I am running into a problem that calls to API's 
> > > > > > > > > > like
> > > > > > > > > > rte_timer_subsystem_init, rte_hash_create are failing while 
> > > > > > > > > > allocation
> > > > > > > > > > of memory.
> > > > > > > > > >
> > > > > > > > > > This is presumably because VPP inits the EAL with the 
> > > > > > > > > > following arguments --
> > > > > > > > > >
> > > > > > > > > > -in-memory --no-telemetry --file-prefix vpp
> > > > > > > > > >
> > > > > > > > > > Is  there is something that can be done eg. passing some 
> > > > > > > > > > more parms in
> > > > > > > > > > the EAL initialization which hopefully wouldn't break VPP 
> > > > > > > > > > but will
> > > > > > > > > > also be friendly to the RTE timer and hash functions too, 
> > > > > > > > > > that would
> > > > > > > > > > be great, so requesting some advice here.
> > > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > can you provide some more details on what the errors are that 
> > > > > > > > > you are
> > > > > > > > > receiving? Have you been able to dig a little deeper into 
> > > > > > > > > what might be
> > > > > > > > > causing the memory failures? The above flags alone are 
> > > > > > > > > unlikely to cause
> > > > > > > > > issues with hash or timer libraries, for example.
> > > > > > > > >
> > > > > > > > > /Bruce
> > > > > >
> > > > > > Thanks Bruce, the error comes from the following function in
> > > > > > lib/eal/common/eal_common_memzone.c
> > > > > > memzone_reserve_aligned_thread_unsafe
> > > > > >
> > > > > > The condition which spits out the error is the following
> > > > > > if (arr->count >= arr->len)
> > > > > > So I printed both of the above values inside this function, and the
> > > > > > following output came
> > > > > >
> > > > > > vpp[14728]: dpdk: EAL init args: --in-memory --no-telemetry 
> > > > > > --file-prefix vpp
> > > > > > [New Thread 0x7fffa67b6700 (LWP 14732)]
> > > > > > count: 0 len: 2560
> > > > > > count: 1 len: 2560
> > > > > > count: 2 len: 2560
> > > > > > [New Thread 0x7fffa5fb5700 (LWP 14733)]
> > > > > > [New Thread 0x7fffa5db4700 (LWP 14734)]
> > > > > > count: 3 len: 2560
> > > > > > count: 4 len: 2560
> > > > > > ### this is the place where I call rte_timer_subsystem_init from my
> > > > > > code, the above must be coming from any other code from VPP/EAL 
> > > > > > init,
> > > > > > the line below is surely because of my call to
> > > > > > rte_timer_subsystem_init
> > > > > > count: 0 len: 0
> > > > > >
> > > > > > So as you can see that both values 

[PATCH] examples/ipsec-secgw: fix AES-CTR IV length

2023-04-13 Thread Tejasree Kondoj
Set AES-CTR IV length to 8 in SA config as it is
used for per packet IV length and set it to 16
in xform since the application populates 16B IV
in the datapath. AES-CTR requires 16B IV
constructed from nonce and counter.

Fixes: 5ff7502f345e ("examples/ipsec-secgw: set AES-CTR IV length to 16")

Signed-off-by: Tejasree Kondoj 
---
 examples/ipsec-secgw/sa.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 5f5d2685f6..63eadb3393 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -96,10 +96,8 @@ const struct supported_cipher_algo cipher_algos[] = {
{
.keyword = "aes-128-ctr",
.algo = RTE_CRYPTO_CIPHER_AES_CTR,
-   /* iv_len includes 8B per packet IV, 4B nonce
-* and 4B counter
-*/
-   .iv_len = 16,
+   /* Per packet IV length */
+   .iv_len = 8,
.block_size = 4,
.key_len = 20
},
@@ -1332,9 +1330,14 @@ sa_add_rules(struct sa_ctx *sa_ctx, const struct 
ipsec_sa entries[],
case RTE_CRYPTO_CIPHER_DES_CBC:
case RTE_CRYPTO_CIPHER_3DES_CBC:
case RTE_CRYPTO_CIPHER_AES_CBC:
-   case RTE_CRYPTO_CIPHER_AES_CTR:
iv_length = sa->iv_len;
break;
+   case RTE_CRYPTO_CIPHER_AES_CTR:
+   /* Length includes 8B per packet IV, 4B nonce 
and
+* 4B counter as populated in datapath.
+*/
+   iv_length = 16;
+   break;
default:
RTE_LOG(ERR, IPSEC_ESP,
"unsupported cipher algorithm 
%u\n",
-- 
2.25.1



RE: [PATCH] examples/ipsec-secgw: fix AES-CTR IV length

2023-04-13 Thread Anoob Joseph
> Subject: [PATCH] examples/ipsec-secgw: fix AES-CTR IV length
> 
> Set AES-CTR IV length to 8 in SA config as it is used for per packet IV 
> length and
> set it to 16 in xform since the application populates 16B IV in the datapath. 
> AES-
> CTR requires 16B IV constructed from nonce and counter.
> 
> Fixes: 5ff7502f345e ("examples/ipsec-secgw: set AES-CTR IV length to 16")
> 
> Signed-off-by: Tejasree Kondoj 

Acked-by: Anoob Joseph 




[PATCH] Check whether the driver is compatible with the device presented.

2023-04-13 Thread Rushil Gupta
Change gve_driver_info fields to report DPDK as OS type and DPDK RTE
version as OS version, reserving driver_version fields for GVE driver
version based on features.

This patch is dependent on  
https://patchwork.dpdk.org/project/dpdk/list/?series=27687&state=*

Signed-off-by: Rushil Gupta 
Signed-off-by: Joshua Washington 
Signed-off-by: Junfeng Guo 
Signed-off-by: Jeroen de Borst 
---
 drivers/net/gve/base/gve.h|  3 --
 drivers/net/gve/base/gve_adminq.c | 19 +
 drivers/net/gve/base/gve_adminq.h | 49 ++-
 drivers/net/gve/base/gve_osdep.h  | 36 +
 drivers/net/gve/gve_ethdev.c  | 65 +--
 drivers/net/gve/gve_ethdev.h  |  2 +-
 drivers/net/gve/gve_version.c | 14 +++
 drivers/net/gve/gve_version.h | 25 
 drivers/net/gve/meson.build   |  1 +
 9 files changed, 198 insertions(+), 16 deletions(-)
 create mode 100644 drivers/net/gve/gve_version.c
 create mode 100644 drivers/net/gve/gve_version.h

diff --git a/drivers/net/gve/base/gve.h b/drivers/net/gve/base/gve.h
index 2dc4507acb..89f9654a72 100644
--- a/drivers/net/gve/base/gve.h
+++ b/drivers/net/gve/base/gve.h
@@ -8,9 +8,6 @@
 
 #include "gve_desc.h"
 
-#define GVE_VERSION"1.3.0"
-#define GVE_VERSION_PREFIX "GVE-"
-
 #ifndef GOOGLE_VENDOR_ID
 #define GOOGLE_VENDOR_ID   0x1ae0
 #endif
diff --git a/drivers/net/gve/base/gve_adminq.c 
b/drivers/net/gve/base/gve_adminq.c
index e745b709b2..2e5099a5b0 100644
--- a/drivers/net/gve/base/gve_adminq.c
+++ b/drivers/net/gve/base/gve_adminq.c
@@ -401,6 +401,9 @@ static int gve_adminq_issue_cmd(struct gve_priv *priv,
case GVE_ADMINQ_GET_PTYPE_MAP:
priv->adminq_get_ptype_map_cnt++;
break;
+   case GVE_ADMINQ_VERIFY_DRIVER_COMPATIBILITY:
+   priv->adminq_verify_driver_compatibility_cnt++;
+   break;
default:
PMD_DRV_LOG(ERR, "unknown AQ command opcode %d", opcode);
}
@@ -465,6 +468,22 @@ int gve_adminq_configure_device_resources(struct gve_priv 
*priv,
return gve_adminq_execute_cmd(priv, &cmd);
 }
 
+int gve_adminq_verify_driver_compatibility(struct gve_priv *priv,
+  u64 driver_info_len,
+  dma_addr_t driver_info_addr)
+{
+   union gve_adminq_command cmd;
+
+   memset(&cmd, 0, sizeof(cmd));
+   cmd.opcode = cpu_to_be32(GVE_ADMINQ_VERIFY_DRIVER_COMPATIBILITY);
+   cmd.verify_driver_compatibility = (struct 
gve_adminq_verify_driver_compatibility) {
+   .driver_info_len = cpu_to_be64(driver_info_len),
+   .driver_info_addr = cpu_to_be64(driver_info_addr),
+   };
+
+   return gve_adminq_execute_cmd(priv, &cmd);
+}
+
 int gve_adminq_deconfigure_device_resources(struct gve_priv *priv)
 {
union gve_adminq_command cmd;
diff --git a/drivers/net/gve/base/gve_adminq.h 
b/drivers/net/gve/base/gve_adminq.h
index 05550119de..edac32f031 100644
--- a/drivers/net/gve/base/gve_adminq.h
+++ b/drivers/net/gve/base/gve_adminq.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: MIT
  * Google Virtual Ethernet (gve) driver
- * Copyright (C) 2015-2022 Google, Inc.
+ * Copyright (C) 2015-2023 Google, Inc.
  */
 
 #ifndef _GVE_ADMINQ_H
@@ -23,6 +23,7 @@ enum gve_adminq_opcodes {
GVE_ADMINQ_REPORT_STATS = 0xC,
GVE_ADMINQ_REPORT_LINK_SPEED= 0xD,
GVE_ADMINQ_GET_PTYPE_MAP= 0xE,
+   GVE_ADMINQ_VERIFY_DRIVER_COMPATIBILITY  = 0xF,
 };
 
 /* Admin queue status codes */
@@ -145,6 +146,47 @@ enum gve_sup_feature_mask {
 };
 
 #define GVE_DEV_OPT_LEN_GQI_RAW_ADDRESSING 0x0
+enum gve_driver_capbility {
+   gve_driver_capability_gqi_qpl = 0,
+   gve_driver_capability_gqi_rda = 1,
+   gve_driver_capability_dqo_qpl = 2, /* reserved for future use */
+   gve_driver_capability_dqo_rda = 3,
+};
+
+#define GVE_CAP1(a) BIT((int)a)
+#define GVE_CAP2(a) BIT(((int)a) - 64)
+#define GVE_CAP3(a) BIT(((int)a) - 128)
+#define GVE_CAP4(a) BIT(((int)a) - 192)
+
+#define GVE_DRIVER_CAPABILITY_FLAGS1 \
+   (GVE_CAP1(gve_driver_capability_gqi_qpl) | \
+GVE_CAP1(gve_driver_capability_gqi_rda) | \
+GVE_CAP1(gve_driver_capability_dqo_rda))
+
+#define GVE_DRIVER_CAPABILITY_FLAGS2 0x0
+#define GVE_DRIVER_CAPABILITY_FLAGS3 0x0
+#define GVE_DRIVER_CAPABILITY_FLAGS4 0x0
+
+struct gve_driver_info {
+   u8 os_type; /* 0x05 = DPDK */
+   u8 driver_major;
+   u8 driver_minor;
+   u8 driver_sub;
+   __be32 os_version_major;
+   __be32 os_version_minor;
+   __be32 os_version_sub;
+   __be64 driver_capability_flags[4];
+   u8 os_version_str1[OS_VERSION_STRLEN];
+   u8 os_version_str2[OS_VERSION_STRLEN];
+};
+
+struct gve_adminq_verify_driver_compatibility {
+   __be64 driver_info_len;
+   __be64 driver_info_addr;
+};
+
+GVE_CHECK_STRUCT_LEN(16,  gve_adminq_verify_driver_c

[PATCH] net/gve: Check whether the driver is compatible with the device presented.

2023-04-13 Thread Rushil Gupta
Change gve_driver_info fields to report DPDK as OS type and DPDK RTE
version as OS version, reserving driver_version fields for GVE driver
version based on features.

This patch is dependent on  
https://patchwork.dpdk.org/project/dpdk/list/?series=27687&state=*

Signed-off-by: Rushil Gupta 
Signed-off-by: Joshua Washington 
Signed-off-by: Junfeng Guo 
Signed-off-by: Jeroen de Borst 
---
 drivers/net/gve/base/gve.h|  3 --
 drivers/net/gve/base/gve_adminq.c | 19 +
 drivers/net/gve/base/gve_adminq.h | 49 ++-
 drivers/net/gve/base/gve_osdep.h  | 36 +
 drivers/net/gve/gve_ethdev.c  | 65 +--
 drivers/net/gve/gve_ethdev.h  |  2 +-
 drivers/net/gve/gve_version.c | 14 +++
 drivers/net/gve/gve_version.h | 25 
 drivers/net/gve/meson.build   |  1 +
 9 files changed, 198 insertions(+), 16 deletions(-)
 create mode 100644 drivers/net/gve/gve_version.c
 create mode 100644 drivers/net/gve/gve_version.h

diff --git a/drivers/net/gve/base/gve.h b/drivers/net/gve/base/gve.h
index 2dc4507acb..89f9654a72 100644
--- a/drivers/net/gve/base/gve.h
+++ b/drivers/net/gve/base/gve.h
@@ -8,9 +8,6 @@
 
 #include "gve_desc.h"
 
-#define GVE_VERSION"1.3.0"
-#define GVE_VERSION_PREFIX "GVE-"
-
 #ifndef GOOGLE_VENDOR_ID
 #define GOOGLE_VENDOR_ID   0x1ae0
 #endif
diff --git a/drivers/net/gve/base/gve_adminq.c 
b/drivers/net/gve/base/gve_adminq.c
index e745b709b2..2e5099a5b0 100644
--- a/drivers/net/gve/base/gve_adminq.c
+++ b/drivers/net/gve/base/gve_adminq.c
@@ -401,6 +401,9 @@ static int gve_adminq_issue_cmd(struct gve_priv *priv,
case GVE_ADMINQ_GET_PTYPE_MAP:
priv->adminq_get_ptype_map_cnt++;
break;
+   case GVE_ADMINQ_VERIFY_DRIVER_COMPATIBILITY:
+   priv->adminq_verify_driver_compatibility_cnt++;
+   break;
default:
PMD_DRV_LOG(ERR, "unknown AQ command opcode %d", opcode);
}
@@ -465,6 +468,22 @@ int gve_adminq_configure_device_resources(struct gve_priv 
*priv,
return gve_adminq_execute_cmd(priv, &cmd);
 }
 
+int gve_adminq_verify_driver_compatibility(struct gve_priv *priv,
+  u64 driver_info_len,
+  dma_addr_t driver_info_addr)
+{
+   union gve_adminq_command cmd;
+
+   memset(&cmd, 0, sizeof(cmd));
+   cmd.opcode = cpu_to_be32(GVE_ADMINQ_VERIFY_DRIVER_COMPATIBILITY);
+   cmd.verify_driver_compatibility = (struct 
gve_adminq_verify_driver_compatibility) {
+   .driver_info_len = cpu_to_be64(driver_info_len),
+   .driver_info_addr = cpu_to_be64(driver_info_addr),
+   };
+
+   return gve_adminq_execute_cmd(priv, &cmd);
+}
+
 int gve_adminq_deconfigure_device_resources(struct gve_priv *priv)
 {
union gve_adminq_command cmd;
diff --git a/drivers/net/gve/base/gve_adminq.h 
b/drivers/net/gve/base/gve_adminq.h
index 05550119de..edac32f031 100644
--- a/drivers/net/gve/base/gve_adminq.h
+++ b/drivers/net/gve/base/gve_adminq.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: MIT
  * Google Virtual Ethernet (gve) driver
- * Copyright (C) 2015-2022 Google, Inc.
+ * Copyright (C) 2015-2023 Google, Inc.
  */
 
 #ifndef _GVE_ADMINQ_H
@@ -23,6 +23,7 @@ enum gve_adminq_opcodes {
GVE_ADMINQ_REPORT_STATS = 0xC,
GVE_ADMINQ_REPORT_LINK_SPEED= 0xD,
GVE_ADMINQ_GET_PTYPE_MAP= 0xE,
+   GVE_ADMINQ_VERIFY_DRIVER_COMPATIBILITY  = 0xF,
 };
 
 /* Admin queue status codes */
@@ -145,6 +146,47 @@ enum gve_sup_feature_mask {
 };
 
 #define GVE_DEV_OPT_LEN_GQI_RAW_ADDRESSING 0x0
+enum gve_driver_capbility {
+   gve_driver_capability_gqi_qpl = 0,
+   gve_driver_capability_gqi_rda = 1,
+   gve_driver_capability_dqo_qpl = 2, /* reserved for future use */
+   gve_driver_capability_dqo_rda = 3,
+};
+
+#define GVE_CAP1(a) BIT((int)a)
+#define GVE_CAP2(a) BIT(((int)a) - 64)
+#define GVE_CAP3(a) BIT(((int)a) - 128)
+#define GVE_CAP4(a) BIT(((int)a) - 192)
+
+#define GVE_DRIVER_CAPABILITY_FLAGS1 \
+   (GVE_CAP1(gve_driver_capability_gqi_qpl) | \
+GVE_CAP1(gve_driver_capability_gqi_rda) | \
+GVE_CAP1(gve_driver_capability_dqo_rda))
+
+#define GVE_DRIVER_CAPABILITY_FLAGS2 0x0
+#define GVE_DRIVER_CAPABILITY_FLAGS3 0x0
+#define GVE_DRIVER_CAPABILITY_FLAGS4 0x0
+
+struct gve_driver_info {
+   u8 os_type; /* 0x05 = DPDK */
+   u8 driver_major;
+   u8 driver_minor;
+   u8 driver_sub;
+   __be32 os_version_major;
+   __be32 os_version_minor;
+   __be32 os_version_sub;
+   __be64 driver_capability_flags[4];
+   u8 os_version_str1[OS_VERSION_STRLEN];
+   u8 os_version_str2[OS_VERSION_STRLEN];
+};
+
+struct gve_adminq_verify_driver_compatibility {
+   __be64 driver_info_len;
+   __be64 driver_info_addr;
+};
+
+GVE_CHECK_STRUCT_LEN(16,  gve_adminq_verify_driver_c

Re: [PATCH 1/1] net/gve: update base code for DQO

2023-04-13 Thread Rushil Gupta
I want to highlight that we wish to keep license changes separate from this
patch (probably for 23.11). This patch is to simply support basic
structures for the DQO data path.

On Wed, Apr 12, 2023 at 11:04 AM Rushil Gupta  wrote:

> Sorry for the confusion. I was talking about the same patch (titled
> net/gve: update copyright holders); however, I am not able to find it on
> patchwork.
>
>
> On Wed, Apr 12, 2023 at 9:03 AM Ferruh Yigit  wrote:
>
>> On 4/12/2023 4:42 PM, Rushil Gupta wrote:
>> >
>> >
>> > On Wed, Apr 12, 2023 at 2:41 AM Guo, Junfeng > > > wrote:
>> >
>> >
>> >
>> > > -Original Message-
>> > > From: Ferruh Yigit > > >
>> > > Sent: Wednesday, April 12, 2023 17:35
>> > > To: Guo, Junfeng > > >; Richardson, Bruce
>> > > mailto:bruce.richard...@intel.com>>
>> > > Cc: dev@dpdk.org ; Zhang, Qi Z
>> > mailto:qi.z.zh...@intel.com>>; Rushil Gupta
>> > > mailto:rush...@google.com>>
>> > > Subject: Re: [PATCH 1/1] net/gve: update base code for DQO
>> > >
>> > > On 4/12/2023 10:09 AM, Guo, Junfeng wrote:
>> > > >
>> > > >
>> > > >> -Original Message-
>> > > >> From: Ferruh Yigit > > >
>> > > >> Sent: Wednesday, April 12, 2023 16:50
>> > > >> To: Guo, Junfeng > > >; Richardson, Bruce
>> > > >> mailto:bruce.richard...@intel.com
>> >>
>> > > >> Cc: dev@dpdk.org ; Zhang, Qi Z
>> > mailto:qi.z.zh...@intel.com>>; Rushil Gupta
>> > > >> mailto:rush...@google.com>>
>> > > >> Subject: Re: [PATCH 1/1] net/gve: update base code for DQO
>> > > >>
>> > > >> On 4/11/2023 7:51 AM, Guo, Junfeng wrote:
>> > > >>
>> > > >> Hi Junfeng, message moved down.
>> > > >>
>> > > >>>
>> > >  -Original Message-
>> > >  From: Rushil Gupta > > >
>> > >  Sent: Tuesday, April 11, 2023 12:59
>> > >  To: Zhang, Qi Z > > >; ferruh.yi...@amd.com
>> > 
>> > >  Cc: Richardson, Bruce > > >;
>> > > dev@dpdk.org ;
>> > >  Rushil Gupta > > >; Guo, Junfeng
>> > >  mailto:junfeng@intel.com>>
>> > >  Subject: [PATCH 1/1] net/gve: update base code for DQO
>> > > 
>> > >  Update gve base code to support DQO.
>> > > 
>> > >  This patch is based on this:
>> > > 
>> > >
>> https://patchwork.dpdk.org/project/dpdk/list/?series=27647&state=*
>> > > >
>> > > 
>> > >  Signed-off-by: Rushil Gupta > > >
>> > >  Signed-off-by: Junfeng Guo > > >
>> > > >>> Hi Ferruh & Bruce,
>> > > >>>
>> > > >>> This patch contains few lines change for the MIT licensed gve
>> base
>> > > code.
>> > > >>> Note that there is no new files added, just some minor code
>> > update.
>> > > >>>
>> > > >>> Do we need to ask for special approval from the Tech Board for
>> > this?
>> > > >>> Please help give some advice and also help review this patch.
>> > Thanks!
>> > > >>>
>> > > >>
>> > > >> Once the MIT license exception is in place, as far as I know no
>> > more
>> > > >> approval is required per change.
>> > > >
>> > > > Got it, thanks the comment!
>> > > >
>> > > > Then we may also need your help to review, as well as the coming
>> > patch
>> > > > set for GVE PMD enhancement for DPDK 23.07. Thanks in advance!
>> > > >
>> > > >>
>> > > >>> BTW, Google will also help replace all the base code under MIT
>> > > license
>> > > >>> with the ones under BSD-3 license soon, which would make
>> things
>> > > more
>> > > >>> easier.
>> > > >>>
>> > > >>
>> > > >> Is this different from base code under DPDK is changing license
>> > [1] ?
>> > > >>
>> > > >>
>> > > >> [1]
>> > > >>
>> > >
>> >
>> https://patches.dpdk.org/project/dpdk/list/?series=27570&state=%2A&ar <
>> https://patches.dpdk.org/project/dpdk/list/?series=27570&state=%2A&ar>
>> > > >> chive=both
>> > > >>
>> > > >
>> > > > The patch set of the above link only contains the processing of
>> > replace
>> > > the
>> > > > MIT licensed base code with the BSD-3 licensed base code. After
>> some
>> > > > discussion, we think Google is in the right place to do that
>> > work. And
>> > > they
>> > > > are working on that now.
>> > > >
>> > >
>> > > Is the Google GVE driver [2] in the process of changing license
>> > from MIT
>> > 

[PATCH] net/ice: support link speed change

2023-04-13 Thread Kaiwen Deng
Support link speed change functions for ice, and when start the ice,
apply link speed to hardware.

This feature supports changing the link speed via the testpmd command
"port config  speed 10|100|1000|1|25000|4|5|10
|20|40|auto duplex half|full|auto".

Signed-off-by: Kaiwen Deng 
---
 drivers/net/ice/ice_ethdev.c | 145 +--
 1 file changed, 105 insertions(+), 40 deletions(-)

diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 9a88cf9796..281f3ccf6f 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -89,6 +89,9 @@ static int ice_dev_close(struct rte_eth_dev *dev);
 static int ice_dev_reset(struct rte_eth_dev *dev);
 static int ice_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
+static int ice_phy_conf_link(struct ice_hw *hw,
+   u16 force_speed,
+   bool link_up);
 static int ice_link_update(struct rte_eth_dev *dev,
   int wait_to_complete);
 static int ice_dev_set_link_up(struct rte_eth_dev *dev);
@@ -4045,72 +4048,134 @@ ice_link_update(struct rte_eth_dev *dev, int 
wait_to_complete)
return 0;
 }
 
-/* Force the physical link state by getting the current PHY capabilities from
- * hardware and setting the PHY config based on the determined capabilities. If
- * link changes, link event will be triggered because both the Enable Automatic
- * Link Update and LESM Enable bits are set when setting the PHY capabilities.
- */
-static enum ice_status
-ice_force_phys_link_state(struct ice_hw *hw, bool link_up)
+static inline uint16_t
+ice_parse_link_speeds(uint16_t link_speeds)
 {
-   struct ice_aqc_set_phy_cfg_data cfg = { 0 };
-   struct ice_aqc_get_phy_caps_data *pcaps;
-   struct ice_port_info *pi;
-   enum ice_status status;
+   uint16_t link_speed = ICE_AQ_LINK_SPEED_UNKNOWN;
 
-   if (!hw || !hw->port_info)
-   return ICE_ERR_PARAM;
+   if (link_speeds & RTE_ETH_LINK_SPEED_100G)
+   link_speed |= ICE_AQ_LINK_SPEED_100GB;
+   if (link_speeds & RTE_ETH_LINK_SPEED_50G)
+   link_speed |= ICE_AQ_LINK_SPEED_50GB;
+   if (link_speeds & RTE_ETH_LINK_SPEED_40G)
+   link_speed |= ICE_AQ_LINK_SPEED_40GB;
+   if (link_speeds & RTE_ETH_LINK_SPEED_25G)
+   link_speed |= ICE_AQ_LINK_SPEED_25GB;
+   if (link_speeds & RTE_ETH_LINK_SPEED_20G)
+   link_speed |= ICE_AQ_LINK_SPEED_20GB;
+   if (link_speeds & RTE_ETH_LINK_SPEED_10G)
+   link_speed |= ICE_AQ_LINK_SPEED_10GB;
+   if (link_speeds & RTE_ETH_LINK_SPEED_5G)
+   link_speed |= ICE_AQ_LINK_SPEED_5GB;
+   if (link_speeds & RTE_ETH_LINK_SPEED_2_5G)
+   link_speed |= ICE_AQ_LINK_SPEED_2500MB;
+   if (link_speeds & RTE_ETH_LINK_SPEED_1G)
+   link_speed |= ICE_AQ_LINK_SPEED_1000MB;
+   if (link_speeds & RTE_ETH_LINK_SPEED_100M)
+   link_speed |= ICE_AQ_LINK_SPEED_100MB;
 
-   pi = hw->port_info;
+   return link_speed;
+}
+
+static int
+ice_apply_link_speed(struct rte_eth_dev *dev)
+{
+   uint16_t speed;
+   struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct rte_eth_conf *conf = &dev->data->dev_conf;
+
+   if (conf->link_speeds == RTE_ETH_LINK_SPEED_AUTONEG) {
+   conf->link_speeds = RTE_ETH_LINK_SPEED_100G |
+   RTE_ETH_LINK_SPEED_50G  |
+   RTE_ETH_LINK_SPEED_40G  |
+   RTE_ETH_LINK_SPEED_25G  |
+   RTE_ETH_LINK_SPEED_20G  |
+   RTE_ETH_LINK_SPEED_10G  |
+   RTE_ETH_LINK_SPEED_5G   |
+   RTE_ETH_LINK_SPEED_2_5G |
+   RTE_ETH_LINK_SPEED_1G   |
+   RTE_ETH_LINK_SPEED_100M;
+   }
+   speed = ice_parse_link_speeds(conf->link_speeds);
+
+   return ice_phy_conf_link(hw, speed, true);
+}
+
+static int
+ice_phy_conf_link(struct ice_hw *hw,
+  u16 link_speeds_bitmap,
+  bool link_up)
+{
+   struct ice_aqc_set_phy_cfg_data cfg = { 0 };
+   struct ice_port_info *pi = hw->port_info;
+   struct ice_aqc_get_phy_caps_data *phy_caps;
+   int err;
+   u64 phy_type_low = 0;
+   u64 phy_type_high = 0;
 
-   pcaps = (struct ice_aqc_get_phy_caps_data *)
-   ice_malloc(hw, sizeof(*pcaps));
-   if (!pcaps)
+   phy_caps = (struct ice_aqc_get_phy_caps_data *)
+   ice_malloc(hw, sizeof(*phy_caps));
+   if (!phy_caps)
return ICE_ERR_NO_MEMORY;
 
-   status = ice_aq_get_phy_caps(pi, false, ICE_AQC_REPORT_ACTIVE_CFG,
-pcaps,

[PATCH v2 0/5] fix Rx data buffer size

2023-04-13 Thread Wenjun Wu
This patch set fixes RX data buffer size in ice, i40e, iavf and idpf driver.

1. Limit the maximum buffer size to no more than 16K - 128.
2. Align max buffer size to 128, or replace RTE_ALIGN with
RTE_ALIGN_FLOOR according to [1].

[1] Commit c9c45beb1b97 ("net/iavf: fix Rx queue buffer size alignment")

---
v2: fix commit log

Wenjun Wu (5):
  net/i40e: fix Rx data buffer size
  net/ice: fix Rx data buffer size
  net/iavf: fix Rx data buffer size
  net/idpf: fix Rx data buffer size
  net/cpfl: fix Rx data buffer size

 drivers/common/idpf/idpf_common_rxtx.h | 3 +++
 drivers/net/cpfl/cpfl_rxtx.c   | 3 ++-
 drivers/net/i40e/i40e_rxtx.c   | 2 ++
 drivers/net/i40e/i40e_rxtx.h   | 3 +++
 drivers/net/iavf/iavf_rxtx.c   | 1 +
 drivers/net/iavf/iavf_rxtx.h   | 3 +++
 drivers/net/ice/ice_dcf_ethdev.c   | 3 ++-
 drivers/net/ice/ice_rxtx.c | 3 ++-
 drivers/net/ice/ice_rxtx.h | 3 +++
 drivers/net/idpf/idpf_rxtx.c   | 6 --
 10 files changed, 25 insertions(+), 5 deletions(-)

-- 
2.34.1



[PATCH v2 1/5] net/i40e: fix Rx data buffer size

2023-04-13 Thread Wenjun Wu
No matter what the mbuf size is, the data buffer size should not
be greater than 16K - 128.

Fixes: 4861cde46116 ("i40e: new poll mode driver")
Cc: sta...@dpdk.org

Signed-off-by: Wenjun Wu 
---
 drivers/net/i40e/i40e_rxtx.c | 2 ++
 drivers/net/i40e/i40e_rxtx.h | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 788ffb51c2..fbbefb5015 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -2904,6 +2904,8 @@ i40e_rx_queue_config(struct i40e_rx_queue *rxq)
rxq->rx_hdr_len = 0;
rxq->rx_buf_len = RTE_ALIGN_FLOOR(buf_size,
(1 << I40E_RXQ_CTX_DBUFF_SHIFT));
+   rxq->rx_buf_len = RTE_MIN(rxq->rx_buf_len,
+ I40E_RX_MAX_DATA_BUF_SIZE);
rxq->hs_mode = i40e_header_split_none;
break;
}
diff --git a/drivers/net/i40e/i40e_rxtx.h b/drivers/net/i40e/i40e_rxtx.h
index 5e6eecc501..0376c219be 100644
--- a/drivers/net/i40e/i40e_rxtx.h
+++ b/drivers/net/i40e/i40e_rxtx.h
@@ -21,6 +21,9 @@
 /* In none-PXE mode QLEN must be whole number of 32 descriptors. */
 #defineI40E_ALIGN_RING_DESC32
 
+/* Max data buffer size must be 16K - 128 bytes */
+#define I40E_RX_MAX_DATA_BUF_SIZE  (16 * 1024 - 128)
+
 #defineI40E_MIN_RING_DESC  64
 #defineI40E_MAX_RING_DESC  4096
 
-- 
2.34.1



[PATCH v2 2/5] net/ice: fix Rx data buffer size

2023-04-13 Thread Wenjun Wu
This patch does two fixes.

1. No matter what the mbuf size is, the data buffer size should not
be greater than 16K - 128.

2. Replace RTE_ALIGN with RTE_ALIGN_FLOOR according to [1].

[1] Commit c9c45beb1b97 ("net/iavf: fix Rx queue buffer size alignment")

Fixes: 50370662b727 ("net/ice: support device and queue ops")
Fixes: 1b009275e2c8 ("net/ice: add Rx queue init in DCF")
Cc: sta...@dpdk.org

Signed-off-by: Wenjun Wu 
---
 drivers/net/ice/ice_dcf_ethdev.c | 3 ++-
 drivers/net/ice/ice_rxtx.c   | 3 ++-
 drivers/net/ice/ice_rxtx.h   | 3 +++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index dcbf2af5b0..7304ea721c 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -115,7 +115,8 @@ ice_dcf_init_rxq(struct rte_eth_dev *dev, struct 
ice_rx_queue *rxq)
 
buf_size = rte_pktmbuf_data_room_size(rxq->mp) - RTE_PKTMBUF_HEADROOM;
rxq->rx_hdr_len = 0;
-   rxq->rx_buf_len = RTE_ALIGN(buf_size, (1 << ICE_RLAN_CTX_DBUF_S));
+   rxq->rx_buf_len = RTE_ALIGN_FLOOR(buf_size, (1 << ICE_RLAN_CTX_DBUF_S));
+   rxq->rx_buf_len = RTE_MIN(rxq->rx_buf_len, ICE_RX_MAX_DATA_BUF_SIZE);
max_pkt_len = RTE_MIN(ICE_SUPPORT_CHAIN_NUM * rxq->rx_buf_len,
  dev->data->mtu + ICE_ETH_OVERHEAD);
 
diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
index 0ea0045836..560c1a4af7 100644
--- a/drivers/net/ice/ice_rxtx.c
+++ b/drivers/net/ice/ice_rxtx.c
@@ -259,7 +259,8 @@ ice_program_hw_rx_queue(struct ice_rx_queue *rxq)
/* Set buffer size as the head split is disabled. */
buf_size = (uint16_t)(rte_pktmbuf_data_room_size(rxq->mp) -
  RTE_PKTMBUF_HEADROOM);
-   rxq->rx_buf_len = RTE_ALIGN(buf_size, (1 << ICE_RLAN_CTX_DBUF_S));
+   rxq->rx_buf_len = RTE_ALIGN_FLOOR(buf_size, (1 << ICE_RLAN_CTX_DBUF_S));
+   rxq->rx_buf_len = RTE_MIN(rxq->rx_buf_len, ICE_RX_MAX_DATA_BUF_SIZE);
rxq->max_pkt_len =
RTE_MIN((uint32_t)ICE_SUPPORT_CHAIN_NUM * rxq->rx_buf_len,
frame_size);
diff --git a/drivers/net/ice/ice_rxtx.h b/drivers/net/ice/ice_rxtx.h
index 94f6bcf3d1..89569029e1 100644
--- a/drivers/net/ice/ice_rxtx.h
+++ b/drivers/net/ice/ice_rxtx.h
@@ -51,6 +51,9 @@ extern int ice_timestamp_dynfield_offset;
 /* Max header size can be 2K - 64 bytes */
 #define ICE_RX_HDR_BUF_SIZE(2048 - 64)
 
+/* Max data buffer size must be 16K - 128 bytes */
+#define ICE_RX_MAX_DATA_BUF_SIZE   (16 * 1024 - 128)
+
 #define ICE_HEADER_SPLIT_ENA   BIT(0)
 
 typedef void (*ice_rx_release_mbufs_t)(struct ice_rx_queue *rxq);
-- 
2.34.1



[PATCH v2 3/5] net/iavf: fix Rx data buffer size

2023-04-13 Thread Wenjun Wu
No matter what the mbuf size is, the data buffer size should not
be greater than 16K - 128.

Fixes: 69dd4c3d0898 ("net/avf: enable queue and device")
Cc: sta...@dpdk.org

Signed-off-by: Wenjun Wu 
---
 drivers/net/iavf/iavf_rxtx.c | 1 +
 drivers/net/iavf/iavf_rxtx.h | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
index b1d0fbceb6..0db3aabd92 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -697,6 +697,7 @@ iavf_dev_rx_queue_setup(struct rte_eth_dev *dev, uint16_t 
queue_idx,
 
len = rte_pktmbuf_data_room_size(rxq->mp) - RTE_PKTMBUF_HEADROOM;
rxq->rx_buf_len = RTE_ALIGN_FLOOR(len, (1 << IAVF_RXQ_CTX_DBUFF_SHIFT));
+   rxq->rx_buf_len = RTE_MIN(rxq->rx_buf_len, IAVF_RX_MAX_DATA_BUF_SIZE);
 
/* Allocate the software ring. */
len = nb_desc + IAVF_RX_MAX_BURST;
diff --git a/drivers/net/iavf/iavf_rxtx.h b/drivers/net/iavf/iavf_rxtx.h
index 09e2127db0..f205a2aaf1 100644
--- a/drivers/net/iavf/iavf_rxtx.h
+++ b/drivers/net/iavf/iavf_rxtx.h
@@ -16,6 +16,9 @@
 /* used for Rx Bulk Allocate */
 #define IAVF_RX_MAX_BURST 32
 
+/* Max data buffer size must be 16K - 128 bytes */
+#define IAVF_RX_MAX_DATA_BUF_SIZE (16 * 1024 - 128)
+
 /* used for Vector PMD */
 #define IAVF_VPMD_RX_MAX_BURST32
 #define IAVF_VPMD_TX_MAX_BURST32
-- 
2.34.1



[PATCH v2 4/5] net/idpf: fix Rx data buffer size

2023-04-13 Thread Wenjun Wu
This patch does two fixes.

1. No matter what the mbuf size is, the data buffer size should not
be greater than 16K - 128.

2. Align data buffer size to 128.

Fixes: 9c47c29739a1 ("net/idpf: add Rx queue setup")
Cc: sta...@dpdk.org

Signed-off-by: Wenjun Wu 
---
 drivers/common/idpf/idpf_common_rxtx.h | 3 +++
 drivers/net/idpf/idpf_rxtx.c   | 6 --
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/common/idpf/idpf_common_rxtx.h 
b/drivers/common/idpf/idpf_common_rxtx.h
index 11260d07f9..6cb83fc0a6 100644
--- a/drivers/common/idpf/idpf_common_rxtx.h
+++ b/drivers/common/idpf/idpf_common_rxtx.h
@@ -34,6 +34,9 @@
 #define IDPF_MAX_TSO_FRAME_SIZE262143
 #define IDPF_TX_MAX_MTU_SEG 10
 
+#define IDPF_RLAN_CTX_DBUF_S   7
+#define IDPF_RX_MAX_DATA_BUF_SIZE  (16 * 1024 - 128)
+
 #define IDPF_TX_CKSUM_OFFLOAD_MASK (   \
RTE_MBUF_F_TX_IP_CKSUM |\
RTE_MBUF_F_TX_L4_MASK | \
diff --git a/drivers/net/idpf/idpf_rxtx.c b/drivers/net/idpf/idpf_rxtx.c
index 414f9a37f6..3e3d81ca6d 100644
--- a/drivers/net/idpf/idpf_rxtx.c
+++ b/drivers/net/idpf/idpf_rxtx.c
@@ -155,7 +155,8 @@ idpf_rx_split_bufq_setup(struct rte_eth_dev *dev, struct 
idpf_rx_queue *rxq,
bufq->adapter = adapter;
 
len = rte_pktmbuf_data_room_size(bufq->mp) - RTE_PKTMBUF_HEADROOM;
-   bufq->rx_buf_len = len;
+   bufq->rx_buf_len = RTE_ALIGN_FLOOR(len, (1 << IDPF_RLAN_CTX_DBUF_S));
+   bufq->rx_buf_len = RTE_MIN(bufq->rx_buf_len, IDPF_RX_MAX_DATA_BUF_SIZE);
 
/* Allocate a little more to support bulk allocate. */
len = nb_desc + IDPF_RX_MAX_BURST;
@@ -275,7 +276,8 @@ idpf_rx_queue_setup(struct rte_eth_dev *dev, uint16_t 
queue_idx,
rxq->offloads = idpf_rx_offload_convert(offloads);
 
len = rte_pktmbuf_data_room_size(rxq->mp) - RTE_PKTMBUF_HEADROOM;
-   rxq->rx_buf_len = len;
+   rxq->rx_buf_len = RTE_ALIGN_FLOOR(len, (1 << IDPF_RLAN_CTX_DBUF_S));
+   rxq->rx_buf_len = RTE_MIN(rxq->rx_buf_len, IDPF_RX_MAX_DATA_BUF_SIZE);
 
/* Allocate a little more to support bulk allocate. */
len = nb_desc + IDPF_RX_MAX_BURST;
-- 
2.34.1



[PATCH v2 5/5] net/cpfl: fix Rx data buffer size

2023-04-13 Thread Wenjun Wu
This patch does two fixes.

1. No matter what the mbuf size is, the data buffer size should not
be greater than 16K - 128.

2. Align data buffer size to 128.

Fixes: 119834846e93 ("net/cpfl: support Rx queue setup")
Cc: sta...@dpdk.org

Signed-off-by: Wenjun Wu 
---
 drivers/net/cpfl/cpfl_rxtx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/cpfl/cpfl_rxtx.c b/drivers/net/cpfl/cpfl_rxtx.c
index de59b31b3d..75021c3c54 100644
--- a/drivers/net/cpfl/cpfl_rxtx.c
+++ b/drivers/net/cpfl/cpfl_rxtx.c
@@ -155,7 +155,8 @@ cpfl_rx_split_bufq_setup(struct rte_eth_dev *dev, struct 
idpf_rx_queue *rxq,
bufq->adapter = base;
 
len = rte_pktmbuf_data_room_size(bufq->mp) - RTE_PKTMBUF_HEADROOM;
-   bufq->rx_buf_len = len;
+   bufq->rx_buf_len = RTE_ALIGN_FLOOR(len, (1 << IDPF_RLAN_CTX_DBUF_S));
+   bufq->rx_buf_len = RTE_MIN(bufq->rx_buf_len, IDPF_RX_MAX_DATA_BUF_SIZE);
 
/* Allocate a little more to support bulk allocate. */
len = nb_desc + IDPF_RX_MAX_BURST;
-- 
2.34.1



RE: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC

2023-04-13 Thread Morten Brørup
> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> Sent: Thursday, 13 April 2023 23.26
> 
> For now expand a lot of common rte macros empty. The catch here is we
> need to test that most of the macros do what they should but at the same
> time they are blocking work needed to bootstrap of the unit tests.
> 
> Later we will return and provide (where possible) expansions that work
> correctly for msvc and where not possible provide some alternate macros
> to achieve the same outcome.
> 
> Signed-off-by: Tyler Retzlaff 
> ---
>  lib/eal/include/rte_branch_prediction.h |  8 ++
>  lib/eal/include/rte_common.h| 45
> +
>  lib/eal/include/rte_compat.h| 20 +++
>  3 files changed, 73 insertions(+)
> 
> diff --git a/lib/eal/include/rte_branch_prediction.h
> b/lib/eal/include/rte_branch_prediction.h
> index 0256a9d..d9a0224 100644
> --- a/lib/eal/include/rte_branch_prediction.h
> +++ b/lib/eal/include/rte_branch_prediction.h
> @@ -25,7 +25,11 @@
>   *
>   */
>  #ifndef likely
> +#ifndef RTE_TOOLCHAIN_MSVC
>  #define likely(x)__builtin_expect(!!(x), 1)
> +#else
> +#define likely(x)(x)

This must be (!!(x)), because x may be non-Boolean, e.g. likely(n & 0x10), and 
likely() must return Boolean (0 or 1).

> +#endif
>  #endif /* likely */
> 
>  /**
> @@ -39,7 +43,11 @@
>   *
>   */
>  #ifndef unlikely
> +#ifndef RTE_TOOLCHAIN_MSVC
>  #define unlikely(x)  __builtin_expect(!!(x), 0)
> +#else
> +#define unlikely(x)  (x)

This must also be (!!(x)), for the same reason as above.

> +#endif
>  #endif /* unlikely */
> 
>  #ifdef __cplusplus
> diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
> index 2f464e3..1bdaa2d 100644
> --- a/lib/eal/include/rte_common.h
> +++ b/lib/eal/include/rte_common.h
> @@ -65,7 +65,11 @@
>  /**
>   * Force alignment
>   */
> +#ifndef RTE_TOOLCHAIN_MSVC
>  #define __rte_aligned(a) __attribute__((__aligned__(a)))
> +#else
> +#define __rte_aligned(a)
> +#endif

It should be reviewed that __rte_aligned() is only used for optimization 
purposes, and is not required for DPDK to function properly.

> 
>  #ifdef RTE_ARCH_STRICT_ALIGN
>  typedef uint64_t unaligned_uint64_t __rte_aligned(1);
> @@ -80,16 +84,29 @@
>  /**
>   * Force a structure to be packed
>   */
> +#ifndef RTE_TOOLCHAIN_MSVC
>  #define __rte_packed __attribute__((__packed__))
> +#else
> +#define __rte_packed
> +#endif

Similar comment as for __rte_aligned(); however, I consider it more likely that 
structure packing is a functional requirement, and not just used for 
optimization. Based on my experience, it may be used for packing network 
structures; perhaps not in DPDK itself but maybe in DPDK applications.

The same risk applies to __rte_aligned(), but with lower probability.