* Re: [PATCH v3 3/4] net/ixgbe: add firmware version get
From: Ferruh Yigit @ 2017-01-04 12:01 UTC (permalink / raw)
To: Yang, Qiming, dev@dpdk.org, thomas.monjalon@6wind.com; +Cc: Horton, Remy
In-Reply-To: <F5DF4F0E3AFEF648ADC1C3C33AD4DBF16EDC9B80@SHSMSX101.ccr.corp.intel.com>
On 1/4/2017 9:48 AM, Yang, Qiming wrote:
> Yes, etrack_id is an unique value. But not all NICs have this value.
> I didn't find any value about fw version in fm10k.
Yes, you are right, following is from i40e datasheet:
"
The EEPROM Manager tool writes a unique 32-bit eTrack_ID number in two
sequential NVM words.
The eTrack_ID is written when EEPROM Manager tool creates an image on
the Intel network. The eTrack_ID DB tracks NVM images back to a specific
SCM build
"
So it is unique, and can be used to identify FW version. And yes it can
be enough on its own without having major minor FW version fields.
> I40e is 8 bit too.
> firmware-version: 5.04 0x800024ca
Right, I read it wrong, i40e also has 32bits etrack-id.
Thanks,
ferruh
^ permalink raw reply
* Re: [PATCH 2/2] app/testpmd: remove explicit ixgbe link request
From: Ferruh Yigit @ 2017-01-04 11:44 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev, konstantin.ananyev, helin.zhang, thomas.monjalon
In-Reply-To: <20170104110144.GA8258@localhost.localdomain>
On 1/4/2017 11:01 AM, Jerin Jacob wrote:
> On Tue, Jan 03, 2017 at 01:30:26PM +0000, Ferruh Yigit wrote:
>> On 12/27/2016 10:09 AM, Jerin Jacob wrote:
>>> Removed explicit ixgbe driver linkage request from
>>> app/testpmd makefile to mk/rte.app.mk to
>>> 1)Maintain the correct link ordering(from higher level libraries
>>> to lower level libraries)
>>> 2)In shared lib configuration, any application can use ixgbe
>>> exposed pmd specific APIs not just testpmd.
>>
>> In testpmd, "explicit ixgbe driver linkage request" added because
>> testpmd uses ixgbe PMD specific APIs.
>>
>> Overall, that line is for shared library, for static library result
>> should be same.
>
> Unfortunately for the static library, the result is different.You can
> check the testpmd.map file for the effects linking rte_pmd_ixgbe first.
This was unintentional/unexpected, thanks for catching this.
>
> I found this while debugging the a strange issue where including ixgbe
> build is dropping 300kpps/core on thunderx pmd.Finally, git bisected and saw
> the following check-in causes this
>
> commit 425781ff5afe08b77c58ec5e4d5cf56b9ac19e02
> Author: Bernard Iremonger <bernard.iremonger@intel.com>
> Date: Wed Oct 12 18:54:12 2016 +0100
>
> app/testpmd: add ixgbe VF management
>
> Nothing wrong in this check-in wrt functionality, but moving rte_pmd_ixgbe
> to first is completely changing the symbol generation for the static build.
I can guess the reason.
Now "-Wl,-lrte_pmd_ixgbe" provided twice, and build system removes the
duplication by keeping only first occurrence.
This moves "-Wl,-lrte_pmd_ixgbe" out of "-Wl,--whole-archive" flag.
Since PMD API not directly called, but register themselves via
constructors, and initialized in runtime using registered callbacks,
without "--whole-archive" some APIs from that PMD may be missing in
final application.
>
> ----
> gcc -o testpmd -m64 -pthread -march=native -DRTE_MACHINE_CPUFLAG_SSE
>
> [snip]
>
> -Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef
> -Wwrite-strings -Werror testpmd.o parameters.o cmdline.o cmdline_flow.o
> config.o iofwd.o macfwd.o macswap.o flowgen.o rxonly.o txonly.o
> csumonly.o icmpecho.o -Wl,-lrte_pmd_ixgbe
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> -L/export/dpdk-master/build/lib -Wl,-lrte_kni -Wl,-lrte_pipeline
> -Wl,-lrte_table -Wl,-lrte_port -Wl,-lrte_pdump -Wl,-lrte_distributor
> -Wl,-lrte_reorder -Wl,-lrte_ip_frag -Wl,-lrte_meter -Wl,-lrte_sched
> -Wl,-lrte_lpm -Wl,--whole-archive -Wl,-lrte_acl -Wl,--no-whole-archive
> -Wl,-lrte_jobstats -Wl,-lrte_power -Wl,--whole-archive -Wl,-lrte_timer
> -Wl,-lrte_hash -Wl,-lrte_vhost -Wl,-lrte_kvargs -Wl,-lrte_mbuf
> -Wl,-lrte_net -Wl,-lrte_ethdev -Wl,-lrte_cryptodev -Wl,-lrte_eventdev
> -Wl,-lrte_mempool -Wl,-lrte_ring -Wl,-lrte_eal -Wl,-lrte_cmdline
> -Wl,-lrte_cfgfile -Wl,-lrte_pmd_bond -Wl,-lrte_pmd_af_packet
> -Wl,-lrte_pmd_bnxt -Wl,-lrte_pmd_cxgbe -Wl,-lrte_pmd_e1000
> -Wl,-lrte_pmd_ena -Wl,-lrte_pmd_enic -Wl,-lrte_pmd_fm10k
> -Wl,-lrte_pmd_i40e -Wl,-lrte_pmd_null -Wl,-lrte_pmd_qede
> -Wl,-lrte_pmd_ring -Wl,-lrte_pmd_virtio -Wl,-lrte_pmd_vhost
> -Wl,-lrte_pmd_vmxnet3_uio -Wl,-lrte_pmd_null_crypto
> -Wl,-lrte_pmd_skeleton_event -Wl,--no-whole-archive -Wl,-lrt -Wl,-lm
> -Wl,-ldl -Wl,-export-dynamic -Wl,-export-dynamic -Wl,-export-dynamic
> -L/export/dpdk-master/build/lib -Wl,--as-needed -Wl,-Map=testpmd.map
> -Wl,--cref
> ----
>
>>
>> I believe it is good to keep it in testpmd Makefile, updating rte.app.mk
>> to have it will:
>> - link library to the applications which does not use PMD specific APIs
>> and want to load PMD dynamically.
>> - link library to the application that won't use driver at all. This may
>> break the distributed binaries, since testpmd will now be dependent to a
>> specific PMD.
>
> No strong opinion here as it is specific to ixgbe. But can we include
> ixgbe only for shared library in testpmd so that it won't effect any
> symbol generation in static build.
I think this is better, I am OK with below patch, thanks.
>
>
> [dpdk-master] $ git diff
> diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
> index 5988c3e..050663a 100644
> --- a/app/test-pmd/Makefile
> +++ b/app/test-pmd/Makefile
> @@ -59,7 +59,9 @@ SRCS-y += csumonly.c
> SRCS-y += icmpecho.c
> SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
>
> +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> _LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> +endif
>
> CFLAGS_cmdline.o := -D_GNU_SOURCE
>
>
>>
>>>
>>> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>>> ---
>>> app/test-pmd/Makefile | 2 --
>>> mk/rte.app.mk | 2 +-
>>> 2 files changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
>>> index 5988c3e..96e0c67 100644
>>> --- a/app/test-pmd/Makefile
>>> +++ b/app/test-pmd/Makefile
>>> @@ -59,8 +59,6 @@ SRCS-y += csumonly.c
>>> SRCS-y += icmpecho.c
>>> SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
>>>
>>> -_LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
>>> -
>>> CFLAGS_cmdline.o := -D_GNU_SOURCE
>>>
>>> # this application needs libraries first
>>> diff --git a/mk/rte.app.mk b/mk/rte.app.mk
>>> index f75f0e2..aee235c 100644
>>> --- a/mk/rte.app.mk
>>> +++ b/mk/rte.app.mk
>>> @@ -101,6 +101,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_CFGFILE) += -lrte_cfgfile
>>>
>>> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += -lrte_pmd_bond
>>> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += -lrte_pmd_xenvirt -lxenstore
>>> +_LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
>>>
>>> ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
>>> # plugins (link only if static libraries)
>>> @@ -114,7 +115,6 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += -lrte_pmd_ena
>>> _LDLIBS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += -lrte_pmd_enic
>>> _LDLIBS-$(CONFIG_RTE_LIBRTE_FM10K_PMD) += -lrte_pmd_fm10k
>>> _LDLIBS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += -lrte_pmd_i40e
>>> -_LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
>>> _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -lrte_pmd_mlx4 -libverbs
>>> _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += -lrte_pmd_mlx5 -libverbs
>>> _LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lrte_pmd_mpipe -lgxio
>>>
>>
^ permalink raw reply
* Re: Running DPDK as an unprivileged user
From: Tan, Jianfeng @ 2017-01-04 11:39 UTC (permalink / raw)
To: Walker, Benjamin, dev@dpdk.org
In-Reply-To: <1483044080.11975.1.camel@intel.com>
Hi Benjamin,
On 12/30/2016 4:41 AM, Walker, Benjamin wrote:
> Hi all,
>
> I've been digging in to what it would take to run DPDK as an
> unprivileged user and I have some findings that I thought
> were worthy of discussion. The assumptions here are that I'm
> using a very recent Linux kernel (4.8.15 to be specific) and
> I'm using vfio with my IOMMU enabled. I'm only interested in
> making it possible to run as an unprivileged user in this
> type of environment.
>
> There are a few key things that DPDK needs to do in order to
> run as an unprivileged user:
>
> 1) Allocate hugepages
> 2) Map device resources
> 3) Map hugepage virtual addresses to DMA addresses.
>
> For #1 and #2, DPDK works just fine today. You simply chown
> the relevant resources in sysfs to the desired user and
> everything is happy.
>
> The problem is #3. This currently relies on looking up the
> mappings in /proc/self/pagemap, but the ability to get
> physical addresses in /proc/self/pagemap as an unprivileged
> user was removed from the kernel in the 4.x timeframe due to
> the Rowhammer vulnerability. At this time, it is not
> possible to run DPDK as an unprivileged user on a 4.x Linux
> kernel.
>
> There is a way to make this work though, which I'll outline
> now. Unfortunately, I think it is going to require some very
> significant changes to the initialization flow in the EAL.
> One bit of of background before I go into how to fix this -
> there are three types of memory addresses - virtual
> addresses, physical addresses, and DMA addresses. Sometimes
> DMA addresses are called bus addresses or I/O addresses, but
> I'll call them DMA addresses because I think that's the
> clearest name. In a system without an IOMMU, DMA addresses
> and physical addresses are equivalent, but in a system with
> an IOMMU any arbitrary DMA address can be chosen by the user
> to map to a given physical address. For security reasons
> (rowhammer), it is no longer considered safe to expose
> physical addresses to userspace, but it is perfectly fine to
> expose DMA addresses when an IOMMU is present.
>
> DPDK today begins by allocating all of the required
> hugepages, then finds all of the physical addresses for
> those hugepages using /proc/self/pagemap, sorts the
> hugepages by physical address, then remaps the pages to
> contiguous virtual addresses. Later on and if vfio is
> enabled, it asks vfio to pin the hugepages and to set their
> DMA addresses in the IOMMU to be the physical addresses
> discovered earlier. Of course, running as an unprivileged
> user means all of the physical addresses in
> /proc/self/pagemap are just 0, so this doesn't end up
> working. Further, there is no real reason to choose the
> physical address as the DMA address in the IOMMU - it would
> be better to just count up starting at 0.
Why not just using virtual address as the DMA address in this case to
avoid maintaining another kind of addresses?
> Also, because the
> pages are pinned after the virtual to physical mapping is
> looked up, there is a window where a page could be moved.
> Hugepage mappings can be moved on more recent kernels (at
> least 4.x), and the reliability of hugepages having static
> mappings decreases with every kernel release.
Do you mean kernel might take back a physical page after mapping it to a
virtual page (maybe copy the data to another physical page)? Could you
please show some links or kernel commits?
> Note that this
> probably means that using uio on recent kernels is subtly
> broken and cannot be supported going forward because there
> is no uio mechanism to pin the memory.
>
> The first open question I have is whether DPDK should allow
> uio at all on recent (4.x) kernels. My current understanding
> is that there is no way to pin memory and hugepages can now
> be moved around, so uio would be unsafe. What does the
> community think here?
>
> My second question is whether the user should be allowed to
> mix uio and vfio usage simultaneously. For vfio, the
> physical addresses are really DMA addresses and are best
> when arbitrarily chosen to appear sequential relative to
> their virtual addresses.
Why "sequential relative to their virtual addresses"? IOMMU table is for
DMA addr -> physical addr mapping. So we need to DMA addresses
"sequential relative to their physical addresses"? Based on your above
analysis on how hugepages are initialized, virtual addresses is a good
candidate for DMA address?
Thanks,
Jianfeng
^ permalink raw reply
* Re: [PATCH 2/2] app/testpmd: remove explicit ixgbe link request
From: Jerin Jacob @ 2017-01-04 11:01 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, konstantin.ananyev, helin.zhang, thomas.monjalon
In-Reply-To: <ecf308dd-1a56-8ad8-092f-53ade6ae4227@intel.com>
On Tue, Jan 03, 2017 at 01:30:26PM +0000, Ferruh Yigit wrote:
> On 12/27/2016 10:09 AM, Jerin Jacob wrote:
> > Removed explicit ixgbe driver linkage request from
> > app/testpmd makefile to mk/rte.app.mk to
> > 1)Maintain the correct link ordering(from higher level libraries
> > to lower level libraries)
> > 2)In shared lib configuration, any application can use ixgbe
> > exposed pmd specific APIs not just testpmd.
>
> In testpmd, "explicit ixgbe driver linkage request" added because
> testpmd uses ixgbe PMD specific APIs.
>
> Overall, that line is for shared library, for static library result
> should be same.
Unfortunately for the static library, the result is different.You can
check the testpmd.map file for the effects linking rte_pmd_ixgbe first.
I found this while debugging the a strange issue where including ixgbe
build is dropping 300kpps/core on thunderx pmd.Finally, git bisected and saw
the following check-in causes this
commit 425781ff5afe08b77c58ec5e4d5cf56b9ac19e02
Author: Bernard Iremonger <bernard.iremonger@intel.com>
Date: Wed Oct 12 18:54:12 2016 +0100
app/testpmd: add ixgbe VF management
Nothing wrong in this check-in wrt functionality, but moving rte_pmd_ixgbe
to first is completely changing the symbol generation for the static build.
----
gcc -o testpmd -m64 -pthread -march=native -DRTE_MACHINE_CPUFLAG_SSE
[snip]
-Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef
-Wwrite-strings -Werror testpmd.o parameters.o cmdline.o cmdline_flow.o
config.o iofwd.o macfwd.o macswap.o flowgen.o rxonly.o txonly.o
csumonly.o icmpecho.o -Wl,-lrte_pmd_ixgbe
^^^^^^^^^^^^^^^^^^^^^^^^^
-L/export/dpdk-master/build/lib -Wl,-lrte_kni -Wl,-lrte_pipeline
-Wl,-lrte_table -Wl,-lrte_port -Wl,-lrte_pdump -Wl,-lrte_distributor
-Wl,-lrte_reorder -Wl,-lrte_ip_frag -Wl,-lrte_meter -Wl,-lrte_sched
-Wl,-lrte_lpm -Wl,--whole-archive -Wl,-lrte_acl -Wl,--no-whole-archive
-Wl,-lrte_jobstats -Wl,-lrte_power -Wl,--whole-archive -Wl,-lrte_timer
-Wl,-lrte_hash -Wl,-lrte_vhost -Wl,-lrte_kvargs -Wl,-lrte_mbuf
-Wl,-lrte_net -Wl,-lrte_ethdev -Wl,-lrte_cryptodev -Wl,-lrte_eventdev
-Wl,-lrte_mempool -Wl,-lrte_ring -Wl,-lrte_eal -Wl,-lrte_cmdline
-Wl,-lrte_cfgfile -Wl,-lrte_pmd_bond -Wl,-lrte_pmd_af_packet
-Wl,-lrte_pmd_bnxt -Wl,-lrte_pmd_cxgbe -Wl,-lrte_pmd_e1000
-Wl,-lrte_pmd_ena -Wl,-lrte_pmd_enic -Wl,-lrte_pmd_fm10k
-Wl,-lrte_pmd_i40e -Wl,-lrte_pmd_null -Wl,-lrte_pmd_qede
-Wl,-lrte_pmd_ring -Wl,-lrte_pmd_virtio -Wl,-lrte_pmd_vhost
-Wl,-lrte_pmd_vmxnet3_uio -Wl,-lrte_pmd_null_crypto
-Wl,-lrte_pmd_skeleton_event -Wl,--no-whole-archive -Wl,-lrt -Wl,-lm
-Wl,-ldl -Wl,-export-dynamic -Wl,-export-dynamic -Wl,-export-dynamic
-L/export/dpdk-master/build/lib -Wl,--as-needed -Wl,-Map=testpmd.map
-Wl,--cref
----
>
> I believe it is good to keep it in testpmd Makefile, updating rte.app.mk
> to have it will:
> - link library to the applications which does not use PMD specific APIs
> and want to load PMD dynamically.
> - link library to the application that won't use driver at all. This may
> break the distributed binaries, since testpmd will now be dependent to a
> specific PMD.
No strong opinion here as it is specific to ixgbe. But can we include
ixgbe only for shared library in testpmd so that it won't effect any
symbol generation in static build.
[dpdk-master] $ git diff
diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
index 5988c3e..050663a 100644
--- a/app/test-pmd/Makefile
+++ b/app/test-pmd/Makefile
@@ -59,7 +59,9 @@ SRCS-y += csumonly.c
SRCS-y += icmpecho.c
SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
_LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
+endif
CFLAGS_cmdline.o := -D_GNU_SOURCE
>
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
> > app/test-pmd/Makefile | 2 --
> > mk/rte.app.mk | 2 +-
> > 2 files changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
> > index 5988c3e..96e0c67 100644
> > --- a/app/test-pmd/Makefile
> > +++ b/app/test-pmd/Makefile
> > @@ -59,8 +59,6 @@ SRCS-y += csumonly.c
> > SRCS-y += icmpecho.c
> > SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> >
> > -_LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > -
> > CFLAGS_cmdline.o := -D_GNU_SOURCE
> >
> > # this application needs libraries first
> > diff --git a/mk/rte.app.mk b/mk/rte.app.mk
> > index f75f0e2..aee235c 100644
> > --- a/mk/rte.app.mk
> > +++ b/mk/rte.app.mk
> > @@ -101,6 +101,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_CFGFILE) += -lrte_cfgfile
> >
> > _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += -lrte_pmd_bond
> > _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += -lrte_pmd_xenvirt -lxenstore
> > +_LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> >
> > ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > # plugins (link only if static libraries)
> > @@ -114,7 +115,6 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += -lrte_pmd_ena
> > _LDLIBS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += -lrte_pmd_enic
> > _LDLIBS-$(CONFIG_RTE_LIBRTE_FM10K_PMD) += -lrte_pmd_fm10k
> > _LDLIBS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += -lrte_pmd_i40e
> > -_LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -lrte_pmd_mlx4 -libverbs
> > _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += -lrte_pmd_mlx5 -libverbs
> > _LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lrte_pmd_mpipe -lgxio
> >
>
^ permalink raw reply related
* Re: [PATCH v2 14/29] eal/arm64: change barrier definitions to macros
From: Tiwei Bie @ 2017-01-04 11:00 UTC (permalink / raw)
To: Jerin Jacob
Cc: Jianbo Liu, dev, Ananyev, Konstantin, Thomas Monjalon,
Bruce Richardson, Jan Viktorin, Santosh Shukla
In-Reply-To: <20170104100912.GB6578@localhost.localdomain>
On Wed, Jan 04, 2017 at 03:39:14PM +0530, Jerin Jacob wrote:
> On Tue, Jan 03, 2017 at 03:55:45PM +0800, Jianbo Liu wrote:
> > On 27 December 2016 at 17:49, Jerin Jacob
> > <jerin.jacob@caviumnetworks.com> wrote:
> > > Change rte_?wb definitions to macros in order to
> >
> > use rte_*mb?
>
> IMHO, regex ? is appropriate here.
> https://en.wikipedia.org/wiki/Regular_expression
>
The APIs you're changing are:
> +#define rte_mb() dsb(sy)
> +#define rte_wmb() dsb(st)
> +#define rte_rmb() dsb(ld)
If it's a regex, shouldn't it be: rte_[wr]?mb or rte_.?mb
If ? is a wildcard used by shell, it should at least be: rte_?mb
But rte_*mb is easier to recognize, and matches all of them. :-)
Best regards,
Tiwei Bie
> >
> > > keep consistent with other barrier definitions in
> > > the file.
> > >
> > > Suggested-by: Jianbo Liu <jianbo.liu@linaro.org>
> > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > > ---
> > > .../common/include/arch/arm/rte_atomic_64.h | 36 ++--------------------
> > > 1 file changed, 3 insertions(+), 33 deletions(-)
> > >
> > > diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > > index ef0efc7..dc3a0f3 100644
> > > --- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > > +++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > > @@ -46,41 +46,11 @@ extern "C" {
> > > #define dsb(opt) { asm volatile("dsb " #opt : : : "memory"); }
> > > #define dmb(opt) { asm volatile("dmb " #opt : : : "memory"); }
> > >
> > > -/**
> > > - * General memory barrier.
> > > - *
> > > - * Guarantees that the LOAD and STORE operations generated before the
> > > - * barrier occur before the LOAD and STORE operations generated after.
> > > - * This function is architecture dependent.
> > > - */
> > > -static inline void rte_mb(void)
> > > -{
> > > - dsb(sy);
> > > -}
> > > +#define rte_mb() dsb(sy)
> > >
> > > -/**
> > > - * Write memory barrier.
> > > - *
> > > - * Guarantees that the STORE operations generated before the barrier
> > > - * occur before the STORE operations generated after.
> > > - * This function is architecture dependent.
> > > - */
> > > -static inline void rte_wmb(void)
> > > -{
> > > - dsb(st);
> > > -}
> > > +#define rte_wmb() dsb(st)
> > >
> > > -/**
> > > - * Read memory barrier.
> > > - *
> > > - * Guarantees that the LOAD operations generated before the barrier
> > > - * occur before the LOAD operations generated after.
> > > - * This function is architecture dependent.
> > > - */
> >
> > How about keep the comments for all these macros?
>
> lib/librte_eal/common/include/generic/rte_atomic.h file has description
> for all the barriers.All other arch are doing in the same-way.
>
> >
> > > -static inline void rte_rmb(void)
> > > -{
> > > - dsb(ld);
> > > -}
> > > +#define rte_rmb() dsb(ld)
> > >
> > > #define rte_smp_mb() dmb(ish)
> > >
> > > --
> > > 2.5.5
> > >
^ permalink raw reply
* Re: Running DPDK as an unprivileged user
From: Thomas Monjalon @ 2017-01-04 10:11 UTC (permalink / raw)
To: Walker, Benjamin; +Cc: stephen, dev
In-Reply-To: <1483483821.5643.4.camel@intel.com>
2017-01-03 22:50, Walker, Benjamin:
> 1) Physical addresses cannot be exposed to unprivileged users due to security
> concerns (the fallout of rowhammer). Therefore, systems without an IOMMU can
> only support privileged users. I think this is probably fine.
> 2) The IOCTL from vfio to pin the memory is tied to specifying the DMA address
> and programming the IOMMU. This is unfortunate - systems without an IOMMU still
> want to do the pinning, but they need to be given the physical address instead
> of specifying a DMA address.
> 3) Not all device types, particularly in virtualization environments, support
> vfio today. These devices have no way to explicitly pin memory.
In VM we can use VFIO-noiommu. Is it helping for mapping?
^ permalink raw reply
* Re: [PATCH v2 14/29] eal/arm64: change barrier definitions to macros
From: Jerin Jacob @ 2017-01-04 10:09 UTC (permalink / raw)
To: Jianbo Liu
Cc: dev, Ananyev, Konstantin, Thomas Monjalon, Bruce Richardson,
Jan Viktorin, Santosh Shukla
In-Reply-To: <CAP4Qi38_OfR20jtJBzfJBo1PZ_kzQk1=R-U8i_1NS=2OU7NfJQ@mail.gmail.com>
On Tue, Jan 03, 2017 at 03:55:45PM +0800, Jianbo Liu wrote:
> On 27 December 2016 at 17:49, Jerin Jacob
> <jerin.jacob@caviumnetworks.com> wrote:
> > Change rte_?wb definitions to macros in order to
>
> use rte_*mb?
IMHO, regex ? is appropriate here.
https://en.wikipedia.org/wiki/Regular_expression
>
> > keep consistent with other barrier definitions in
> > the file.
> >
> > Suggested-by: Jianbo Liu <jianbo.liu@linaro.org>
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
> > .../common/include/arch/arm/rte_atomic_64.h | 36 ++--------------------
> > 1 file changed, 3 insertions(+), 33 deletions(-)
> >
> > diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > index ef0efc7..dc3a0f3 100644
> > --- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > +++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > @@ -46,41 +46,11 @@ extern "C" {
> > #define dsb(opt) { asm volatile("dsb " #opt : : : "memory"); }
> > #define dmb(opt) { asm volatile("dmb " #opt : : : "memory"); }
> >
> > -/**
> > - * General memory barrier.
> > - *
> > - * Guarantees that the LOAD and STORE operations generated before the
> > - * barrier occur before the LOAD and STORE operations generated after.
> > - * This function is architecture dependent.
> > - */
> > -static inline void rte_mb(void)
> > -{
> > - dsb(sy);
> > -}
> > +#define rte_mb() dsb(sy)
> >
> > -/**
> > - * Write memory barrier.
> > - *
> > - * Guarantees that the STORE operations generated before the barrier
> > - * occur before the STORE operations generated after.
> > - * This function is architecture dependent.
> > - */
> > -static inline void rte_wmb(void)
> > -{
> > - dsb(st);
> > -}
> > +#define rte_wmb() dsb(st)
> >
> > -/**
> > - * Read memory barrier.
> > - *
> > - * Guarantees that the LOAD operations generated before the barrier
> > - * occur before the LOAD operations generated after.
> > - * This function is architecture dependent.
> > - */
>
> How about keep the comments for all these macros?
lib/librte_eal/common/include/generic/rte_atomic.h file has description
for all the barriers.All other arch are doing in the same-way.
>
> > -static inline void rte_rmb(void)
> > -{
> > - dsb(ld);
> > -}
> > +#define rte_rmb() dsb(ld)
> >
> > #define rte_smp_mb() dmb(ish)
> >
> > --
> > 2.5.5
> >
^ permalink raw reply
* Re: [PATCH v2 09/29] eal/arm64: define I/O device memory barriers for arm64
From: Jerin Jacob @ 2017-01-04 10:01 UTC (permalink / raw)
To: Jianbo Liu
Cc: dev, Ananyev, Konstantin, Thomas Monjalon, Bruce Richardson,
Jan Viktorin, Santosh Shukla
In-Reply-To: <CAP4Qi38GTrKaUsxCWFH9g8D=wiR1wBM9N5HGykya5pKoOfen3g@mail.gmail.com>
On Tue, Jan 03, 2017 at 03:48:32PM +0800, Jianbo Liu wrote:
> On 27 December 2016 at 17:49, Jerin Jacob
> <jerin.jacob@caviumnetworks.com> wrote:
> > CC: Jianbo Liu <jianbo.liu@linaro.org>
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
> > lib/librte_eal/common/include/arch/arm/rte_atomic_64.h | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > index 78ebea2..ef0efc7 100644
> > --- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > +++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > @@ -88,6 +88,12 @@ static inline void rte_rmb(void)
> >
> > #define rte_smp_rmb() dmb(ishld)
> >
> > +#define rte_io_mb() rte_mb()
> > +
> > +#define rte_io_wmb() rte_wmb()
> > +
> > +#define rte_io_rmb() rte_rmb()
> > +
>
> I think it's better to use outer shareable dmb for io barrier, instead of dsb.
Its is difficult to generalize. AFAIK, from the IO barrier perspective
dsb would be the right candidate. But just for the DMA barrier between IO may
be outer sharable dmb is enough. In-terms of performance implication, the
fastpath code(door bell write) has been changed to relaxed write in all
the drivers in this patchset and rte_io_* will be only
used by rte_[read/write]8/16/32/64 which will be in slow-path.
So, IMO, it better stick with dsb and its safe from the complete IO barrier
perspective.
At least on ThunderX, I couldn't see any performance difference between
using dsb(st) and dmb(oshst) for dma write barrier before the doorbell register
write in fastpath. In case there are platforms which has such performance difference,
may be could add rte_dma_wmb() and rte_dma_rmb() in future like Linux kernel
dma_wmb() and dma_rmb().(But i couldn't see all the driver are using it,
though)
Jerin
^ permalink raw reply
* Re: [PATCH v2 00/25] Generic flow API (rte_flow)
From: Simon Horman @ 2017-01-04 9:53 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: dev
In-Reply-To: <20161222124804.GD10340@6wind.com>
On Thu, Dec 22, 2016 at 01:48:04PM +0100, Adrien Mazarguil wrote:
> On Wed, Dec 21, 2016 at 05:19:16PM +0100, Simon Horman wrote:
> > On Fri, Dec 16, 2016 at 05:24:57PM +0100, Adrien Mazarguil wrote:
> > > As previously discussed in RFC v1 [1], RFC v2 [2], with changes
> > > described in [3] (also pasted below), here is the first non-draft series
> > > for this new API.
> > >
> > > Its capabilities are so generic that its name had to be vague, it may be
> > > called "Generic flow API", "Generic flow interface" (possibly shortened
> > > as "GFI") to refer to the name of the new filter type, or "rte_flow" from
> > > the prefix used for its public symbols. I personally favor the latter.
> > >
> > > While it is currently meant to supersede existing filter types in order for
> > > all PMDs to expose a common filtering/classification interface, it may
> > > eventually evolve to cover the following ideas as well:
> > >
> > > - Rx/Tx offloads configuration through automatic offloads for specific
> > > packets, e.g. performing checksum on TCP packets could be expressed with
> > > an egress rule with a TCP pattern and a kind of checksum action.
> > >
> > > - RSS configuration (already defined actually). Could be global or per rule
> > > depending on hardware capabilities.
> > >
> > > - Switching configuration for devices with many physical ports; rules doing
> > > both ingress and egress could even be used to completely bypass software
> > > if supported by hardware.
Hi Adrien,
apologies for not replying for some time due to my winter vacation.
> Hi Simon,
>
> > Hi Adrien,
> >
> > thanks for this valuable work.
> >
> > I would like to ask some high level questions on the proposal.
> > I apologise in advance if any of these questions are based on a
> > misunderstanding on my part.
> >
> > * I am wondering about provisions for actions to modify packet data or
> > metadata. I do see support for marking packets. Is the implication of
> > this that the main focus is to provide a mechanism for classification
> > with the assumption that any actions - other than drop and variants of
> > output - would be performed elsewhere?
>
> I'm not sure to understand what you mean by "elsewhere" here. Packet marking
> as currently defined is a purely ingress action, i.e. HW matches some packet
> and returns a user-defined tag in related meta-data that the PMD copies to
> the appropriate mbuf structure field before returning it to the application.
By elsewhere I meant in the application, sorry for being unclear.
> There is provision for egress rules and I wrote down a few ideas describing
> how they could be useful (as above), however they remain to be defined.
>
> > If so I would observe that this seems somewhat limiting in the case of
> > hardware that can perform a richer set of actions. And seems particularly
> > limiting on egress as there doesn't seem anywhere else that other actions
> > could be performed after classification is performed by this API.
>
> A single flow rule may contain any number of distinct actions. For egress,
> it means you could wrap matching packets in VLAN and VXLAN at once.
>
> If you wanted to perform the same action twice on matching packets, you'd
> have to provide two rules with defined priorities and use a non-terminating
> action for the first one:
>
> - Rule with priority 0: match UDP -> add VLAN 42, passthrough
> - Rule with priority 1: match UDP -> add VLAN 64, terminating
>
> This is how automatic QinQ would be defined for outgoing UDP packets.
Ok understood. I have two follow-up questions:
1. Is the "add VLAN" action included at this time, I was not able to find it
2. Was consideration given to allowing multiple actions in a single rule?
I see there would be some advantage to that if classification is
expensive.
> > * I am curious to know what considerations have been given to supporting support for tunnelling (encapsulation and decapsulation of e.g. VXLAN),
> > tagging (pushing and popping e.g. VLANs), and labels (pushing or popping
> > e.g. MPLS).
> >
> > Such features seem would useful for application of this work in a variety
> > of situations including overlay networks and VNFs.
>
> This is also what I had in mind and we'd only have to define specific
> ingress/egress actions for these. Currently rte_flow only implements a basic
> set of existing features from the legacy filtering framework, but is meant
> to be extended.
Thanks. I think that answers most of my questions: what I see as missing
in terms of actions can be added.
> > * I am wondering if any thought has gone into supporting matching on the
> > n-th instance of a field that may appear more than once: e.g. VLAN tag.
>
> Sure, please see the latest documentation [1] and testpmd examples [2].
> Pattern items being stacked in the same order as protocol layers, maching
> specific QinQ traffic and redirecting it to some queue could be expressed
> with something like:
>
> testpmd> flow create 0 ingress pattern eth / vlan vid is 64 / vlan vid is 42 / end
> actions queue 6 / end
>
> Such a rule is translated as-is to rte_flow pattern items and action
> structures.
Thanks, I will look over that.
> > With the above questions in mind I am curious to know what use-cases
> > the proposal is targeted at.
>
> Well, it should be easier to answer if you have a specific use-case in mind
> you would like to support but that cannot be expressed with the API as
> defined in [1], in which case please share it with the community.
A use-case would be implementing OvS DPIF flow offload using this API.
> [1] http://dpdk.org/ml/archives/dev/2016-December/052954.html
> [2] http://dpdk.org/ml/archives/dev/2016-December/052975.html
^ permalink raw reply
* Re: [PATCH v3 3/4] net/ixgbe: add firmware version get
From: Yang, Qiming @ 2017-01-04 9:48 UTC (permalink / raw)
To: Yigit, Ferruh, dev@dpdk.org, thomas.monjalon@6wind.com; +Cc: Horton, Remy
In-Reply-To: <f3cbfc26-3fba-8590-6142-6e0abc5b4cfd@intel.com>
Yes, etrack_id is an unique value. But not all NICs have this value.
I didn't find any value about fw version in fm10k.
I40e is 8 bit too.
firmware-version: 5.04 0x800024ca
-----Original Message-----
From: Yigit, Ferruh
Sent: Wednesday, January 4, 2017 5:06 PM
To: Yang, Qiming <qiming.yang@intel.com>; dev@dpdk.org; thomas.monjalon@6wind.com
Cc: Horton, Remy <remy.horton@intel.com>
Subject: Re: [PATCH v3 3/4] net/ixgbe: add firmware version get
On 1/4/2017 2:44 AM, Yang, Qiming wrote:
> You can see the kernel version ethtool, use command 'ethtool -i <ixgbe NIC name>'
> driver: ixgbe
> version: 4.2.1-k
> firmware-version: 0x61bf0001
>
> Ixgbe's FW version do not have the major and minor number, and the original purpose of this function is get FW version, so I think it's enough.
Is etrack_id a unique value that defines the FW version on its own?
And is above definition true for all NICs (or at least Intel ones)?
Because I can see i40e is using 4 bit value for etrack_id ?
>
> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Tuesday, January 3, 2017 11:04 PM
> To: Yang, Qiming <qiming.yang@intel.com>; dev@dpdk.org; thomas.monjalon@6wind.com
> Cc: Horton, Remy <remy.horton@intel.com>
> Subject: Re: [PATCH v3 3/4] net/ixgbe: add firmware version get
>
> On 12/27/2016 12:30 PM, Qiming Yang wrote:
>> This patch add a new function ixgbe_fw_version_get.
>>
>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>
> <...>
>
>>
>> static void
>> +ixgbe_fw_version_get(struct rte_eth_dev *dev, __rte_unused u32 *fw_major,
>> + __rte_unused u32 *fw_minor, __rte_unused u32 *fw_patch, u32
>> +*etrack_id)
>
> This API at least provide major and minor fw versions I think. Isn't there any kind of FW version information for ixgbe? Just providing etrack_id is not looking good.
>
>> +{
>> + struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>> + u16 eeprom_verh, eeprom_verl;
>> +
>> + ixgbe_read_eeprom(hw, 0x2e, &eeprom_verh);
>> + ixgbe_read_eeprom(hw, 0x2d, &eeprom_verl);
>> +
>> + *etrack_id = (eeprom_verh << 16) | eeprom_verl; }
>> +
>> +static void
>> ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info
>> *dev_info) {
>> struct rte_pci_device *pci_dev = IXGBE_DEV_TO_PCI(dev);
>>
>
^ permalink raw reply
* Re: [PATCH v3 3/4] net/ixgbe: add firmware version get
From: Ferruh Yigit @ 2017-01-04 9:06 UTC (permalink / raw)
To: Yang, Qiming, dev@dpdk.org, thomas.monjalon@6wind.com; +Cc: Horton, Remy
In-Reply-To: <F5DF4F0E3AFEF648ADC1C3C33AD4DBF16EDC98D4@SHSMSX101.ccr.corp.intel.com>
On 1/4/2017 2:44 AM, Yang, Qiming wrote:
> You can see the kernel version ethtool, use command 'ethtool -i <ixgbe NIC name>'
> driver: ixgbe
> version: 4.2.1-k
> firmware-version: 0x61bf0001
>
> Ixgbe's FW version do not have the major and minor number, and the original purpose of this function is get FW version, so I think it's enough.
Is etrack_id a unique value that defines the FW version on its own?
And is above definition true for all NICs (or at least Intel ones)?
Because I can see i40e is using 4 bit value for etrack_id ?
>
> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Tuesday, January 3, 2017 11:04 PM
> To: Yang, Qiming <qiming.yang@intel.com>; dev@dpdk.org; thomas.monjalon@6wind.com
> Cc: Horton, Remy <remy.horton@intel.com>
> Subject: Re: [PATCH v3 3/4] net/ixgbe: add firmware version get
>
> On 12/27/2016 12:30 PM, Qiming Yang wrote:
>> This patch add a new function ixgbe_fw_version_get.
>>
>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>
> <...>
>
>>
>> static void
>> +ixgbe_fw_version_get(struct rte_eth_dev *dev, __rte_unused u32 *fw_major,
>> + __rte_unused u32 *fw_minor, __rte_unused u32 *fw_patch, u32
>> +*etrack_id)
>
> This API at least provide major and minor fw versions I think. Isn't there any kind of FW version information for ixgbe? Just providing etrack_id is not looking good.
>
>> +{
>> + struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>> + u16 eeprom_verh, eeprom_verl;
>> +
>> + ixgbe_read_eeprom(hw, 0x2e, &eeprom_verh);
>> + ixgbe_read_eeprom(hw, 0x2d, &eeprom_verl);
>> +
>> + *etrack_id = (eeprom_verh << 16) | eeprom_verl; }
>> +
>> +static void
>> ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info
>> *dev_info) {
>> struct rte_pci_device *pci_dev = IXGBE_DEV_TO_PCI(dev);
>>
>
^ permalink raw reply
* Re: [PATCH v3 2/4] net/e1000: add firmware version get
From: Ferruh Yigit @ 2017-01-04 8:47 UTC (permalink / raw)
To: Yang, Qiming, dev@dpdk.org, thomas.monjalon@6wind.com; +Cc: Horton, Remy
In-Reply-To: <F5DF4F0E3AFEF648ADC1C3C33AD4DBF16EDC990A@SHSMSX101.ccr.corp.intel.com>
On 1/4/2017 3:14 AM, Yang, Qiming wrote:
> See the reply below.
>
> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Tuesday, January 3, 2017 11:03 PM
> To: Yang, Qiming <qiming.yang@intel.com>; dev@dpdk.org; thomas.monjalon@6wind.com
> Cc: Horton, Remy <remy.horton@intel.com>
> Subject: Re: [PATCH v3 2/4] net/e1000: add firmware version get
>
> On 12/27/2016 12:30 PM, Qiming Yang wrote:
>> This patch adds a new function eth_igb_fw_version_get.
>>
>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>> ---
>> v3 changes:
>> * use eth_igb_fw_version_get(struct rte_eth_dev *dev, u32 *fw_major,
>> u32 *fw_minor, u32 *fw_minor, u32 *fw_patch, u32 *etrack_id) instead
>> of eth_igb_fw_version_get(struct rte_eth_dev *dev, char *fw_version,
>> int fw_length). Add statusment in /doc/guides/nics/features/igb.ini.
>> ---
>> ---
>> doc/guides/nics/features/igb.ini | 1 +
>> drivers/net/e1000/igb_ethdev.c | 43 ++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 44 insertions(+)
>>
>> diff --git a/doc/guides/nics/features/igb.ini
>> b/doc/guides/nics/features/igb.ini
>> index 9fafe72..ffd87ba 100644
>> --- a/doc/guides/nics/features/igb.ini
>> +++ b/doc/guides/nics/features/igb.ini
>> @@ -39,6 +39,7 @@ EEPROM dump = Y
>> Registers dump = Y
>> BSD nic_uio = Y
>> Linux UIO = Y
>> +FW version = Y
>
> Please keep same location with default.ini file. Why you are putting this just into middle of the uio and vfio?
> Qiming: It's a clerical error, I want to add this line at the end of this file.
>
>> Linux VFIO = Y
>> x86-32 = Y
>> x86-64 = Y
>> diff --git a/drivers/net/e1000/igb_ethdev.c
>> b/drivers/net/e1000/igb_ethdev.c index 4a15447..25344b7 100644
>> --- a/drivers/net/e1000/igb_ethdev.c
>> +++ b/drivers/net/e1000/igb_ethdev.c
>> @@ -120,6 +120,8 @@ static int eth_igb_xstats_get_names(struct rte_eth_dev *dev,
>> unsigned limit);
>> static void eth_igb_stats_reset(struct rte_eth_dev *dev); static
>> void eth_igb_xstats_reset(struct rte_eth_dev *dev);
>> +static void eth_igb_fw_version_get(struct rte_eth_dev *dev, u32 *fw_major,
>> + u32 *fw_minor, u32 *fw_patch, u32 *etrack_id);
>
> I think you can use a struct as parameter here. But beware, that struct should NOT be a public struct.
> Qiming: I think only add a private struct for igb is unnecessary. Keep the arguments consistent with rte_eth_dev_fw_info_get is better.
> What do you think?
Both are OK.
Normally, I believe using struct is better. But we are not using struct
in public API because of the ABI compatibility issues. Here it is
internal usage, there is no ABI breakage concern, so it may be possible
to use a struct.
But if you prefer to keep the arguments same here with public API, that
is fine.
>
>> static void eth_igb_infos_get(struct rte_eth_dev *dev,
>> struct rte_eth_dev_info *dev_info); static const uint32_t
>> *eth_igb_supported_ptypes_get(struct rte_eth_dev *dev); @@ -389,6
>> +391,7 @@ static const struct eth_dev_ops eth_igb_ops = {
>> .xstats_get_names = eth_igb_xstats_get_names,
>> .stats_reset = eth_igb_stats_reset,
>> .xstats_reset = eth_igb_xstats_reset,
>> + .fw_version_get = eth_igb_fw_version_get,
>> .dev_infos_get = eth_igb_infos_get,
>> .dev_supported_ptypes_get = eth_igb_supported_ptypes_get,
>> .mtu_set = eth_igb_mtu_set,
>> @@ -1981,6 +1984,46 @@ eth_igbvf_stats_reset(struct rte_eth_dev *dev)
>> }
>>
>
> <...>
>
^ permalink raw reply
* Re: [PATCH v3 1/4] ethdev: add firmware information get
From: Ferruh Yigit @ 2017-01-04 8:43 UTC (permalink / raw)
To: Wu, Jingjing, Yang, Qiming; +Cc: dev@dpdk.org, Horton, Remy, Thomas Monjalon
In-Reply-To: <9BB6961774997848B5B42BEC655768F810CC2AF1@SHSMSX103.ccr.corp.intel.com>
On 1/4/2017 7:48 AM, Wu, Jingjing wrote:
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yang, Qiming
>> Sent: Wednesday, January 4, 2017 11:33 AM
>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>> Cc: dev@dpdk.org; Horton, Remy <remy.horton@intel.com>; Thomas Monjalon
>> <thomas.monjalon@6wind.com>
>> Subject: Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add firmware information get
>>
>> Yes, in my opinion it is. And I use this name already exist in the share code from
>> ND team.
>>
>> -----Original Message-----
>> From: Yigit, Ferruh
>> Sent: Tuesday, January 3, 2017 10:49 PM
>> To: Yang, Qiming <qiming.yang@intel.com>
>> Cc: dev@dpdk.org; Horton, Remy <remy.horton@intel.com>; Thomas Monjalon
>> <thomas.monjalon@6wind.com>
>> Subject: Re: [PATCH v3 1/4] ethdev: add firmware information get
>>
>> On 1/3/2017 9:05 AM, Yang, Qiming wrote:
>>> Hi, Ferruh
>>> Please see the question below. In my opinion, etrack_id is just a name used to
>> define the ID of one NIC.
>>> In kernel version ethtool, it will print this ID in the line of firmware verison.
>>> I know what is etrack_id mean, but I really don't know why this named
>> etrack_id.
>>
>> Hi Qiming,
>>
>> I suggested the API based on fields you already used in your patch.
>>
>> So, this API is to get FW version, is etrack_id something that defines (part of)
>> firmware version?
>>
>> Thanks,
>> ferruh
>>
>>
> Different HW may have different version format, so it is better to use string.
>
> And I prefer the API definition in your v2 patch like
>
> rte_eth_dev_fwver_get(uint8_t port_id, char *fw_version, int fw_length);
The problem with this is the format and content of the string is not
defined, as you said different HW has different version format. This is
no problem if you will only print the string.
But this is a public API, if an application wants to call this API and
do something useful according the FW version information, it will need
to parse the string, and it will not able to parse it because format of
the string is not defined. By making API fill some defined variables,
app won't need to parse them, and API output won't be HW dependent.
Thanks,
ferruh
>
> Thanks
> Jingjing
>
^ permalink raw reply
* [PATCH] crypto/qat: add scatter gather option to QAT feature flags
From: Arek Kusztal @ 2017-01-04 8:37 UTC (permalink / raw)
To: dev
Cc: fiona.trahe, pablo.de.lara.guarch, john.griffin, deepak.k.jain,
Arek Kusztal
This commit adds scatter gather option to Intel(R) QuickAssist
Technology driver feature flags.
Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
This patch depends on the following patches/patchsets:
"crypto: add sgl support in sw PMDs"
(http://dpdk.org/dev/patchwork/patch/18693)
drivers/crypto/qat/rte_qat_cryptodev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c b/drivers/crypto/qat/rte_qat_cryptodev.c
index 1e7ee61..9594067 100644
--- a/drivers/crypto/qat/rte_qat_cryptodev.c
+++ b/drivers/crypto/qat/rte_qat_cryptodev.c
@@ -100,7 +100,8 @@ crypto_qat_dev_init(__attribute__((unused)) struct rte_cryptodev_driver *crypto_
cryptodev->feature_flags = RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO |
RTE_CRYPTODEV_FF_HW_ACCELERATED |
- RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING;
+ RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING |
+ RTE_CRYPTODEV_FF_MBUF_SCATTER_GATHER;
internals = cryptodev->data->dev_private;
internals->max_nb_sessions = RTE_QAT_PMD_MAX_NB_SESSIONS;
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v5 0/8] Add MACsec offload support for ixgbe
From: Peng, Yuan @ 2017-01-04 8:29 UTC (permalink / raw)
To: Bie, Tiwei, dev@dpdk.org
Cc: adrien.mazarguil@6wind.com, Lu, Wenzhuo, Mcnamara, John,
olivier.matz@6wind.com, thomas.monjalon@6wind.com,
Ananyev, Konstantin, Zhang, Helin, Dai, Wei, Wang, Xiao W
In-Reply-To: <1483514502-32841-1-git-send-email-tiwei.bie@intel.com>
Tested-by: Peng Yuan <yuan.peng@intel.com>
- Tested Branch: master
- Tested Commit: eac901ce29be559b1bb5c5da33fe2bf5c0b4bfd6
- OS: Fedora24 4.5.5-300.fc24.x86_64
- GCC: gcc version 5.3.1 20151207
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb]
- Default x86_64-native-linuxapp-gcc configuration
- Total 5 cases, 5 passed, 0 failed
- Prerequisites:
1x Niantic NIC (2x 10G)
2x IXIA ports (10G)
- Added commands:
testpmd>set macsec offload (port_id) on encrypt (on|off) replay-protect (on|off)
" Enable MACsec offload. "
testpmd>set macsec offload (port_id) off
" Disable MACsec offload. "
testpmd>set macsec sc (tx|rx) (port_id) (mac) (pi)
" Configure MACsec secure connection (SC). "
testpmd>set macsec sa (tx|rx) (port_id) (idx) (an) (pn) (key)
" Configure MACsec secure association (SA). "
- Test Case 1: MACsec packets send and receive
============================================
1. bind two ports to dpdk driver::
./tools/dpdk-devbind.py -b igb_uio 07:00.0 07:00.1
2. config the rx port
1). start the testpmd of rx port::
./testpmd -c 0xc --socket-mem 1024,1024 --file-prefix=rx -w 0000:07:00.1 \
-- --port-topology=chained -i --crc-strip
2). set MACsec offload on::
testpmd>set macsec offload 0 on encrypt on replay-protect on
3). set MACsec parameters as rx_port::
testpmd>set macsec sc rx 0 00:00:00:00:00:01 0
testpmd>set macsec sa rx 0 0 0 0 00112200000000000000000000000000
4). set MACsec parameters as tx_port::
testpmd>set macsec sc tx 0 00:00:00:00:00:02 0
testpmd>set macsec sa tx 0 0 0 0 00112200000000000000000000000000
5). set rxonly::
testpmd>set fwd rxonly
6). start::
testpmd>set promisc all on
testpmd>start
3. config the tx port
1). start the testpmd of tx port::
./testpmd -c 0x30 --socket-mem 1024,1024 --file-prefix=tx -w 0000:07:00.0 \
-- --port-topology=chained -i --crc-strip --txqflags=0x0
2). set MACsec offload on::
testpmd>set macsec offload 0 on encrypt on replay-protect on
3). set MACsec parameters as tx_port::
testpmd>set macsec sc tx 0 00:00:00:00:00:01 0
testpmd>set macsec sa tx 0 0 0 0 00112200000000000000000000000000
4). set MACsec parameters as rx_port::
testpmd>set macsec sc rx 0 00:00:00:00:00:02 0
testpmd>set macsec sa rx 0 0 0 0 00112200000000000000000000000000
5). set txonly::
testpmd>set fwd txonly
6). start::
testpmd>start
4. check the result::
testpmd>stop
testpmd>show port xstats 0
stop the packet transmiting on tx_port first, then stop the packet receiving
on rx_port.
check the rx data and tx data:
tx_good_packets == rx_good_packets
out_pkts_encrypted == in_pkts_ok == tx_good_packets == rx_good_packets
out_octets_encrypted == in_octets_decrypted
out_octets_protected == in_octets_validated
if you want to check the content of the packet, use the command::
testpmd>set verbose 1
the received packets are Decrypted.
check the ol_flags:PKT_RX_IP_CKSUM_GOOD
check the content of the packet:
type=0x0800, the ptype of L2,L3,L4: L2_ETHER L3_IPV4 L4_UDP
Test Case 2: MACsec packets send and normal receive
===================================================
1. disable MACsec offload on rx port::
testpmd>set macsec offload 0 off
2. start the the packets transfer
3. check the result::
testpmd>stop
testpmd>show port xstats 0
stop the testpmd on tx_port first, then stop the testpmd on rx_port.
the received packets are encrypted.
check the content of the packet:
type=0x88e5 sw ptype: L2_ETHER - l2_len=14 - Receive queue=0x0
you can't find L3 and L4 infomation in the packet
in_octets_decrypted and in_octets_validated doesn't increase on last data
transfer.
Test Case 3: normal packet send and MACsec receive
==================================================
1. enable MACsec offload on rx port::
testpmd>set macsec offload 0 on encrypt on replay-protect on
2. disable MACsec offload on tx port::
testpmd>set macsec offload 0 off
3. start the the packets transfer
4. check the result::
testpmd>stop
testpmd>show port xstats 0
stop the testpmd on tx_port first, then stop the testpmd on rx_port.
the received packets are not encrypted.
check the content of the packet:
type=0x0800, the ptype of L2,L3,L4: L2_ETHER L3_IPV4 L4_UDP
in_octets_decrypted and out_pkts_encrypted doesn't increase on last data
transfer.
Test Case 4: MACsec send and receive with wrong parameters
==========================================================
1. don't add "--txqflags=0x0" in the tx_port command line.
the MACsec offload can't work. the tx packets are normal packets.
2. set different pn on rx and tx port, then start the data transfer.
1) set the parameters as test case 1, start and stop the data transfer.
check the result, rx port can receive and decrypt the packets normally.
2) reset the pn of tx port to 0::
testpmd>set macsec sa tx 0 0 0 0 00112200000000000000000000000000
rx port can receive the packets until the pn equals the pn of tx port::
out_pkts_encrypted = in_pkts_late + in_pkts_ok
2. set different keys on rx and tx port, then start the data transfer::
the RX-packets=0,
in_octets_decrypted == out_octets_encrypted,
in_pkts_notvalid == out_pkts_encrypted,
in_pkts_ok=0,
rx_good_packets=0
3. set different pi on rx and tx port(reset on rx_port), then start the data
transfer::
in_octets_decrypted == out_octets_encrypted,
in_pkts_ok = 0,
in_pkts_nosci == out_pkts_encrypted
4. set different an on rx and tx port, then start the data transfer::
rx_good_packets=0,
in_octets_decrypted == out_octets_encrypted,
in_pkts_notusingsa == out_pkts_encrypted,
in_pkts_ok=0,
rx_good_packets=0
5. set different index on rx and tx port, then start the data transfer::
in_octets_decrypted == out_octets_encrypted,
in_pkts_ok == out_pkts_encrypted
Test Case 5: performance test of MACsec offload packets
==========================================================
1. tx linerate
port0 connected to IXIA port5, port1 connected to IXIA port6, set port0
MACsec offload on, set fwd mac.
on IXIA side, start IXIA port6 transmit, start the IXIA capture.
view the IXIA port5 captrued packet, the protocol is MACsec, the EtherType
is 0x88E5, and the packet length is 96bytes, more than the normal packet
32 bytes.
The valid frames received rate is 10.78Mpps, and the %linerate is 100%.
2. rx linerate
there are three ports 05:00.0 07:00.0 07:00.1. connect 07:00.0 to 07:00.1
with cable, connect 05:00.0 to IXIA. bind the three ports to dpdk driver.
start two testpmd::
./testpmd -c 0x3 --socket-mem 1024,1024 --file-prefix=rx -w 0000:07:00.1 \
-- --port-topology=chained -i --crc-strip --txqflags=0x0
testpmd>set macsec offload 0 on encrypt on replay-protect on
testpmd>set macsec sc rx 0 00:00:00:00:00:01 0
testpmd>set macsec sa rx 0 0 0 0 00112200000000000000000000000000
testpmd>set macsec sc tx 0 00:00:00:00:00:02 0
testpmd>set macsec sa tx 0 0 0 0 00112200000000000000000000000000
testpmd>set fwd rxonly
./testpmd -c 0xc --socket-mem 1024,1024 --file-prefix=tx -b 0000:07:00.1 \
-- --port-topology=chained -i --crc-strip --txqflags=0x0
testpmd>set macsec offload 1 on encrypt on replay-protect on
testpmd>set macsec sc rx 1 00:00:00:00:00:02 0
testpmd>set macsec sa rx 1 0 0 0 00112200000000000000000000000000
testpmd>set macsec sc tx 1 00:00:00:00:00:01 0
testpmd>set macsec sa tx 1 0 0 0 00112200000000000000000000000000
testpmd>set fwd mac
start on both two testpmd.
start data transmit from IXIA port, the frame size is 64bytes,
the Ethertype is 0x0800. the rate is 14.88Mpps.
check the linerate on rxonly port::
testpmd>show port stats 0
It shows "Rx-pps: 10775697", so the rx %linerate is 100%.
check the MACsec packets number on tx side::
testpmd>show port xstats 1
on rx side::
testpmd>show port xstats 0
in_pkts_ok == out_pkts_encrypted
-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tiwei Bie
Sent: Wednesday, January 4, 2017 3:22 PM
To: dev@dpdk.org
Cc: adrien.mazarguil@6wind.com; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Mcnamara, John <john.mcnamara@intel.com>; olivier.matz@6wind.com; thomas.monjalon@6wind.com; Ananyev, Konstantin <konstantin.ananyev@intel.com>; Zhang, Helin <helin.zhang@intel.com>; Dai, Wei <wei.dai@intel.com>; Wang, Xiao W <xiao.w.wang@intel.com>
Subject: [dpdk-dev] [PATCH v5 0/8] Add MACsec offload support for ixgbe
This patch set adds the MACsec offload support for ixgbe.
The testpmd is also updated to support MACsec cmds.
v2:
- Update the documents for testpmd;
- Update the release notes;
- Reuse the functions provided by base code;
v3:
- Add the missing parts of MACsec mbuf flag and reorganize the patch set;
- Add an ethdev event type for MACsec;
- Advertise the MACsec offload capabilities based on the mac type;
- Minor fixes and improvements;
v4:
- Reserve bits in mbuf and ethdev for PMD specific API;
- Use the reserved bits in PMD specific API;
v5:
- Add MACsec offload in the NIC feature list;
- Minor improvements on comments;
Tiwei Bie (8):
mbuf: reserve a Tx offload flag for PMD-specific API
ethdev: reserve an event type for PMD-specific API
ethdev: reserve capability flags for PMD-specific API
net/ixgbe: add MACsec offload support
app/testpmd: add MACsec offload commands
doc: add ixgbe specific APIs
doc: update the release notes for the reserved flags
doc: add MACsec offload into NIC feature list
app/test-pmd/cmdline.c | 389 ++++++++++++++++++++++
app/test-pmd/macfwd.c | 7 +
app/test-pmd/macswap.c | 7 +
app/test-pmd/testpmd.h | 2 +
app/test-pmd/txonly.c | 7 +
doc/guides/nics/features/default.ini | 1 +
doc/guides/nics/features/ixgbe.ini | 1 +
doc/guides/rel_notes/release_17_02.rst | 18 ++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 32 ++
drivers/net/ixgbe/ixgbe_ethdev.c | 481 +++++++++++++++++++++++++++-
drivers/net/ixgbe/ixgbe_ethdev.h | 45 +++
drivers/net/ixgbe/ixgbe_rxtx.c | 5 +
drivers/net/ixgbe/rte_pmd_ixgbe.h | 122 +++++++
drivers/net/ixgbe/rte_pmd_ixgbe_version.map | 11 +
lib/librte_ether/rte_ethdev.h | 4 +
lib/librte_mbuf/rte_mbuf.c | 2 +
lib/librte_mbuf/rte_mbuf.h | 5 +
17 files changed, 1134 insertions(+), 5 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH v4 1/2] net/vhost: create datagram sockets immediately
From: Yuanhan Liu @ 2017-01-04 8:06 UTC (permalink / raw)
To: Charles (Chas) Williams; +Cc: dev, mtetsuyah, stable
In-Reply-To: <1483460563-5003-1-git-send-email-ciwillia@brocade.com>
On Tue, Jan 03, 2017 at 11:22:42AM -0500, Charles (Chas) Williams wrote:
> If you create a vhost server device, it doesn't create the actual datagram
> socket until you call .dev_start(). If you call .dev_stop() is also
> deletes those sockets. For QEMU clients, this is a problem since QEMU
> doesn't know how to re-attach to datagram sockets that have gone away.
>
> To fix this, register and unregister the datagram sockets during device
> creation and removal.
>
> Fixes: ee584e9710b9 ("vhost: add driver on top of the library")
Both patches applied to dpdk-next-virtio. Thanks!
Note that we prefer a title of "prefix: fix ..." for bug fixing patch.
For this reason, I have changed the title for you while apply:
net/vhost: fix socket file being deleted on dev stop
Also, stable is cc'ed.
--yliu
^ permalink raw reply
* Re: [PATCH v3] ethtool: dispaly bus info and firmware version
From: Wu, Jingjing @ 2017-01-04 7:51 UTC (permalink / raw)
To: Yang, Qiming, dev@dpdk.org, thomas.monjalon@6wind.com
Cc: Horton, Remy, Yigit, Ferruh, Yang, Qiming
In-Reply-To: <1482843968-6483-1-git-send-email-qiming.yang@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qiming Yang
> Sent: Tuesday, December 27, 2016 9:06 PM
> To: dev@dpdk.org; thomas.monjalon@6wind.com
> Cc: Horton, Remy <remy.horton@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Yang, Qiming <qiming.yang@intel.com>
> Subject: [dpdk-dev] [PATCH v3] ethtool: dispaly bus info and firmware version
>
> This patch enhances the ethtool example to support to show bus information
> and firmware version, in the same way that the Linux kernel ethtool does.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> ---
> v3 changes:
> * split this patch from the patch set of rte_eth_dev_fw_info_get
> use the new version function.
> ---
> ---
> examples/ethtool/ethtool-app/ethapp.c | 2 ++
> examples/ethtool/lib/rte_ethtool.c | 11 +++++++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/examples/ethtool/ethtool-app/ethapp.c
> b/examples/ethtool/ethtool-app/ethapp.c
> index 6aeaa06..192d941 100644
> --- a/examples/ethtool/ethtool-app/ethapp.c
> +++ b/examples/ethtool/ethtool-app/ethapp.c
> @@ -185,6 +185,8 @@ pcmd_drvinfo_callback(__rte_unused void *ptr_params,
> printf("Port %i driver: %s (ver: %s)\n",
> id_port, info.driver, info.version
> );
> + printf("bus-info: %s\n", info.bus_info);
This patch has dependence on your get_fw_version patch set.
I think you may misunderstand Ferruh's comments,
I think what he said was ask you to remove bus-info print (above line) from that patch set,
but keep firmware version print.
Thanks
Jingjing
^ permalink raw reply
* Re: [PATCH v3 1/4] ethdev: add firmware information get
From: Wu, Jingjing @ 2017-01-04 7:48 UTC (permalink / raw)
To: Yang, Qiming, Yigit, Ferruh; +Cc: dev@dpdk.org, Horton, Remy, Thomas Monjalon
In-Reply-To: <F5DF4F0E3AFEF648ADC1C3C33AD4DBF16EDC998C@SHSMSX101.ccr.corp.intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yang, Qiming
> Sent: Wednesday, January 4, 2017 11:33 AM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: dev@dpdk.org; Horton, Remy <remy.horton@intel.com>; Thomas Monjalon
> <thomas.monjalon@6wind.com>
> Subject: Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add firmware information get
>
> Yes, in my opinion it is. And I use this name already exist in the share code from
> ND team.
>
> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Tuesday, January 3, 2017 10:49 PM
> To: Yang, Qiming <qiming.yang@intel.com>
> Cc: dev@dpdk.org; Horton, Remy <remy.horton@intel.com>; Thomas Monjalon
> <thomas.monjalon@6wind.com>
> Subject: Re: [PATCH v3 1/4] ethdev: add firmware information get
>
> On 1/3/2017 9:05 AM, Yang, Qiming wrote:
> > Hi, Ferruh
> > Please see the question below. In my opinion, etrack_id is just a name used to
> define the ID of one NIC.
> > In kernel version ethtool, it will print this ID in the line of firmware verison.
> > I know what is etrack_id mean, but I really don't know why this named
> etrack_id.
>
> Hi Qiming,
>
> I suggested the API based on fields you already used in your patch.
>
> So, this API is to get FW version, is etrack_id something that defines (part of)
> firmware version?
>
> Thanks,
> ferruh
>
>
Different HW may have different version format, so it is better to use string.
And I prefer the API definition in your v2 patch like
rte_eth_dev_fwver_get(uint8_t port_id, char *fw_version, int fw_length);
Thanks
Jingjing
^ permalink raw reply
* Re: [PATCH v2 5/7] net/virtio_user: add vhost kernel support
From: Yuanhan Liu @ 2017-01-04 7:46 UTC (permalink / raw)
To: Tan, Jianfeng; +Cc: dev, ferruh.yigit, cunming.liang
In-Reply-To: <59e32f20-fe7a-20ad-1aa6-99fc90322a42@intel.com>
On Wed, Jan 04, 2017 at 03:22:08PM +0800, Tan, Jianfeng wrote:
>
> Sorry, I forget to reply this comment.
>
> On 12/26/2016 3:44 PM, Yuanhan Liu wrote:
> >[...]
> >>+
> >>+ /* Does not work when VIRTIO_F_IOMMU_PLATFORM now, why? */
> >Because this feature need the vhost IOTLB support from the device
> >emulation. Patches for QEMU hasn't been merged yet, but it has been
> >there for a while.
>
> Yes. And it's in need of help from QEMU.
>
> >
> >Since we don't have the support yet, for sure it won't work. But
> >I'm wondering why you have to disable it explicitly?
>
> Here we do not have QEMU. Frontend driver talks with vhost-net through
> virtio_user_dev. And both ends claim to support VIRTIO_F_IOMMU_PLATFORM. So
> this feature bit will be negotiated if we don't explicitly disable it. In my
> previous test, it fails in vhost_init_device_iotlb() of vhost kernel module.
> My guess is that, for this feature, without the help of QEMU, vhost kernel
> module cannot work independently.
The negotiation is a work between the driver, the device and the vhost
backend. If the device doesn't claim to support it, how could it be
nenogitated.
Think that way, does old QEMU (that doesn't support this feature) disable this
feature explicitly? No. Then why do we have to do that?
--yliu
^ permalink raw reply
* Re: [PATCH v2 5/9] net/virtio: setup rxq interrupts
From: Tan, Jianfeng @ 2017-01-04 7:30 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev@dpdk.org, stephen@networkplumber.org
In-Reply-To: <20170104072256.GK21228@yliu-dev.sh.intel.com>
> -----Original Message-----
> From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
> Sent: Wednesday, January 4, 2017 3:23 PM
> To: Tan, Jianfeng
> Cc: dev@dpdk.org; stephen@networkplumber.org
> Subject: Re: [PATCH v2 5/9] net/virtio: setup rxq interrupts
>
> On Wed, Jan 04, 2017 at 02:56:50PM +0800, Tan, Jianfeng wrote:
> >
> >
> > [...]
> > >>+
> > >>+ if (virtio_queues_bind_intr(dev) < 0) {
> > >>+ PMD_INIT_LOG(ERR, "Failed to bind queue/interrupt");
> > >>+ return -1;
> > >You have to free intr_handle->intr_vec, otherwise, memory leak occurs.
> >
> > It's freed at dev_close(). Do you mean freeing and reallocating here? As
>
> The typical way is free the resources have been allocated when errors
> happens.
>
> > nr_rx_queues is not a changeable value, I don't see the necessity here. I
> > miss something?
>
> No. nb_rx_queues does change, when people reconfigure the queue
> number.
> However, the MAX queues the virito supports does not change. You could
> use that number for allocation.
Oh yes. I will fix it.
Thanks,
Jianfeng
>
> --yliu
^ permalink raw reply
* [PATCH v5 8/8] doc: add MACsec offload into NIC feature list
From: Tiwei Bie @ 2017-01-04 7:21 UTC (permalink / raw)
To: dev
Cc: adrien.mazarguil, wenzhuo.lu, john.mcnamara, olivier.matz,
thomas.monjalon, konstantin.ananyev, helin.zhang, wei.dai,
xiao.w.wang
In-Reply-To: <1483514502-32841-1-git-send-email-tiwei.bie@intel.com>
Add MACsec offload into NIC feature list. And also update the
feature list for the supported drivers.
Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
---
doc/guides/nics/features/default.ini | 1 +
doc/guides/nics/features/ixgbe.ini | 1 +
2 files changed, 2 insertions(+)
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index f1bf9bf..c412d6f 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -43,6 +43,7 @@ VLAN offload =
QinQ offload =
L3 checksum offload =
L4 checksum offload =
+MACsec offload =
Inner L3 checksum =
Inner L4 checksum =
Packet type parsing =
diff --git a/doc/guides/nics/features/ixgbe.ini b/doc/guides/nics/features/ixgbe.ini
index 4a5667f..24c02fb 100644
--- a/doc/guides/nics/features/ixgbe.ini
+++ b/doc/guides/nics/features/ixgbe.ini
@@ -36,6 +36,7 @@ VLAN offload = Y
QinQ offload = Y
L3 checksum offload = Y
L4 checksum offload = Y
+MACsec offload = Y
Inner L3 checksum = Y
Inner L4 checksum = Y
Packet type parsing = Y
--
2.7.4
^ permalink raw reply related
* [PATCH v5 7/8] doc: update the release notes for the reserved flags
From: Tiwei Bie @ 2017-01-04 7:21 UTC (permalink / raw)
To: dev
Cc: adrien.mazarguil, wenzhuo.lu, john.mcnamara, olivier.matz,
thomas.monjalon, konstantin.ananyev, helin.zhang, wei.dai,
xiao.w.wang
In-Reply-To: <1483514502-32841-1-git-send-email-tiwei.bie@intel.com>
Add information about the flags reserved for PMD-specific API in
the release notes.
Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
---
doc/guides/rel_notes/release_17_02.rst | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/doc/guides/rel_notes/release_17_02.rst b/doc/guides/rel_notes/release_17_02.rst
index 34dba45..af71f39 100644
--- a/doc/guides/rel_notes/release_17_02.rst
+++ b/doc/guides/rel_notes/release_17_02.rst
@@ -58,6 +58,18 @@ New Features
MACsec offload support. The declarations of the APIs and the definitions
of the flags can be found in ``rte_pmd_ixgbe.h``.
+* **Reserved flags for PMD to implement the PMD-specific API.**
+
+ Following flags in mbuf and ethdev are reserved for PMD to define its
+ own flags when implementing the PMD-specific API.
+
+ * DEV_RX_OFFLOAD_RESERVED_0
+ * DEV_TX_OFFLOAD_RESERVED_0
+ * RTE_ETH_EVENT_RESERVED_0
+ * PKT_TX_RESERVED_0
+
+ You can refer to ``rte_pmd_ixgbe.h`` for an example.
+
Resolved Issues
---------------
--
2.7.4
^ permalink raw reply related
* [PATCH v5 6/8] doc: add ixgbe specific APIs
From: Tiwei Bie @ 2017-01-04 7:21 UTC (permalink / raw)
To: dev
Cc: adrien.mazarguil, wenzhuo.lu, john.mcnamara, olivier.matz,
thomas.monjalon, konstantin.ananyev, helin.zhang, wei.dai,
xiao.w.wang
In-Reply-To: <1483514502-32841-1-git-send-email-tiwei.bie@intel.com>
Add information about the new ixgbe PMD APIs in the release notes.
Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
---
doc/guides/rel_notes/release_17_02.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/doc/guides/rel_notes/release_17_02.rst b/doc/guides/rel_notes/release_17_02.rst
index 180af82..34dba45 100644
--- a/doc/guides/rel_notes/release_17_02.rst
+++ b/doc/guides/rel_notes/release_17_02.rst
@@ -52,6 +52,12 @@ New Features
See the :ref:`Generic flow API <Generic_flow_API>` documentation for more
information.
+* **Added APIs for MACsec offload support to the ixgbe PMD.**
+
+ Six new APIs and some related flags have been added to the ixgbe PMD for
+ MACsec offload support. The declarations of the APIs and the definitions
+ of the flags can be found in ``rte_pmd_ixgbe.h``.
+
Resolved Issues
---------------
--
2.7.4
^ permalink raw reply related
* [PATCH v5 5/8] app/testpmd: add MACsec offload commands
From: Tiwei Bie @ 2017-01-04 7:21 UTC (permalink / raw)
To: dev
Cc: adrien.mazarguil, wenzhuo.lu, john.mcnamara, olivier.matz,
thomas.monjalon, konstantin.ananyev, helin.zhang, wei.dai,
xiao.w.wang
In-Reply-To: <1483514502-32841-1-git-send-email-tiwei.bie@intel.com>
Below MACsec offload commands are added:
- set macsec offload <port_id> on encrypt on|off replay-protect on|off
- set macsec offload <port_id> off
- set macsec sc tx|rx <port_id> <mac> <pi>
- set macsec sa tx|rx <port_id> <idx> <an> <pn> <key>
Also update the testpmd user guide.
Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
---
app/test-pmd/cmdline.c | 389 ++++++++++++++++++++++++++++
app/test-pmd/macfwd.c | 7 +
app/test-pmd/macswap.c | 7 +
app/test-pmd/testpmd.h | 2 +
app/test-pmd/txonly.c | 7 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 32 +++
6 files changed, 444 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index f768b6b..4a67894 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -275,6 +275,18 @@ static void cmd_help_long_parsed(void *parsed_result,
"set vf mac antispoof (port_id) (vf_id) (on|off).\n"
" Set MAC antispoof for a VF from the PF.\n\n"
+
+ "set macsec offload (port_id) on encrypt (on|off) replay-protect (on|off)\n"
+ " Enable MACsec offload.\n\n"
+
+ "set macsec offload (port_id) off\n"
+ " Disable MACsec offload.\n\n"
+
+ "set macsec sc (tx|rx) (port_id) (mac) (pi)\n"
+ " Configure MACsec secure connection (SC).\n\n"
+
+ "set macsec sa (tx|rx) (port_id) (idx) (an) (pn) (key)\n"
+ " Configure MACsec secure association (SA).\n\n"
#endif
"vlan set strip (on|off) (port_id)\n"
@@ -11488,6 +11500,379 @@ cmdline_parse_inst_t cmd_set_vf_mac_addr = {
NULL,
},
};
+
+/* MACsec configuration */
+
+/* Common result structure for MACsec offload enable */
+struct cmd_macsec_offload_on_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t macsec;
+ cmdline_fixed_string_t offload;
+ uint8_t port_id;
+ cmdline_fixed_string_t on;
+ cmdline_fixed_string_t encrypt;
+ cmdline_fixed_string_t en_on_off;
+ cmdline_fixed_string_t replay_protect;
+ cmdline_fixed_string_t rp_on_off;
+};
+
+/* Common CLI fields for MACsec offload disable */
+cmdline_parse_token_string_t cmd_macsec_offload_on_set =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_offload_on_result,
+ set, "set");
+cmdline_parse_token_string_t cmd_macsec_offload_on_macsec =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_offload_on_result,
+ macsec, "macsec");
+cmdline_parse_token_string_t cmd_macsec_offload_on_offload =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_offload_on_result,
+ offload, "offload");
+cmdline_parse_token_string_t cmd_macsec_offload_on_port_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_macsec_offload_on_result,
+ port_id, UINT8);
+cmdline_parse_token_string_t cmd_macsec_offload_on_on =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_offload_on_result,
+ on, "on");
+cmdline_parse_token_string_t cmd_macsec_offload_on_encrypt =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_offload_on_result,
+ encrypt, "encrypt");
+cmdline_parse_token_string_t cmd_macsec_offload_on_en_on_off =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_offload_on_result,
+ en_on_off, "on#off");
+cmdline_parse_token_string_t cmd_macsec_offload_on_replay_protect =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_offload_on_result,
+ replay_protect, "replay-protect");
+cmdline_parse_token_string_t cmd_macsec_offload_on_rp_on_off =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_offload_on_result,
+ rp_on_off, "on#off");
+
+static void
+cmd_set_macsec_offload_on_parsed(
+ void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_macsec_offload_on_result *res = parsed_result;
+ int ret;
+ portid_t port_id = res->port_id;
+ int en = (strcmp(res->en_on_off, "on") == 0) ? 1 : 0;
+ int rp = (strcmp(res->rp_on_off, "on") == 0) ? 1 : 0;
+
+ if (port_id_is_invalid(port_id, ENABLED_WARN))
+ return;
+
+ ports[port_id].tx_ol_flags |= TESTPMD_TX_OFFLOAD_MACSEC;
+ ret = rte_pmd_ixgbe_macsec_enable(port_id, en, rp);
+
+ switch (ret) {
+ case 0:
+ break;
+ case -ENODEV:
+ printf("invalid port_id %d\n", port_id);
+ break;
+ default:
+ printf("programming error: (%s)\n", strerror(-ret));
+ }
+}
+
+cmdline_parse_inst_t cmd_set_macsec_offload_on = {
+ .f = cmd_set_macsec_offload_on_parsed,
+ .data = NULL,
+ .help_str = "set macsec offload <port_id> on "
+ "encrypt on|off replay-protect on|off",
+ .tokens = {
+ (void *)&cmd_macsec_offload_on_set,
+ (void *)&cmd_macsec_offload_on_macsec,
+ (void *)&cmd_macsec_offload_on_offload,
+ (void *)&cmd_macsec_offload_on_port_id,
+ (void *)&cmd_macsec_offload_on_on,
+ (void *)&cmd_macsec_offload_on_encrypt,
+ (void *)&cmd_macsec_offload_on_en_on_off,
+ (void *)&cmd_macsec_offload_on_replay_protect,
+ (void *)&cmd_macsec_offload_on_rp_on_off,
+ NULL,
+ },
+};
+
+/* Common result structure for MACsec offload disable */
+struct cmd_macsec_offload_off_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t macsec;
+ cmdline_fixed_string_t offload;
+ uint8_t port_id;
+ cmdline_fixed_string_t off;
+};
+
+/* Common CLI fields for MACsec offload disable */
+cmdline_parse_token_string_t cmd_macsec_offload_off_set =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_offload_off_result,
+ set, "set");
+cmdline_parse_token_string_t cmd_macsec_offload_off_macsec =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_offload_off_result,
+ macsec, "macsec");
+cmdline_parse_token_string_t cmd_macsec_offload_off_offload =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_offload_off_result,
+ offload, "offload");
+cmdline_parse_token_string_t cmd_macsec_offload_off_port_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_macsec_offload_off_result,
+ port_id, UINT8);
+cmdline_parse_token_string_t cmd_macsec_offload_off_off =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_offload_off_result,
+ off, "off");
+
+static void
+cmd_set_macsec_offload_off_parsed(
+ void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_macsec_offload_off_result *res = parsed_result;
+ int ret;
+ portid_t port_id = res->port_id;
+
+ if (port_id_is_invalid(port_id, ENABLED_WARN))
+ return;
+
+ ports[port_id].tx_ol_flags &= ~TESTPMD_TX_OFFLOAD_MACSEC;
+ ret = rte_pmd_ixgbe_macsec_disable(port_id);
+
+ switch (ret) {
+ case 0:
+ break;
+ case -ENODEV:
+ printf("invalid port_id %d\n", port_id);
+ break;
+ default:
+ printf("programming error: (%s)\n", strerror(-ret));
+ }
+}
+
+cmdline_parse_inst_t cmd_set_macsec_offload_off = {
+ .f = cmd_set_macsec_offload_off_parsed,
+ .data = NULL,
+ .help_str = "set macsec offload <port_id> off",
+ .tokens = {
+ (void *)&cmd_macsec_offload_off_set,
+ (void *)&cmd_macsec_offload_off_macsec,
+ (void *)&cmd_macsec_offload_off_offload,
+ (void *)&cmd_macsec_offload_off_port_id,
+ (void *)&cmd_macsec_offload_off_off,
+ NULL,
+ },
+};
+
+/* Common result structure for MACsec secure connection configure */
+struct cmd_macsec_sc_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t macsec;
+ cmdline_fixed_string_t sc;
+ cmdline_fixed_string_t tx_rx;
+ uint8_t port_id;
+ struct ether_addr mac;
+ uint16_t pi;
+};
+
+/* Common CLI fields for MACsec secure connection configure */
+cmdline_parse_token_string_t cmd_macsec_sc_set =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_sc_result,
+ set, "set");
+cmdline_parse_token_string_t cmd_macsec_sc_macsec =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_sc_result,
+ macsec, "macsec");
+cmdline_parse_token_string_t cmd_macsec_sc_sc =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_sc_result,
+ sc, "sc");
+cmdline_parse_token_string_t cmd_macsec_sc_tx_rx =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_sc_result,
+ tx_rx, "tx#rx");
+cmdline_parse_token_num_t cmd_macsec_sc_port_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_macsec_sc_result,
+ port_id, UINT8);
+cmdline_parse_token_etheraddr_t cmd_macsec_sc_mac =
+ TOKEN_ETHERADDR_INITIALIZER
+ (struct cmd_macsec_sc_result,
+ mac);
+cmdline_parse_token_num_t cmd_macsec_sc_pi =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_macsec_sc_result,
+ pi, UINT16);
+
+static void
+cmd_set_macsec_sc_parsed(
+ void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_macsec_sc_result *res = parsed_result;
+ int ret;
+ int is_tx = (strcmp(res->tx_rx, "tx") == 0) ? 1 : 0;
+
+ ret = is_tx ?
+ rte_pmd_ixgbe_macsec_config_txsc(res->port_id,
+ res->mac.addr_bytes) :
+ rte_pmd_ixgbe_macsec_config_rxsc(res->port_id,
+ res->mac.addr_bytes, res->pi);
+ switch (ret) {
+ case 0:
+ break;
+ case -ENODEV:
+ printf("invalid port_id %d\n", res->port_id);
+ break;
+ default:
+ printf("programming error: (%s)\n", strerror(-ret));
+ }
+}
+
+cmdline_parse_inst_t cmd_set_macsec_sc = {
+ .f = cmd_set_macsec_sc_parsed,
+ .data = NULL,
+ .help_str = "set macsec sc tx|rx <port_id> <mac> <pi>",
+ .tokens = {
+ (void *)&cmd_macsec_sc_set,
+ (void *)&cmd_macsec_sc_macsec,
+ (void *)&cmd_macsec_sc_sc,
+ (void *)&cmd_macsec_sc_tx_rx,
+ (void *)&cmd_macsec_sc_port_id,
+ (void *)&cmd_macsec_sc_mac,
+ (void *)&cmd_macsec_sc_pi,
+ NULL,
+ },
+};
+
+/* Common result structure for MACsec secure connection configure */
+struct cmd_macsec_sa_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t macsec;
+ cmdline_fixed_string_t sa;
+ cmdline_fixed_string_t tx_rx;
+ uint8_t port_id;
+ uint8_t idx;
+ uint8_t an;
+ uint32_t pn;
+ cmdline_fixed_string_t key;
+};
+
+/* Common CLI fields for MACsec secure connection configure */
+cmdline_parse_token_string_t cmd_macsec_sa_set =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_sa_result,
+ set, "set");
+cmdline_parse_token_string_t cmd_macsec_sa_macsec =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_sa_result,
+ macsec, "macsec");
+cmdline_parse_token_string_t cmd_macsec_sa_sa =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_sa_result,
+ sa, "sa");
+cmdline_parse_token_string_t cmd_macsec_sa_tx_rx =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_sa_result,
+ tx_rx, "tx#rx");
+cmdline_parse_token_num_t cmd_macsec_sa_port_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_macsec_sa_result,
+ port_id, UINT8);
+cmdline_parse_token_num_t cmd_macsec_sa_idx =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_macsec_sa_result,
+ idx, UINT8);
+cmdline_parse_token_num_t cmd_macsec_sa_an =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_macsec_sa_result,
+ an, UINT8);
+cmdline_parse_token_num_t cmd_macsec_sa_pn =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_macsec_sa_result,
+ pn, UINT32);
+cmdline_parse_token_string_t cmd_macsec_sa_key =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_macsec_sa_result,
+ key, NULL);
+
+static void
+cmd_set_macsec_sa_parsed(
+ void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_macsec_sa_result *res = parsed_result;
+ int ret;
+ int is_tx = (strcmp(res->tx_rx, "tx") == 0) ? 1 : 0;
+ uint8_t key[16] = { 0 };
+ uint8_t xdgt0;
+ uint8_t xdgt1;
+ int key_len;
+ int i;
+
+ key_len = strlen(res->key) / 2;
+ if (key_len > 16)
+ key_len = 16;
+
+ for (i = 0; i < key_len; i++) {
+ xdgt0 = parse_and_check_key_hexa_digit(res->key, (i * 2));
+ if (xdgt0 == 0xFF)
+ return;
+ xdgt1 = parse_and_check_key_hexa_digit(res->key, (i * 2) + 1);
+ if (xdgt1 == 0xFF)
+ return;
+ key[i] = (uint8_t) ((xdgt0 * 16) + xdgt1);
+ }
+
+ ret = is_tx ?
+ rte_pmd_ixgbe_macsec_select_txsa(res->port_id,
+ res->idx, res->an, res->pn, key) :
+ rte_pmd_ixgbe_macsec_select_rxsa(res->port_id,
+ res->idx, res->an, res->pn, key);
+ switch (ret) {
+ case 0:
+ break;
+ case -EINVAL:
+ printf("invalid idx %d or an %d\n", res->idx, res->an);
+ break;
+ case -ENODEV:
+ printf("invalid port_id %d\n", res->port_id);
+ break;
+ default:
+ printf("programming error: (%s)\n", strerror(-ret));
+ }
+}
+
+cmdline_parse_inst_t cmd_set_macsec_sa = {
+ .f = cmd_set_macsec_sa_parsed,
+ .data = NULL,
+ .help_str = "set macsec sa tx|rx <port_id> <idx> <an> <pn> <key>",
+ .tokens = {
+ (void *)&cmd_macsec_sa_set,
+ (void *)&cmd_macsec_sa_macsec,
+ (void *)&cmd_macsec_sa_sa,
+ (void *)&cmd_macsec_sa_tx_rx,
+ (void *)&cmd_macsec_sa_port_id,
+ (void *)&cmd_macsec_sa_idx,
+ (void *)&cmd_macsec_sa_an,
+ (void *)&cmd_macsec_sa_pn,
+ (void *)&cmd_macsec_sa_key,
+ NULL,
+ },
+};
#endif
/* ******************************************************************************** */
@@ -11656,6 +12041,10 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_set_all_queues_drop_en,
(cmdline_parse_inst_t *)&cmd_set_vf_split_drop_en,
(cmdline_parse_inst_t *)&cmd_set_vf_mac_addr,
+ (cmdline_parse_inst_t *)&cmd_set_macsec_offload_on,
+ (cmdline_parse_inst_t *)&cmd_set_macsec_offload_off,
+ (cmdline_parse_inst_t *)&cmd_set_macsec_sc,
+ (cmdline_parse_inst_t *)&cmd_set_macsec_sa,
#endif
NULL,
};
diff --git a/app/test-pmd/macfwd.c b/app/test-pmd/macfwd.c
index d361db1..38e955f 100644
--- a/app/test-pmd/macfwd.c
+++ b/app/test-pmd/macfwd.c
@@ -66,6 +66,9 @@
#include <rte_ip.h>
#include <rte_string_fns.h>
#include <rte_flow.h>
+#ifdef RTE_LIBRTE_IXGBE_PMD
+#include <rte_pmd_ixgbe.h>
+#endif
#include "testpmd.h"
@@ -113,6 +116,10 @@ pkt_burst_mac_forward(struct fwd_stream *fs)
ol_flags = PKT_TX_VLAN_PKT;
if (txp->tx_ol_flags & TESTPMD_TX_OFFLOAD_INSERT_QINQ)
ol_flags |= PKT_TX_QINQ_PKT;
+#ifdef RTE_LIBRTE_IXGBE_PMD
+ if (txp->tx_ol_flags & TESTPMD_TX_OFFLOAD_MACSEC)
+ ol_flags |= PKT_TX_IXGBE_MACSEC;
+#endif
for (i = 0; i < nb_rx; i++) {
if (likely(i < nb_rx - 1))
rte_prefetch0(rte_pktmbuf_mtod(pkts_burst[i + 1],
diff --git a/app/test-pmd/macswap.c b/app/test-pmd/macswap.c
index f996039..7f5dcd7 100644
--- a/app/test-pmd/macswap.c
+++ b/app/test-pmd/macswap.c
@@ -66,6 +66,9 @@
#include <rte_ip.h>
#include <rte_string_fns.h>
#include <rte_flow.h>
+#ifdef RTE_LIBRTE_IXGBE_PMD
+#include <rte_pmd_ixgbe.h>
+#endif
#include "testpmd.h"
@@ -113,6 +116,10 @@ pkt_burst_mac_swap(struct fwd_stream *fs)
ol_flags = PKT_TX_VLAN_PKT;
if (txp->tx_ol_flags & TESTPMD_TX_OFFLOAD_INSERT_QINQ)
ol_flags |= PKT_TX_QINQ_PKT;
+#ifdef RTE_LIBRTE_IXGBE_PMD
+ if (txp->tx_ol_flags & TESTPMD_TX_OFFLOAD_MACSEC)
+ ol_flags |= PKT_TX_IXGBE_MACSEC;
+#endif
for (i = 0; i < nb_rx; i++) {
if (likely(i < nb_rx - 1))
rte_prefetch0(rte_pktmbuf_mtod(pkts_burst[i + 1],
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 22ce2d6..0a9a1af 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -143,6 +143,8 @@ struct fwd_stream {
#define TESTPMD_TX_OFFLOAD_INSERT_VLAN 0x0040
/** Insert double VLAN header in forward engine */
#define TESTPMD_TX_OFFLOAD_INSERT_QINQ 0x0080
+/** Offload MACsec in forward engine */
+#define TESTPMD_TX_OFFLOAD_MACSEC 0x0100
/** Descriptor for a single flow. */
struct port_flow {
diff --git a/app/test-pmd/txonly.c b/app/test-pmd/txonly.c
index e996f35..3aea8b3 100644
--- a/app/test-pmd/txonly.c
+++ b/app/test-pmd/txonly.c
@@ -69,6 +69,9 @@
#include <rte_udp.h>
#include <rte_string_fns.h>
#include <rte_flow.h>
+#ifdef RTE_LIBRTE_IXGBE_PMD
+#include <rte_pmd_ixgbe.h>
+#endif
#include "testpmd.h"
@@ -215,6 +218,10 @@ pkt_burst_transmit(struct fwd_stream *fs)
ol_flags = PKT_TX_VLAN_PKT;
if (txp->tx_ol_flags & TESTPMD_TX_OFFLOAD_INSERT_QINQ)
ol_flags |= PKT_TX_QINQ_PKT;
+#ifdef RTE_LIBRTE_IXGBE_PMD
+ if (txp->tx_ol_flags & TESTPMD_TX_OFFLOAD_MACSEC)
+ ol_flags |= PKT_TX_IXGBE_MACSEC;
+#endif
for (nb_pkt = 0; nb_pkt < nb_pkt_per_burst; nb_pkt++) {
pkt = rte_mbuf_raw_alloc(mbp);
if (pkt == NULL) {
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index cacdef1..f4068d3 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -507,6 +507,38 @@ Set mac antispoof for a VF from the PF::
testpmd> set vf mac antispoof (port_id) (vf_id) (on|off)
+set macsec offload
+~~~~~~~~~~~~~~~~~~
+
+Enable/disable MACsec offload::
+
+ testpmd> set macsec offload (port_id) on encrypt (on|off) replay-protect (on|off)
+ testpmd> set macsec offload (port_id) off
+
+set macsec sc
+~~~~~~~~~~~~~
+
+Configure MACsec secure connection (SC)::
+
+ testpmd> set macsec sc (tx|rx) (port_id) (mac) (pi)
+
+.. note::
+
+ The pi argument is ignored for tx.
+ Check the NIC Datasheet for hardware limits.
+
+set macsec sa
+~~~~~~~~~~~~~
+
+Configure MACsec secure association (SA)::
+
+ testpmd> set macsec sa (tx|rx) (port_id) (idx) (an) (pn) (key)
+
+.. note::
+
+ The IDX value must be 0 or 1.
+ Check the NIC Datasheet for hardware limits.
+
vlan set strip
~~~~~~~~~~~~~~
--
2.7.4
^ permalink raw reply related
* [PATCH v5 4/8] net/ixgbe: add MACsec offload support
From: Tiwei Bie @ 2017-01-04 7:21 UTC (permalink / raw)
To: dev
Cc: adrien.mazarguil, wenzhuo.lu, john.mcnamara, olivier.matz,
thomas.monjalon, konstantin.ananyev, helin.zhang, wei.dai,
xiao.w.wang
In-Reply-To: <1483514502-32841-1-git-send-email-tiwei.bie@intel.com>
MACsec (or LinkSec, 802.1AE) is a MAC level encryption/authentication
scheme defined in IEEE 802.1AE that uses symmetric cryptography.
This commit adds the MACsec offload support for ixgbe.
Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
---
drivers/net/ixgbe/ixgbe_ethdev.c | 481 +++++++++++++++++++++++++++-
drivers/net/ixgbe/ixgbe_ethdev.h | 45 +++
drivers/net/ixgbe/ixgbe_rxtx.c | 5 +
drivers/net/ixgbe/rte_pmd_ixgbe.h | 122 +++++++
drivers/net/ixgbe/rte_pmd_ixgbe_version.map | 11 +
5 files changed, 659 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index ec2edad..653ddd2 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -231,6 +231,7 @@ static int ixgbe_dev_rss_reta_query(struct rte_eth_dev *dev,
uint16_t reta_size);
static void ixgbe_dev_link_status_print(struct rte_eth_dev *dev);
static int ixgbe_dev_lsc_interrupt_setup(struct rte_eth_dev *dev);
+static int ixgbe_dev_macsec_interrupt_setup(struct rte_eth_dev *dev);
static int ixgbe_dev_rxq_interrupt_setup(struct rte_eth_dev *dev);
static int ixgbe_dev_interrupt_get_status(struct rte_eth_dev *dev);
static int ixgbe_dev_interrupt_action(struct rte_eth_dev *dev,
@@ -745,6 +746,51 @@ static const struct rte_ixgbe_xstats_name_off rte_ixgbe_stats_strings[] = {
#define IXGBE_NB_HW_STATS (sizeof(rte_ixgbe_stats_strings) / \
sizeof(rte_ixgbe_stats_strings[0]))
+/* MACsec statistics */
+static const struct rte_ixgbe_xstats_name_off rte_ixgbe_macsec_strings[] = {
+ {"out_pkts_untagged", offsetof(struct ixgbe_macsec_stats,
+ out_pkts_untagged)},
+ {"out_pkts_encrypted", offsetof(struct ixgbe_macsec_stats,
+ out_pkts_encrypted)},
+ {"out_pkts_protected", offsetof(struct ixgbe_macsec_stats,
+ out_pkts_protected)},
+ {"out_octets_encrypted", offsetof(struct ixgbe_macsec_stats,
+ out_octets_encrypted)},
+ {"out_octets_protected", offsetof(struct ixgbe_macsec_stats,
+ out_octets_protected)},
+ {"in_pkts_untagged", offsetof(struct ixgbe_macsec_stats,
+ in_pkts_untagged)},
+ {"in_pkts_badtag", offsetof(struct ixgbe_macsec_stats,
+ in_pkts_badtag)},
+ {"in_pkts_nosci", offsetof(struct ixgbe_macsec_stats,
+ in_pkts_nosci)},
+ {"in_pkts_unknownsci", offsetof(struct ixgbe_macsec_stats,
+ in_pkts_unknownsci)},
+ {"in_octets_decrypted", offsetof(struct ixgbe_macsec_stats,
+ in_octets_decrypted)},
+ {"in_octets_validated", offsetof(struct ixgbe_macsec_stats,
+ in_octets_validated)},
+ {"in_pkts_unchecked", offsetof(struct ixgbe_macsec_stats,
+ in_pkts_unchecked)},
+ {"in_pkts_delayed", offsetof(struct ixgbe_macsec_stats,
+ in_pkts_delayed)},
+ {"in_pkts_late", offsetof(struct ixgbe_macsec_stats,
+ in_pkts_late)},
+ {"in_pkts_ok", offsetof(struct ixgbe_macsec_stats,
+ in_pkts_ok)},
+ {"in_pkts_invalid", offsetof(struct ixgbe_macsec_stats,
+ in_pkts_invalid)},
+ {"in_pkts_notvalid", offsetof(struct ixgbe_macsec_stats,
+ in_pkts_notvalid)},
+ {"in_pkts_unusedsa", offsetof(struct ixgbe_macsec_stats,
+ in_pkts_unusedsa)},
+ {"in_pkts_notusingsa", offsetof(struct ixgbe_macsec_stats,
+ in_pkts_notusingsa)},
+};
+
+#define IXGBE_NB_MACSEC_STATS (sizeof(rte_ixgbe_macsec_strings) / \
+ sizeof(rte_ixgbe_macsec_strings[0]))
+
/* Per-queue statistics */
static const struct rte_ixgbe_xstats_name_off rte_ixgbe_rxq_strings[] = {
{"mbuf_allocation_errors", offsetof(struct ixgbe_hw_stats, rnbc)},
@@ -2367,6 +2413,7 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
/* check if lsc interrupt is enabled */
if (dev->data->dev_conf.intr_conf.lsc != 0)
ixgbe_dev_lsc_interrupt_setup(dev);
+ ixgbe_dev_macsec_interrupt_setup(dev);
} else {
rte_intr_callback_unregister(intr_handle,
ixgbe_dev_interrupt_handler, dev);
@@ -2557,6 +2604,7 @@ ixgbe_dev_close(struct rte_eth_dev *dev)
static void
ixgbe_read_stats_registers(struct ixgbe_hw *hw,
struct ixgbe_hw_stats *hw_stats,
+ struct ixgbe_macsec_stats *macsec_stats,
uint64_t *total_missed_rx, uint64_t *total_qbrc,
uint64_t *total_qprc, uint64_t *total_qprdc)
{
@@ -2726,6 +2774,40 @@ ixgbe_read_stats_registers(struct ixgbe_hw *hw,
/* Flow Director Stats registers */
hw_stats->fdirmatch += IXGBE_READ_REG(hw, IXGBE_FDIRMATCH);
hw_stats->fdirmiss += IXGBE_READ_REG(hw, IXGBE_FDIRMISS);
+
+ /* MACsec Stats registers */
+ macsec_stats->out_pkts_untagged += IXGBE_READ_REG(hw, IXGBE_LSECTXUT);
+ macsec_stats->out_pkts_encrypted +=
+ IXGBE_READ_REG(hw, IXGBE_LSECTXPKTE);
+ macsec_stats->out_pkts_protected +=
+ IXGBE_READ_REG(hw, IXGBE_LSECTXPKTP);
+ macsec_stats->out_octets_encrypted +=
+ IXGBE_READ_REG(hw, IXGBE_LSECTXOCTE);
+ macsec_stats->out_octets_protected +=
+ IXGBE_READ_REG(hw, IXGBE_LSECTXOCTP);
+ macsec_stats->in_pkts_untagged += IXGBE_READ_REG(hw, IXGBE_LSECRXUT);
+ macsec_stats->in_pkts_badtag += IXGBE_READ_REG(hw, IXGBE_LSECRXBAD);
+ macsec_stats->in_pkts_nosci += IXGBE_READ_REG(hw, IXGBE_LSECRXNOSCI);
+ macsec_stats->in_pkts_unknownsci +=
+ IXGBE_READ_REG(hw, IXGBE_LSECRXUNSCI);
+ macsec_stats->in_octets_decrypted +=
+ IXGBE_READ_REG(hw, IXGBE_LSECRXOCTD);
+ macsec_stats->in_octets_validated +=
+ IXGBE_READ_REG(hw, IXGBE_LSECRXOCTV);
+ macsec_stats->in_pkts_unchecked += IXGBE_READ_REG(hw, IXGBE_LSECRXUNCH);
+ macsec_stats->in_pkts_delayed += IXGBE_READ_REG(hw, IXGBE_LSECRXDELAY);
+ macsec_stats->in_pkts_late += IXGBE_READ_REG(hw, IXGBE_LSECRXLATE);
+ for (i = 0; i < 2; i++) {
+ macsec_stats->in_pkts_ok +=
+ IXGBE_READ_REG(hw, IXGBE_LSECRXOK(i));
+ macsec_stats->in_pkts_invalid +=
+ IXGBE_READ_REG(hw, IXGBE_LSECRXINV(i));
+ macsec_stats->in_pkts_notvalid +=
+ IXGBE_READ_REG(hw, IXGBE_LSECRXNV(i));
+ }
+ macsec_stats->in_pkts_unusedsa += IXGBE_READ_REG(hw, IXGBE_LSECRXUNSA);
+ macsec_stats->in_pkts_notusingsa +=
+ IXGBE_READ_REG(hw, IXGBE_LSECRXNUSA);
}
/*
@@ -2738,6 +2820,9 @@ ixgbe_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct ixgbe_hw_stats *hw_stats =
IXGBE_DEV_PRIVATE_TO_STATS(dev->data->dev_private);
+ struct ixgbe_macsec_stats *macsec_stats =
+ IXGBE_DEV_PRIVATE_TO_MACSEC_STATS(
+ dev->data->dev_private);
uint64_t total_missed_rx, total_qbrc, total_qprc, total_qprdc;
unsigned i;
@@ -2746,8 +2831,8 @@ ixgbe_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
total_qprc = 0;
total_qprdc = 0;
- ixgbe_read_stats_registers(hw, hw_stats, &total_missed_rx, &total_qbrc,
- &total_qprc, &total_qprdc);
+ ixgbe_read_stats_registers(hw, hw_stats, macsec_stats, &total_missed_rx,
+ &total_qbrc, &total_qprc, &total_qprdc);
if (stats == NULL)
return;
@@ -2799,7 +2884,7 @@ ixgbe_dev_stats_reset(struct rte_eth_dev *dev)
/* This function calculates the number of xstats based on the current config */
static unsigned
ixgbe_xstats_calc_num(void) {
- return IXGBE_NB_HW_STATS +
+ return IXGBE_NB_HW_STATS + IXGBE_NB_MACSEC_STATS +
(IXGBE_NB_RXQ_PRIO_STATS * IXGBE_NB_RXQ_PRIO_VALUES) +
(IXGBE_NB_TXQ_PRIO_STATS * IXGBE_NB_TXQ_PRIO_VALUES);
}
@@ -2826,6 +2911,15 @@ static int ixgbe_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
count++;
}
+ /* MACsec Stats */
+ for (i = 0; i < IXGBE_NB_MACSEC_STATS; i++) {
+ snprintf(xstats_names[count].name,
+ sizeof(xstats_names[count].name),
+ "%s",
+ rte_ixgbe_macsec_strings[i].name);
+ count++;
+ }
+
/* RX Priority Stats */
for (stat = 0; stat < IXGBE_NB_RXQ_PRIO_STATS; stat++) {
for (i = 0; i < IXGBE_NB_RXQ_PRIO_VALUES; i++) {
@@ -2875,6 +2969,9 @@ ixgbe_dev_xstats_get(struct rte_eth_dev *dev, struct rte_eth_xstat *xstats,
IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct ixgbe_hw_stats *hw_stats =
IXGBE_DEV_PRIVATE_TO_STATS(dev->data->dev_private);
+ struct ixgbe_macsec_stats *macsec_stats =
+ IXGBE_DEV_PRIVATE_TO_MACSEC_STATS(
+ dev->data->dev_private);
uint64_t total_missed_rx, total_qbrc, total_qprc, total_qprdc;
unsigned i, stat, count = 0;
@@ -2888,8 +2985,8 @@ ixgbe_dev_xstats_get(struct rte_eth_dev *dev, struct rte_eth_xstat *xstats,
total_qprc = 0;
total_qprdc = 0;
- ixgbe_read_stats_registers(hw, hw_stats, &total_missed_rx, &total_qbrc,
- &total_qprc, &total_qprdc);
+ ixgbe_read_stats_registers(hw, hw_stats, macsec_stats, &total_missed_rx,
+ &total_qbrc, &total_qprc, &total_qprdc);
/* If this is a reset xstats is NULL, and we have cleared the
* registers by reading them.
@@ -2905,6 +3002,13 @@ ixgbe_dev_xstats_get(struct rte_eth_dev *dev, struct rte_eth_xstat *xstats,
count++;
}
+ /* MACsec Stats */
+ for (i = 0; i < IXGBE_NB_MACSEC_STATS; i++) {
+ xstats[count].value = *(uint64_t *)(((char *)macsec_stats) +
+ rte_ixgbe_macsec_strings[i].offset);
+ count++;
+ }
+
/* RX Priority Stats */
for (stat = 0; stat < IXGBE_NB_RXQ_PRIO_STATS; stat++) {
for (i = 0; i < IXGBE_NB_RXQ_PRIO_VALUES; i++) {
@@ -2932,6 +3036,9 @@ ixgbe_dev_xstats_reset(struct rte_eth_dev *dev)
{
struct ixgbe_hw_stats *stats =
IXGBE_DEV_PRIVATE_TO_STATS(dev->data->dev_private);
+ struct ixgbe_macsec_stats *macsec_stats =
+ IXGBE_DEV_PRIVATE_TO_MACSEC_STATS(
+ dev->data->dev_private);
unsigned count = ixgbe_xstats_calc_num();
@@ -2940,6 +3047,7 @@ ixgbe_dev_xstats_reset(struct rte_eth_dev *dev)
/* Reset software totals */
memset(stats, 0, sizeof(*stats));
+ memset(macsec_stats, 0, sizeof(*macsec_stats));
}
static void
@@ -3072,6 +3180,10 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
!RTE_ETH_DEV_SRIOV(dev).active)
dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_TCP_LRO;
+ if (hw->mac.type == ixgbe_mac_82599EB ||
+ hw->mac.type == ixgbe_mac_X540)
+ dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_IXGBE_MACSEC_STRIP;
+
if (hw->mac.type == ixgbe_mac_X550 ||
hw->mac.type == ixgbe_mac_X550EM_x ||
hw->mac.type == ixgbe_mac_X550EM_a)
@@ -3085,6 +3197,10 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
DEV_TX_OFFLOAD_SCTP_CKSUM |
DEV_TX_OFFLOAD_TCP_TSO;
+ if (hw->mac.type == ixgbe_mac_82599EB ||
+ hw->mac.type == ixgbe_mac_X540)
+ dev_info->tx_offload_capa |= DEV_TX_OFFLOAD_IXGBE_MACSEC_INSERT;
+
if (hw->mac.type == ixgbe_mac_X550 ||
hw->mac.type == ixgbe_mac_X550EM_x ||
hw->mac.type == ixgbe_mac_X550EM_a)
@@ -3382,6 +3498,28 @@ ixgbe_dev_rxq_interrupt_setup(struct rte_eth_dev *dev)
return 0;
}
+/**
+ * It clears the interrupt causes and enables the interrupt.
+ * It will be called once only during nic initialized.
+ *
+ * @param dev
+ * Pointer to struct rte_eth_dev.
+ *
+ * @return
+ * - On success, zero.
+ * - On failure, a negative value.
+ */
+static int
+ixgbe_dev_macsec_interrupt_setup(struct rte_eth_dev *dev)
+{
+ struct ixgbe_interrupt *intr =
+ IXGBE_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
+
+ intr->mask |= IXGBE_EICR_LINKSEC;
+
+ return 0;
+}
+
/*
* It reads ICR and sets flag (IXGBE_EICR_LSC) for the link_update.
*
@@ -3416,6 +3554,9 @@ ixgbe_dev_interrupt_get_status(struct rte_eth_dev *dev)
if (eicr & IXGBE_EICR_MAILBOX)
intr->flags |= IXGBE_FLAG_MAILBOX;
+ if (eicr & IXGBE_EICR_LINKSEC)
+ intr->flags |= IXGBE_FLAG_MACSEC;
+
if (hw->mac.type == ixgbe_mac_X550EM_x &&
hw->phy.type == ixgbe_phy_x550em_ext_t &&
(eicr & IXGBE_EICR_GPI_SDP0_X550EM_x))
@@ -3570,6 +3711,12 @@ ixgbe_dev_interrupt_delayed_handler(void *param)
_rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_INTR_LSC, NULL);
}
+ if (intr->flags & IXGBE_FLAG_MACSEC) {
+ _rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_IXGBE_MACSEC,
+ NULL);
+ intr->flags &= ~IXGBE_FLAG_MACSEC;
+ }
+
PMD_DRV_LOG(DEBUG, "enable intr in delayed handler S[%08x]", eicr);
ixgbe_enable_intr(dev);
rte_intr_enable(intr_handle);
@@ -7610,6 +7757,330 @@ ixgbevf_dev_interrupt_handler(__rte_unused struct rte_intr_handle *handle,
ixgbevf_dev_interrupt_action(dev);
}
+/**
+ * ixgbe_disable_sec_tx_path_generic - Stops the transmit data path
+ * @hw: pointer to hardware structure
+ *
+ * Stops the transmit data path and waits for the HW to internally empty
+ * the Tx security block
+ **/
+int ixgbe_disable_sec_tx_path_generic(struct ixgbe_hw *hw)
+{
+#define IXGBE_MAX_SECTX_POLL 40
+
+ int i;
+ int sectxreg;
+
+ sectxreg = IXGBE_READ_REG(hw, IXGBE_SECTXCTRL);
+ sectxreg |= IXGBE_SECTXCTRL_TX_DIS;
+ IXGBE_WRITE_REG(hw, IXGBE_SECTXCTRL, sectxreg);
+ for (i = 0; i < IXGBE_MAX_SECTX_POLL; i++) {
+ sectxreg = IXGBE_READ_REG(hw, IXGBE_SECTXSTAT);
+ if (sectxreg & IXGBE_SECTXSTAT_SECTX_RDY)
+ break;
+ /* Use interrupt-safe sleep just in case */
+ usec_delay(1000);
+ }
+
+ /* For informational purposes only */
+ if (i >= IXGBE_MAX_SECTX_POLL)
+ PMD_DRV_LOG(DEBUG, "Tx unit being enabled before security "
+ "path fully disabled. Continuing with init.\n");
+
+ return IXGBE_SUCCESS;
+}
+
+/**
+ * ixgbe_enable_sec_tx_path_generic - Enables the transmit data path
+ * @hw: pointer to hardware structure
+ *
+ * Enables the transmit data path.
+ **/
+int ixgbe_enable_sec_tx_path_generic(struct ixgbe_hw *hw)
+{
+ uint32_t sectxreg;
+
+ sectxreg = IXGBE_READ_REG(hw, IXGBE_SECTXCTRL);
+ sectxreg &= ~IXGBE_SECTXCTRL_TX_DIS;
+ IXGBE_WRITE_REG(hw, IXGBE_SECTXCTRL, sectxreg);
+ IXGBE_WRITE_FLUSH(hw);
+
+ return IXGBE_SUCCESS;
+}
+
+int
+rte_pmd_ixgbe_macsec_enable(uint8_t port, uint8_t en, uint8_t rp)
+{
+ struct ixgbe_hw *hw;
+ struct rte_eth_dev *dev;
+ uint32_t ctrl;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ /* Stop the data paths */
+ if (ixgbe_disable_sec_rx_path(hw) != IXGBE_SUCCESS)
+ return -ENOTSUP;
+ /*
+ * Workaround:
+ * As no ixgbe_disable_sec_rx_path equivalent is
+ * implemented for tx in the base code, and we are
+ * not allowed to modify the base code in DPDK, so
+ * just call the hand-written one directly for now.
+ * The hardware support has been checked by
+ * ixgbe_disable_sec_rx_path().
+ */
+ ixgbe_disable_sec_tx_path_generic(hw);
+
+ /* Enable Ethernet CRC (required by MACsec offload) */
+ ctrl = IXGBE_READ_REG(hw, IXGBE_HLREG0);
+ ctrl |= IXGBE_HLREG0_TXCRCEN | IXGBE_HLREG0_RXCRCSTRP;
+ IXGBE_WRITE_REG(hw, IXGBE_HLREG0, ctrl);
+
+ /* Enable the TX and RX crypto engines */
+ ctrl = IXGBE_READ_REG(hw, IXGBE_SECTXCTRL);
+ ctrl &= ~IXGBE_SECTXCTRL_SECTX_DIS;
+ IXGBE_WRITE_REG(hw, IXGBE_SECTXCTRL, ctrl);
+
+ ctrl = IXGBE_READ_REG(hw, IXGBE_SECRXCTRL);
+ ctrl &= ~IXGBE_SECRXCTRL_SECRX_DIS;
+ IXGBE_WRITE_REG(hw, IXGBE_SECRXCTRL, ctrl);
+
+ ctrl = IXGBE_READ_REG(hw, IXGBE_SECTXMINIFG);
+ ctrl &= ~IXGBE_SECTX_MINSECIFG_MASK;
+ ctrl |= 0x3;
+ IXGBE_WRITE_REG(hw, IXGBE_SECTXMINIFG, ctrl);
+
+ /* Enable SA lookup */
+ ctrl = IXGBE_READ_REG(hw, IXGBE_LSECTXCTRL);
+ ctrl &= ~IXGBE_LSECTXCTRL_EN_MASK;
+ ctrl |= en ? IXGBE_LSECTXCTRL_AUTH_ENCRYPT :
+ IXGBE_LSECTXCTRL_AUTH;
+ ctrl |= IXGBE_LSECTXCTRL_AISCI;
+ ctrl &= ~IXGBE_LSECTXCTRL_PNTHRSH_MASK;
+ ctrl |= IXGBE_MACSEC_PNTHRSH & IXGBE_LSECTXCTRL_PNTHRSH_MASK;
+ IXGBE_WRITE_REG(hw, IXGBE_LSECTXCTRL, ctrl);
+
+ ctrl = IXGBE_READ_REG(hw, IXGBE_LSECRXCTRL);
+ ctrl &= ~IXGBE_LSECRXCTRL_EN_MASK;
+ ctrl |= IXGBE_LSECRXCTRL_STRICT << IXGBE_LSECRXCTRL_EN_SHIFT;
+ ctrl &= ~IXGBE_LSECRXCTRL_PLSH;
+ if (rp)
+ ctrl |= IXGBE_LSECRXCTRL_RP;
+ else
+ ctrl &= ~IXGBE_LSECRXCTRL_RP;
+ IXGBE_WRITE_REG(hw, IXGBE_LSECRXCTRL, ctrl);
+
+ /* Start the data paths */
+ ixgbe_enable_sec_rx_path(hw);
+ /*
+ * Workaround:
+ * As no ixgbe_enable_sec_rx_path equivalent is
+ * implemented for tx in the base code, and we are
+ * not allowed to modify the base code in DPDK, so
+ * just call the hand-written one directly for now.
+ */
+ ixgbe_enable_sec_tx_path_generic(hw);
+
+ return 0;
+}
+
+int
+rte_pmd_ixgbe_macsec_disable(uint8_t port)
+{
+ struct ixgbe_hw *hw;
+ struct rte_eth_dev *dev;
+ uint32_t ctrl;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ /* Stop the data paths */
+ if (ixgbe_disable_sec_rx_path(hw) != IXGBE_SUCCESS)
+ return -ENOTSUP;
+ /*
+ * Workaround:
+ * As no ixgbe_disable_sec_rx_path equivalent is
+ * implemented for tx in the base code, and we are
+ * not allowed to modify the base code in DPDK, so
+ * just call the hand-written one directly for now.
+ * The hardware support has been checked by
+ * ixgbe_disable_sec_rx_path().
+ */
+ ixgbe_disable_sec_tx_path_generic(hw);
+
+ /* Disable the TX and RX crypto engines */
+ ctrl = IXGBE_READ_REG(hw, IXGBE_SECTXCTRL);
+ ctrl |= IXGBE_SECTXCTRL_SECTX_DIS;
+ IXGBE_WRITE_REG(hw, IXGBE_SECTXCTRL, ctrl);
+
+ ctrl = IXGBE_READ_REG(hw, IXGBE_SECRXCTRL);
+ ctrl |= IXGBE_SECRXCTRL_SECRX_DIS;
+ IXGBE_WRITE_REG(hw, IXGBE_SECRXCTRL, ctrl);
+
+ /* Disable SA lookup */
+ ctrl = IXGBE_READ_REG(hw, IXGBE_LSECTXCTRL);
+ ctrl &= ~IXGBE_LSECTXCTRL_EN_MASK;
+ ctrl |= IXGBE_LSECTXCTRL_DISABLE;
+ IXGBE_WRITE_REG(hw, IXGBE_LSECTXCTRL, ctrl);
+
+ ctrl = IXGBE_READ_REG(hw, IXGBE_LSECRXCTRL);
+ ctrl &= ~IXGBE_LSECRXCTRL_EN_MASK;
+ ctrl |= IXGBE_LSECRXCTRL_DISABLE << IXGBE_LSECRXCTRL_EN_SHIFT;
+ IXGBE_WRITE_REG(hw, IXGBE_LSECRXCTRL, ctrl);
+
+ /* Start the data paths */
+ ixgbe_enable_sec_rx_path(hw);
+ /*
+ * Workaround:
+ * As no ixgbe_enable_sec_rx_path equivalent is
+ * implemented for tx in the base code, and we are
+ * not allowed to modify the base code in DPDK, so
+ * just call the hand-written one directly for now.
+ */
+ ixgbe_enable_sec_tx_path_generic(hw);
+
+ return 0;
+}
+
+int
+rte_pmd_ixgbe_macsec_config_txsc(uint8_t port, uint8_t *mac)
+{
+ struct ixgbe_hw *hw;
+ struct rte_eth_dev *dev;
+ uint32_t ctrl;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ ctrl = mac[0] | (mac[1] << 8) | (mac[2] << 16) | (mac[3] << 24);
+ IXGBE_WRITE_REG(hw, IXGBE_LSECTXSCL, ctrl);
+
+ ctrl = mac[4] | (mac[5] << 8);
+ IXGBE_WRITE_REG(hw, IXGBE_LSECTXSCH, ctrl);
+
+ return 0;
+}
+
+int
+rte_pmd_ixgbe_macsec_config_rxsc(uint8_t port, uint8_t *mac, uint16_t pi)
+{
+ struct ixgbe_hw *hw;
+ struct rte_eth_dev *dev;
+ uint32_t ctrl;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ ctrl = mac[0] | (mac[1] << 8) | (mac[2] << 16) | (mac[3] << 24);
+ IXGBE_WRITE_REG(hw, IXGBE_LSECRXSCL, ctrl);
+
+ pi = rte_cpu_to_be_16(pi);
+ ctrl = mac[4] | (mac[5] << 8) | (pi << 16);
+ IXGBE_WRITE_REG(hw, IXGBE_LSECRXSCH, ctrl);
+
+ return 0;
+}
+
+int
+rte_pmd_ixgbe_macsec_select_txsa(uint8_t port, uint8_t idx, uint8_t an,
+ uint32_t pn, uint8_t *key)
+{
+ struct ixgbe_hw *hw;
+ struct rte_eth_dev *dev;
+ uint32_t ctrl, i;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ if (idx != 0 && idx != 1)
+ return -EINVAL;
+
+ if (an >= 4)
+ return -EINVAL;
+
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ /* Set the PN and key */
+ pn = rte_cpu_to_be_32(pn);
+ if (idx == 0) {
+ IXGBE_WRITE_REG(hw, IXGBE_LSECTXPN0, pn);
+
+ for (i = 0; i < 4; i++) {
+ ctrl = (key[i * 4 + 0] << 0) |
+ (key[i * 4 + 1] << 8) |
+ (key[i * 4 + 2] << 16) |
+ (key[i * 4 + 3] << 24);
+ IXGBE_WRITE_REG(hw, IXGBE_LSECTXKEY0(i), ctrl);
+ }
+ } else {
+ IXGBE_WRITE_REG(hw, IXGBE_LSECTXPN1, pn);
+
+ for (i = 0; i < 4; i++) {
+ ctrl = (key[i * 4 + 0] << 0) |
+ (key[i * 4 + 1] << 8) |
+ (key[i * 4 + 2] << 16) |
+ (key[i * 4 + 3] << 24);
+ IXGBE_WRITE_REG(hw, IXGBE_LSECTXKEY1(i), ctrl);
+ }
+ }
+
+ /* Set AN and select the SA */
+ ctrl = (an << idx * 2) | (idx << 4);
+ IXGBE_WRITE_REG(hw, IXGBE_LSECTXSA, ctrl);
+
+ return 0;
+}
+
+int
+rte_pmd_ixgbe_macsec_select_rxsa(uint8_t port, uint8_t idx, uint8_t an,
+ uint32_t pn, uint8_t *key)
+{
+ struct ixgbe_hw *hw;
+ struct rte_eth_dev *dev;
+ uint32_t ctrl, i;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ if (idx != 0 && idx != 1)
+ return -EINVAL;
+
+ if (an >= 4)
+ return -EINVAL;
+
+ /* Set the PN */
+ pn = rte_cpu_to_be_32(pn);
+ IXGBE_WRITE_REG(hw, IXGBE_LSECRXPN(idx), pn);
+
+ /* Set the key */
+ for (i = 0; i < 4; i++) {
+ ctrl = (key[i * 4 + 0] << 0) |
+ (key[i * 4 + 1] << 8) |
+ (key[i * 4 + 2] << 16) |
+ (key[i * 4 + 3] << 24);
+ IXGBE_WRITE_REG(hw, IXGBE_LSECRXKEY(idx, i), ctrl);
+ }
+
+ /* Set the AN and validate the SA */
+ ctrl = an | (1 << 2);
+ IXGBE_WRITE_REG(hw, IXGBE_LSECRXSA(idx), ctrl);
+
+ return 0;
+}
+
RTE_PMD_REGISTER_PCI(net_ixgbe, rte_ixgbe_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_ixgbe, pci_id_ixgbe_map);
RTE_PMD_REGISTER_KMOD_DEP(net_ixgbe, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index 80350c2..ffced1c 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -43,6 +43,7 @@
#define IXGBE_FLAG_NEED_LINK_UPDATE (uint32_t)(1 << 0)
#define IXGBE_FLAG_MAILBOX (uint32_t)(1 << 1)
#define IXGBE_FLAG_PHY_INTERRUPT (uint32_t)(1 << 2)
+#define IXGBE_FLAG_MACSEC (uint32_t)(1 << 3)
/*
* Defines that were not part of ixgbe_type.h as they are not used by the
@@ -130,6 +131,10 @@
#define IXGBE_MISC_VEC_ID RTE_INTR_VEC_ZERO_OFFSET
#define IXGBE_RX_VEC_START RTE_INTR_VEC_RXTX_OFFSET
+#define IXGBE_SECTX_MINSECIFG_MASK 0x0000000F
+
+#define IXGBE_MACSEC_PNTHRSH 0xFFFFFE00
+
/*
* Information about the fdir mode.
*/
@@ -265,11 +270,44 @@ struct ixgbe_filter_info {
};
/*
+ * Statistics counters collected by the MACsec
+ */
+struct ixgbe_macsec_stats {
+ /* TX port statistics */
+ uint64_t out_pkts_untagged;
+ uint64_t out_pkts_encrypted;
+ uint64_t out_pkts_protected;
+ uint64_t out_octets_encrypted;
+ uint64_t out_octets_protected;
+
+ /* RX port statistics */
+ uint64_t in_pkts_untagged;
+ uint64_t in_pkts_badtag;
+ uint64_t in_pkts_nosci;
+ uint64_t in_pkts_unknownsci;
+ uint64_t in_octets_decrypted;
+ uint64_t in_octets_validated;
+
+ /* RX SC statistics */
+ uint64_t in_pkts_unchecked;
+ uint64_t in_pkts_delayed;
+ uint64_t in_pkts_late;
+
+ /* RX SA statistics */
+ uint64_t in_pkts_ok;
+ uint64_t in_pkts_invalid;
+ uint64_t in_pkts_notvalid;
+ uint64_t in_pkts_unusedsa;
+ uint64_t in_pkts_notusingsa;
+};
+
+/*
* Structure to store private data for each driver instance (for each port).
*/
struct ixgbe_adapter {
struct ixgbe_hw hw;
struct ixgbe_hw_stats stats;
+ struct ixgbe_macsec_stats macsec_stats;
struct ixgbe_hw_fdir_info fdir;
struct ixgbe_interrupt intr;
struct ixgbe_stat_mapping_registers stat_mappings;
@@ -300,6 +338,9 @@ struct ixgbe_adapter {
#define IXGBE_DEV_PRIVATE_TO_STATS(adapter) \
(&((struct ixgbe_adapter *)adapter)->stats)
+#define IXGBE_DEV_PRIVATE_TO_MACSEC_STATS(adapter) \
+ (&((struct ixgbe_adapter *)adapter)->macsec_stats)
+
#define IXGBE_DEV_PRIVATE_TO_INTR(adapter) \
(&((struct ixgbe_adapter *)adapter)->intr)
@@ -445,4 +486,8 @@ uint32_t ixgbe_convert_vm_rx_mask_to_val(uint16_t rx_mask, uint32_t orig_val);
int ixgbe_fdir_ctrl_func(struct rte_eth_dev *dev,
enum rte_filter_op filter_op, void *arg);
+
+int ixgbe_disable_sec_tx_path_generic(struct ixgbe_hw *hw);
+
+int ixgbe_enable_sec_tx_path_generic(struct ixgbe_hw *hw);
#endif /* _IXGBE_ETHDEV_H_ */
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index b2d9f45..db9fc18 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -79,12 +79,15 @@
#include "base/ixgbe_common.h"
#include "ixgbe_rxtx.h"
+#include "rte_pmd_ixgbe.h"
+
/* Bit Mask to indicate what bits required for building TX context */
#define IXGBE_TX_OFFLOAD_MASK ( \
PKT_TX_VLAN_PKT | \
PKT_TX_IP_CKSUM | \
PKT_TX_L4_MASK | \
PKT_TX_TCP_SEG | \
+ PKT_TX_IXGBE_MACSEC | \
PKT_TX_OUTER_IP_CKSUM)
#if 1
@@ -519,6 +522,8 @@ tx_desc_ol_flags_to_cmdtype(uint64_t ol_flags)
cmdtype |= IXGBE_ADVTXD_DCMD_TSE;
if (ol_flags & PKT_TX_OUTER_IP_CKSUM)
cmdtype |= (1 << IXGBE_ADVTXD_OUTERIPCS_SHIFT);
+ if (ol_flags & PKT_TX_IXGBE_MACSEC)
+ cmdtype |= IXGBE_ADVTXD_MAC_LINKSEC;
return cmdtype;
}
diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe.h b/drivers/net/ixgbe/rte_pmd_ixgbe.h
index c2fb826..0c28ea2 100644
--- a/drivers/net/ixgbe/rte_pmd_ixgbe.h
+++ b/drivers/net/ixgbe/rte_pmd_ixgbe.h
@@ -42,6 +42,28 @@
#include <rte_ethdev.h>
/**
+ * If these flags are advertised by the PMD, the NIC supports the MACsec
+ * offload. The incoming MACsec traffics can be offloaded transparently
+ * after the MACsec offload is configured correctly by the application.
+ * And the application can set the PKT_TX_IXGBE_MACSEC flag in mbufs to
+ * enable the MACsec offload for the packets to be transmitted.
+ */
+#define DEV_RX_OFFLOAD_IXGBE_MACSEC_STRIP DEV_RX_OFFLOAD_RESERVED_0
+#define DEV_TX_OFFLOAD_IXGBE_MACSEC_INSERT DEV_TX_OFFLOAD_RESERVED_0
+
+/**
+ * This event will occur when the PN counter in a MACsec connection
+ * reach the exhaustion threshold.
+ */
+#define RTE_ETH_EVENT_IXGBE_MACSEC RTE_ETH_EVENT_RESERVED_0
+
+/**
+ * Offload the MACsec. This flag must be set by the application in mbuf
+ * to enable this offload feature for a packet to be transmitted.
+ */
+#define PKT_TX_IXGBE_MACSEC PKT_TX_RESERVED_0
+
+/**
* Set the VF MAC address.
*
* @param port
@@ -183,6 +205,106 @@ int
rte_pmd_ixgbe_set_vf_vlan_stripq(uint8_t port, uint16_t vf, uint8_t on);
/**
+ * Enable MACsec offload.
+ *
+ * @param port
+ * The port identifier of the Ethernet device.
+ * @param en
+ * 1 - Enable encryption (encrypt and add integrity signature).
+ * 0 - Disable encryption (only add integrity signature).
+ * @param rp
+ * 1 - Enable replay protection.
+ * 0 - Disable replay protection.
+ * @return
+ * - (0) if successful.
+ * - (-ENODEV) if *port* invalid.
+ * - (-ENOTSUP) if hardware doesn't support this feature.
+ */
+int rte_pmd_ixgbe_macsec_enable(uint8_t port, uint8_t en, uint8_t rp);
+
+/**
+ * Disable MACsec offload.
+ *
+ * @param port
+ * The port identifier of the Ethernet device.
+ * @return
+ * - (0) if successful.
+ * - (-ENODEV) if *port* invalid.
+ * - (-ENOTSUP) if hardware doesn't support this feature.
+ */
+int rte_pmd_ixgbe_macsec_disable(uint8_t port);
+
+/**
+ * Configure Tx SC (Secure Connection).
+ *
+ * @param port
+ * The port identifier of the Ethernet device.
+ * @param mac
+ * The MAC address on the local side.
+ * @return
+ * - (0) if successful.
+ * - (-ENODEV) if *port* invalid.
+ */
+int rte_pmd_ixgbe_macsec_config_txsc(uint8_t port, uint8_t *mac);
+
+/**
+ * Configure Rx SC (Secure Connection).
+ *
+ * @param port
+ * The port identifier of the Ethernet device.
+ * @param mac
+ * The MAC address on the remote side.
+ * @param pi
+ * The PI (port identifier) on the remote side.
+ * @return
+ * - (0) if successful.
+ * - (-ENODEV) if *port* invalid.
+ */
+int rte_pmd_ixgbe_macsec_config_rxsc(uint8_t port, uint8_t *mac, uint16_t pi);
+
+/**
+ * Enable Tx SA (Secure Association).
+ *
+ * @param port
+ * The port identifier of the Ethernet device.
+ * @param idx
+ * The SA to be enabled (0 or 1).
+ * @param an
+ * The association number on the local side.
+ * @param pn
+ * The packet number on the local side.
+ * @param key
+ * The key on the local side.
+ * @return
+ * - (0) if successful.
+ * - (-ENODEV) if *port* invalid.
+ * - (-EINVAL) if bad parameter.
+ */
+int rte_pmd_ixgbe_macsec_select_txsa(uint8_t port, uint8_t idx, uint8_t an,
+ uint32_t pn, uint8_t *key);
+
+/**
+ * Enable Rx SA (Secure Association).
+ *
+ * @param port
+ * The port identifier of the Ethernet device.
+ * @param idx
+ * The SA to be enabled (0 or 1)
+ * @param an
+ * The association number on the remote side.
+ * @param pn
+ * The packet number on the remote side.
+ * @param key
+ * The key on the remote side.
+ * @return
+ * - (0) if successful.
+ * - (-ENODEV) if *port* invalid.
+ * - (-EINVAL) if bad parameter.
+ */
+int rte_pmd_ixgbe_macsec_select_rxsa(uint8_t port, uint8_t idx, uint8_t an,
+ uint32_t pn, uint8_t *key);
+
+/**
* Response sent back to ixgbe driver from user app after callback
*/
enum rte_pmd_ixgbe_mb_event_rsp {
diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe_version.map b/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
index 92434f3..6d68934 100644
--- a/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
+++ b/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
@@ -15,3 +15,14 @@ DPDK_16.11 {
rte_pmd_ixgbe_set_vf_vlan_insert;
rte_pmd_ixgbe_set_vf_vlan_stripq;
} DPDK_2.0;
+
+DPDK_17.02 {
+ global:
+
+ rte_pmd_ixgbe_macsec_enable;
+ rte_pmd_ixgbe_macsec_disable;
+ rte_pmd_ixgbe_macsec_config_txsc;
+ rte_pmd_ixgbe_macsec_config_rxsc;
+ rte_pmd_ixgbe_macsec_select_txsa;
+ rte_pmd_ixgbe_macsec_select_rxsa;
+} DPDK_16.11;
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox