> From: Pavan Nikhilesh
>
> Add new offload flags ``DEV_RX_OFFLOAD_PTYPE``,
> ``DEV_RX_OFFLOAD_RSS`` and ``DEV_RX_OFFLOAD_FLOW_MARK``.
>
> Signed-off-by: Pavan Nikhilesh
> Acked-by: Andrew Rybchenko
> Acked-by: Jerin Jacob
Acked-by: Hemant Agrawal
From: Pavan Nikhilesh
Add new offload flags ``DEV_RX_OFFLOAD_RSS`` and ``DEV_RX_OFFLOAD_FLOW_MARK``.
Add new function ``rte_eth_dev_set_supported_ptypes`` to allow application to
set specific ptypes to be updated in ``rte_mbuf::packet_type``
Signed-off-by: Pavan Nikhilesh
Acked-by: Andrew Rybch
Hi Jerin,
> > > > > Since application has two knobs rte_eth_dev_get_supported_ptypes()
> > > > > and DEV_RX_OFFLOAD_PTYPE. We may not need to new ol_flags for
> > this
> > > > change. Right?
> > > > > i.e if application sets the DEV_RX_OFFLOAD_PTYPE, The application
> > > > > will get the parsed p
Hi
>
> From: Pavan Nikhilesh
>
> Add new offload flags ``DEV_RX_OFFLOAD_RSS`` and ``DEV_RX_OFFLOAD_FLOW_MARK``.
> Add new function ``rte_eth_dev_set_supported_ptypes`` to allow application to
> set specific ptypes to be updated in ``rte_mbuf::packet_type``
>
> Signed-off-by: Pavan Nikhilesh
Hi,
>-Original Message-
>From: Ananyev, Konstantin
>Sent: Friday, August 9, 2019 2:17 PM
>To: Pavan Nikhilesh Bhagavatula ; Jerin
>Jacob Kollanukkaran ;
>step...@networkplumber.org; arybche...@solarflare.com;
>hemant.agra...@nxp.com; tho...@monjalon.net; Yigit, Ferruh
>; Richardson, Bruce
I think the silent breaking is still not solved for
DEV_RX_OFFLOAD_RSS_HASH and DEV_RX_OFFLOAD_FLOW_MARK.
An old application will still compile without any problem, but the RSS
hash will not be written and the app will break... They should be
negative. Eg DEV_RX_OFFLOAD_NO_RSS_HASH and DEV_RX_
On Thu, Aug 8, 2019 at 7:38 PM Aaron Conole wrote:
>
> Because the eal interrupt framework can race when invoking the callback
> and a separate unregister call, the test needs to accommodate the chance
> that the two collide. Do this by checking the return value of unregister
> against the race-c
Regarding rxtx_callbacks, it's the only one featuring the use of
hardware timestamping. I would delay its removal until the feature is
more known and mature.
Tom
On 2019-07-18 11:33, Bruce Richardson wrote:
A standard item on the agenda of the DPDK technical board meetings has been
the number
On 8/9/19 12:13 PM, Tom Barbette wrote:
I think the silent breaking is still not solved for
DEV_RX_OFFLOAD_RSS_HASH and DEV_RX_OFFLOAD_FLOW_MARK.
An old application will still compile without any problem, but the RSS
hash will not be written and the app will break... They should be
negative.
> -Original Message-
> From: Tom Barbette
> Sent: Friday, August 9, 2019 2:44 PM
> To: Pavan Nikhilesh Bhagavatula ; Jerin Jacob
> Kollanukkaran ; step...@networkplumber.org;
> arybche...@solarflare.com; hemant.agra...@nxp.com;
> tho...@monjalon.net; ferruh.yi...@intel.com;
> bruce.richard
When running auth NULL cases while using
vfio_pci, DMAR read/write faults appear. It
happens even if digest_length is set to 0.
This is caused by auth_res_addr initialized
as 0x0.
Fixes: 4e0955bddb08
Cc: Fiona Trahe
Signed-off-by: Damian Nowak
---
drivers/crypto/qat/qat_sym.c | 5 ++---
1 file
In APP_MODE_SRTCM_COLOR_AWARE mode, sample app compilation fails
due to wrong meter color type conversion.
Fixes: fc8a10d8527a ("examples/qos_meter: add color policy")
error log-
/qos_meter/main.c:error: conversion to incomplete type
(enum rte_meter_color) input_color);
Signed-off-by: Jasvinder
From: Pavan Nikhilesh
Add new offload flags ``DEV_RX_OFFLOAD_RSS_HASH`` and
``DEV_RX_OFFLOAD_FLOW_MARK``.
Add new function ``rte_eth_dev_set_supported_ptypes`` to allow application
to set specific ptypes to be updated in ``rte_mbuf::packet_type``
Signed-off-by: Pavan Nikhilesh
Acked-by: Andrew
> Add new offload flags ``DEV_RX_OFFLOAD_RSS_HASH`` and
> ``DEV_RX_OFFLOAD_FLOW_MARK``.
> Add new function ``rte_eth_dev_set_supported_ptypes`` to allow application
> to set specific ptypes to be updated in ``rte_mbuf::packet_type``
>
> Signed-off-by: Pavan Nikhilesh
> Acked-by: Andrew Rybchenk
>
> 07/08/2019 15:39, Akhil Goyal:
> >
> > >
> > > Check the return value of the rte_eth_dev_rss_hash_conf_get function.
> > >
> > > Coverity issue: 344970
> > > Fixes: 3a690d5a65e2 ("examples/ipsec-secgw: fix first packet with inline
> crypto")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-
> -Original Message-
> From: Singh, Jasvinder
> Sent: Friday, August 9, 2019 10:37 AM
> To: dev@dpdk.org
> Cc: Dumitrescu, Cristian ; Peng, Yuan
>
> Subject: [PATCH] examples/qos_meter: fix meter color type conversion
>
> In APP_MODE_SRTCM_COLOR_AWARE mode, sample app compilation fails
From: Rastislav Cernay
The rte_eth_dev_close() function now handles freeing resources for
devices (e.g., mac_addrs). To conform with the new close() behaviour we
are asserting the RTE_ETH_DEV_CLOSE_REMOVE flag so that
rte_eth_dev_close() releases all device level dynamic memory.
Signed-off-by:
Acked-by: Jan Remes
On Fri, Aug 9, 2019 at 4:59 PM Rastislav Cernay wrote:
>
> From: Rastislav Cernay
>
> The rte_eth_dev_close() function now handles freeing resources for
> devices (e.g., mac_addrs). To conform with the new close() behaviour we
> are asserting the RTE_ETH_DEV_CLOSE_REMOVE fl
From: Jerin Jacob
bpf_validate does not allow to execute
RTE_BPF_ARG_PTR_STACK for no reason.
Fix it by enhancing the prog_arg.type check.
Fixes: 6e12ec4c4d6d ("bpf: add more checks")
Cc: sta...@dpdk.org
Signed-off-by: Jerin Jacob
---
lib/librte_bpf/bpf_validate.c | 1 +
1 file changed, 1 ins
This reverts commit aa2c00702bad7b2c742e11a86cb9dbbb8364fd88, which
introduced the possibility of an invalid address exception when running
an application with a stopped receive queue. The issues with rxq stop/start
will be revisited in the 19.11 release timeframe.
Fixes: aa2c00702bad ("net/bnxt:
On Fri, Aug 9, 2019 at 10:22 AM Lance Richardson <
lance.richard...@broadcom.com> wrote:
> This reverts commit aa2c00702bad7b2c742e11a86cb9dbbb8364fd88, which
> introduced the possibility of an invalid address exception when running
> an application with a stopped receive queue. The issues with rx
IBM Power9 testing for v19.08-rc4
Hi-
The following describes the test completed for v19.08-rc4 run on IBM
Power9 hardware.
* Single port stability test using l3fwd (16 cpus) and TRex, tested 64
and 1500 byte packets at a 0.0% drop rate for 4 hours each.
No errors or regressions were seen
22 matches
Mail list logo
