Flow support for 1300 series adapters with the 'Advanced Filter'
mode disabled via the UCS management interface. This allows:
Attributes: ingress
Items: Outer eth, ipv4, ipv6, udp, sctp, tcp, vxlan. Inner eth, ipv4,
ipv6, udp, tcp.
Actions: queue and void
Selectors: 'is', 'spec' and 'mask'.
Added a debug function to print enic filters and actions when
rte_validate_flow is called. Compiled in CONFIG_RTE_LIBRTE_ENIC_DEBUG_FLOW
is enabled and log level is INFO.
Signed-off-by: John Daley
Reviewed-by: Nelson Escobar
---
drivers/net/enic/enic_flow.c | 138 +++
Update enic NIC guide, release notes and add flow API to the
supported features list.
Signed-off-by: John Daley
Reviewed-by: Nelson Escobar
---
doc/guides/nics/enic.rst | 51 ++
doc/guides/nics/features/enic.ini | 1 +
doc/guides/rel_notes/rel
Flow support for 1300 series adapters with the 'Advanced Filter'
mode enabled via the UCS management interface. This enables:
Attributes: ingress
Items: Outer eth, ipv4, ipv6, udp, sctp, tcp, vxlan. Inner eth, ipv4,
ipv6, udp, tcp.
Actions: queue, mark, flag and void
Selectors: 'is', 'spec'
5-tuple exact Flow support for 1200 series adapters. This allows:
Attributes: ingress
Items: ipv4, ipv6, udp, tcp (must exactly match src/dst IP
addresses and ports and all must be specified).
Actions: queue and void
Selectors: 'is'
Signed-off-by: John Daley
Reviewed-by: Nelson Escobar
--
This V3 is rebased on dpdk-next-net and retargeted at 17.08. Also,
inner ipv4, ipv6, udp, tcp support added for 1300 series VICs.
thank you,
johnd
John Daley (6):
net/enic: flow API skeleton
net/enic: flow API for NICs with advanced filters enabled
net/enic: flow API for NICs with advanced
Stub callbacks for the generic flow API and a new FLOW debug define.
Signed-off-by: John Daley
Reviewed-by: Nelson Escobar
---
config/common_base | 1 +
drivers/net/enic/Makefile | 1 +
drivers/net/enic/enic.h| 1 +
drivers/net/enic/enic_ethdev.c | 21 +-
dri
Hi,
Seems my comments in v2 are not addressed, add the comments here again.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Michael Lilja
> Sent: Wednesday, May 17, 2017 6:02 AM
> To: dev@dpdk.org
> Cc: Michael Lilja
> Subject: [dpdk-dev] [PATCH v3] net/i40e:
> On May 12, 2017, at 4:42 PM, Bruce Richardson
> wrote:
>
> On Thu, May 11, 2017 at 11:03:43PM -0700, Tonghao Zhang wrote:
>> If the socket_id is invalid (e.g. -2, -3), the
>> memzone_reserve_aligned_thread_unsafe should return the
>> EINVAL and not ENOMEM. To avoid it, we should check the
>>
> On May 16, 2017, at 3:11 PM, Thomas Monjalon wrote:
>
> 03/05/2017 13:29, Harry van Haaren:
>> The concept is to allow a software function register itself with EAL as
>> a "service", which requires CPU time to perform its duties. Multiple
>> services can be registered in an application, if mor
On Tue, 16 May 2017 21:25:37 +
Tom Hall wrote:
> I'm trying to make sense of the stats_get ierrors value. It doesn't appear
> that there is any consistency between any of the net drivers for what this
> value truly represents. For example, the ixgbe driver calculates the value as
>
>
> st
04/05/2017 13:35, Mcnamara, John:
>
> > -Original Message-
> > From: Yigit, Ferruh
> > Sent: Thursday, April 20, 2017 7:55 PM
> > To: dev@dpdk.org
> > Cc: Yigit, Ferruh ; Mcnamara, John
> > ; Tahhan, Maryam
> > Subject: [RFC 17.08] flow_classify: add librte_flow_classify library
>
>
> C
03/05/2017 13:29, Harry van Haaren:
> The concept is to allow a software function register itself with EAL as
> a "service", which requires CPU time to perform its duties. Multiple
> services can be registered in an application, if more than one service
> exists. The application can retrieve a list
Previously, the FDIR programming time is +11ms on i40e.
This patch will result in an average programming time of
22usec with a max of 60usec .
Signed-off-by: Michael Lilja
---
v3:
* Code style fix
---
drivers/net/i40e/i40e_fdir.c | 21 +
1 file changed, 13 insertions(+), 8 d
09/05/2017 16:57, Radu Nicolau:
> In this RFC we introduce a mechanism to support inline hardware
> acceleration of symmetric crypto processing of IPsec flows
> on Ethernet adapters within the cryptodev framework,
> specifically this RFC includes the initial enablement work
> for the Intel® 82599 1
I'm trying to make sense of the stats_get ierrors value. It doesn't appear that
there is any consistency between any of the net drivers for what this value
truly represents. For example, the ixgbe driver calculates the value as
stats->ierrors = hw_stats->crcerrs +
hw_
11/05/2017 18:38, Jerin Jacob:
> > +struct rte_eth_rx_event_adapter_config {
>
> Since this code is going to be at lib/librte_eventdev, We must start all
> public symbols and file name with rte_event_*.
+1, please do not mix the namespaces
Any volunteer to review this patch, please?
07/04/2017 12:26, Ray Zhang:
> From: Ray Zhang
>
> Add a new RTE_PTYPE_L2_ETHER_PPPOE and its support in
> rte_net_get_ptype()
>
> Signed-off-by: Ray Zhang
> ---
>
> Resend the patch
>
> lib/librte_mbuf/rte_mbuf_ptype.h | 7 +++
> lib/librte_
On Tue, May 16, 2017 at 01:51:52PM +0200, Jan Viktorin wrote:
> On Tue, 16 May 2017 07:44:59 -0400
> Neil Horman wrote:
>
> > On Tue, May 16, 2017 at 12:51:40PM +0200, Jan Viktorin wrote:
> > > Hello Jimmy,
> > >
> > > On Tue, 16 May 2017 15:38:22 +0530
> > > Jimmy Carter wrote:
> > >
> > >
On 5/11/2017 12:51 PM, Gowrishankar wrote:
> From: Gowrishankar Muthukrishnan
>
> In kni_allocate_mbufs(), we attempt to add max_burst (32) count of mbuf
> always into alloc_q, which is excessively leading too many rte_pktmbuf_
> free() when alloc_q is contending at high packet rate (for eg 10Gig
On 5/16/2017 5:14 PM, John Miller wrote:
> Coverity issue: 144512
> Coverity issue: 144513
> Fixes: 9c7188a68d7b ("net/ark: provide API for hardware modules pktchkr and
> pktgen")
>
> Signed-off-by: John Miller
Series applied to dpdk-next-net/master, thanks.
On 5/15/2017 11:54 AM, Andrew Rybchenko wrote:
> On 05/15/2017 01:24 PM, Ferruh Yigit wrote:
>> Instead of many PMD define their own macro, define a generic one in
>> ethdev and use that in PMDs.
>>
>> Signed-off-by: Ferruh Yigit
>> Acked-by: Allain Legacy
>> Acked-by: Wenzhuo Lu
>
> Acked-by:
Coverity issue: 144517
Fixes: 1131cbf0fb2b ("net/ark: stub PMD for Atomic Rules Arkville")
Signed-off-by: John Miller
---
drivers/net/ark/ark_ethdev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index f8fb359..017817e 1006
Coverity issue: 144514
Fixes: 727b3fe292bc ("net/ark: integrate PMD")
Signed-off-by: John Miller
---
drivers/net/ark/ark_ethdev.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index 995c93d..9143fc4 100644
---
Coverity issue: 144520
Fixes: 727b3fe292bc ("net/ark: integrate PMD")
Signed-off-by: John Miller
---
drivers/net/ark/ark_ethdev.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index 9143fc4..f8fb359 100644
---
Coverity issue: 144512
Coverity issue: 144513
Fixes: 9c7188a68d7b ("net/ark: provide API for hardware modules pktchkr and
pktgen")
Signed-off-by: John Miller
---
drivers/net/ark/ark_pktchkr.c | 2 +-
drivers/net/ark/ark_pktgen.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --
On 5/15/2017 10:19 PM, Ferruh Yigit wrote:
On 5/15/2017 1:37 PM, Hemant Agrawal wrote:
Signed-off-by: Hemant Agrawal
---
config/defconfig_arm64-dpaa2-linuxapp-gcc | 2 +-
mk/machine/dpaa2/rte.vars.mk | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/config/def
16/05/2017 16:20, Mcnamara, John:
>
> > -Original Message-
> > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > Sent: Friday, May 12, 2017 10:24 AM
> > ,,,
> >
> > > The current DPDK "single sentence per line plus wrap at ~120 characters"
> > > guideline is unusual, not supported by
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, May 12, 2017 10:24 AM
> ,,,
>
> > The current DPDK "single sentence per line plus wrap at ~120 characters"
> > guideline is unusual, not supported by editors and, with rare
> > exceptions, not follow
On Tue, 16 May 2017 18:57:41 +0530
Jimmy Carter wrote:
> I assume after git clone https://github.com/RehiveTech/buildroot
> I need to git checkout dpdk-support-v5
Yes, I forgot to mention...
> I get legacy error on running make
> root@xav101000739:~/Downloads/dpdk/newbuildroot/buildroot# *make
> -Original Message-
> From: Stojaczyk, DariuszX
> Sent: Tuesday, May 16, 2017 4:35 PM
> To: dev@dpdk.org
> Cc: Wodkowski, PawelX ; Stojaczyk, DariuszX
>
> Subject: [PATCH] vhost: fix deadlock on rte_vhost_driver_unregister()
>
> Consider the following scenario, threads A and B:
> (A)
>
On Tue, 16 May 2017 17:25:20 +0530
Jimmy Carter wrote:
> Hi All
>
> Attached is the complete env variables file
> I have added RTE_KERNELDIR too
> Also I am now using gnu-eabi version 5.4.0
> [arm-openwrt-linux-muslgnueabi-gcc (LEDE GCC 5.4.0 r3909-6411a12) 5.4.0]
> But I am still getting the s
Hi All
Attached is the complete env variables file
I have added RTE_KERNELDIR too
Also I am now using gnu-eabi version 5.4.0
[arm-openwrt-linux-muslgnueabi-gcc (LEDE GCC 5.4.0 r3909-6411a12) 5.4.0]
But I am still getting the same error
Currently I am not using buildroot
Is there any step by step
On Tue, 16 May 2017 07:44:59 -0400
Neil Horman wrote:
> On Tue, May 16, 2017 at 12:51:40PM +0200, Jan Viktorin wrote:
> > Hello Jimmy,
> >
> > On Tue, 16 May 2017 15:38:22 +0530
> > Jimmy Carter wrote:
> >
> > > Hi All
> > >
> > > I am using dpdk16.11.1 and want to use openwrt external tool
On Tue, May 16, 2017 at 12:51:40PM +0200, Jan Viktorin wrote:
> Hello Jimmy,
>
> On Tue, 16 May 2017 15:38:22 +0530
> Jimmy Carter wrote:
>
> > Hi All
> >
> > I am using dpdk16.11.1 and want to use openwrt external toolchain so that I
> > can cross compile for arm cortex 15
> > neon.(arm_cortex
On Tue, 16 May 2017 13:22:19 +0200
Thomas Monjalon wrote:
> 16/05/2017 12:51, Jan Viktorin:
> > DPDK does not support OpenWRT because (as far as I know) nobody from
> > the DPDK community is using it in this way. I build DPDK via Buildroot
> > but this is unsupported by the DPDK upstream.
>
>
Hi All
I am using dpdk16.11.1 and want to use openwrt external toolchain so that I
can cross compile for arm cortex 15
neon.(arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi)
My target board is Tp link archer C2600.
I am have assigned these env variables but still getting compilation error
export
ST
16/05/2017 12:51, Jan Viktorin:
> DPDK does not support OpenWRT because (as far as I know) nobody from
> the DPDK community is using it in this way. I build DPDK via Buildroot
> but this is unsupported by the DPDK upstream.
Why means "unsupported upstream"? Are we missing some patches?
Should we i
Consider the following scenario, threads A and B:
(A)
* fdset_event_dispatch() start
* pfdentry->busy = 1;
* vhost_user_read_cb() start
* vhost_destroy_device() start
(B)
* rte_vhost_driver_unregister() start
* pthread_mutex_lock(&vsocket->conn_mutex);
* fdset_del()
* endles
Hello Jimmy,
On Tue, 16 May 2017 15:38:22 +0530
Jimmy Carter wrote:
> Hi All
>
> I am using dpdk16.11.1 and want to use openwrt external toolchain so that I
> can cross compile for arm cortex 15
> neon.(arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi)
I've never built DPDK with musl-eabi. I don'
On Tue, May 16, 2017 at 11:02 AM, Thomas Monjalon
wrote:
> 16/05/2017 11:39, Alejandro Lucero:
> > Maybe we need another feature for detected link speed report capability.
> >
> > There is already support for ETH_SPEED_NUM_NONE if the speed is not
> defined
> > or it can not be specified by the d
Thanks Shyam, great to see that people get the idea behind this design!
Regards, Cristian
From: Shyam Shrivastav [mailto:shrivastav.sh...@gmail.com]
Sent: Wednesday, May 10, 2017 5:14 PM
To: Nidhia Varghese
Cc: Dumitrescu, Cristian ; Singh, Jasvinder
; dev@dpdk.org; us...@dpdk.org
Subject: Re:
16/05/2017 11:39, Alejandro Lucero:
> Maybe we need another feature for detected link speed report capability.
>
> There is already support for ETH_SPEED_NUM_NONE if the speed is not defined
> or it can not be specified by the device. Netronome has some firmwares
> without that link speed report c
Maybe we need another feature for detected link speed report capability.
There is already support for ETH_SPEED_NUM_NONE if the speed is not defined
or it can not be specified by the device. Netronome has some firmwares
without that link speed report capability, although maybe we are not the
only
Applied, let's start a new release cycle :)
> -Original Message-
> From: Ravi Kerur [mailto:rke...@gmail.com]
> Sent: Thursday, May 11, 2017 2:49 AM
> To: dev@dpdk.org
> Cc: Mcnamara, John ; Ravi Kerur
>
> Subject: [PATCH v3] doc: Merge l3fwd and l3fwd-acl documentation files
>
> Merge l3fwd and l3fwd-acl documentation to reflect
On Tue, May 16, 2017 at 05:36:22AM +, Shahaf Shuler wrote:
> Monday, May 15, 2017 5:26 PM, Thomas Monjalon:
> > 15/05/2017 16:12, Richardson, Bruce:
> > > From: Yigit, Ferruh
> > > > On 5/15/2017 2:15 PM, Bruce Richardson wrote:
> > > > > On Mon, May 15, 2017 at 02:35:55PM +0200, Thomas Monjalo
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang
> Sent: Sunday, May 14, 2017 8:50 PM
> To: adrien.mazarg...@6wind.com
> Cc: dev@dpdk.org; Lu, Wenzhuo ; Xing, Beilei
> ; Zhang, Qi Z
> Subject: [dpdk-dev] [RFC 2/2] doc/guides/prog_guide: add new flow
>
> -Original Message-
> From: Yigit, Ferruh
> Sent: Monday, May 15, 2017 12:00 PM
> To: Shepard Siegel ; Ed Czeck
> ; John Miller ;
> Mcnamara, John ; Harish Patil
> ; Rasesh Mody ; Rahul
> Lakkireddy ; Hemant Agrawal
> ; Shreyansh Jain ; Lu,
> Wenzhuo ; Marcin Wojtas ; Michal
> Krawczyk ;
49 matches
Mail list logo
