When the mtu_set() function is not implemented, rte_eth_dev_set_mtu()
fails with -ENOTSUP and mtu is not stored in the mtu field in the
rte_eth_dev_data. This causes the mtu in Vmxnet3_MiscConf which is
shared with hypervisor to always be set to 1500.
This may cause issues receiving jumbo frames
Replace the boilerplate BSD license text with the equivalent
SPDX license id.
Signed-off-by: Stephen Hemminger
Acked-by: Tetsuya Mukawa
---
drivers/net/null/rte_eth_null.c | 34 +++--
1 file changed, 3 insertions(+), 31 deletions(-)
diff --git a/drivers/net/null/rte
check_tsc_flags() parses /proc/cpuinfo and prints
warning messages if any cores don't have constant_tsc
and nonstop_tsc. It has no functional meaning.
This consumes a noticeable amount of time in
secondary processes - on my test system, it consumes
21ms out of the 66ms total execution time for
rte
rte_eal_init() is much faster in secondary processes since
hugepages don't need to be zeroed. But there's still
non-trivial delays in the timer subsystem initialization
due to the 100ms sleep used to calculate TSC hz. So use
the rte_mp_msg framework to allow secondary processes
to get the TSC hz
The code checks both rte_mp_request_sync() return
code and that the number of messages in the reply
equals 1. If rte_mp_request_sync() succeeds but
there was more than one message, those messages
would get leaked.
Found via code review by Anatoly Burakov of patches
that used the vhost code as a t
check_tsc_flags() parses /proc/cpuinfo and prints
warning messages if any cores don't have constant_tsc
and nonstop_tsc. It has no functional meaning.
This consumes a noticeable amount of time in
secondary processes - on my test system, it consumes
21ms out of the 66ms total execution time for
rte
rte_eal_init() is much faster in secondary processes since
hugepages don't need to be zeroed. But there's still
non-trivial delays in the timer subsystem initialization
due to the 100ms sleep used to calculate TSC hz. So use
the rte_mp_msg framework to allow secondary processes
to get the TSC hz
On 8/16/19, 12:56 AM, "Burakov, Anatoly" wrote:
> @@ -89,6 +96,65 @@ set_tsc_freq(void)
> eal_tsc_resolution_hz = freq;
> }
>
> +static void
> +set_tsc_freq_secondary(void)
> +{
> + struct rte_mp_msg mp_req;
> + struct rte_mp_re
Added mlx5_rxtx_vec_altivec.h which supports vectorized RX
using Altivec vector code. Modified associated build files
to use the new code.
Cc: shah...@mellanox.com
Cc: ys...@mellanox.com
Cc: viachesl...@mellanox.com
Signed-off-by: David Christensen
---
Changelog since v1:
- Resovled meson build
>
> From: Jerin Jacob
>
> RTE_BPF_ARG_PTR_STACK is used as internal program
> arg type. Rename to RTE_BPF_ARG_RESERVED to
> avoid exposing internal program type.
>
> Signed-off-by: Jerin Jacob
> ---
Acked-by: Konstantin Ananyev
Tested-by: Konstantin Ananyev
> 2.22.0
Get rid of duplicate definitions for rte_mbuf and related macros.
Include rte_mbuf_core.h instead.
Signed-off-by: Konstantin Ananyev
---
examples/bpf/mbuf.h | 605
examples/bpf/t2.c | 5 +-
examples/bpf/t3.c | 3 +-
3 files changed, 5 insertio
Right now inclusion of rte_mbuf.h header can cause inclusion of
some arch/os specific headers.
That prevents it to be included directly by some
non-DPDK (but related) entities: KNI, BPF programs, etc.
To overcome that problem usually a separate definitions of rte_mbuf
structure is created within th
Right now RTE_CACHE_ and IOVA definitions are located inside rte_memory.h
That might cause an unwanted inclusions of arch/os specific header files.
See [1] for particular problem example.
Probably the simplest way to deal with such problems -
move these definitions into rte_commmon.h
Note that thi
Right now inclusion of rte_mbuf.h header can cause inclusion of
some arch/os specific headers.
That prevents it to be included directly by some
non-DPDK (but related) entities: KNI, BPF programs, etc.
To overcome that problem usually a separate definitions of rte_mbuf
structure is created within th
Hi all,
This is a continuation of thread we have had before but it would be easier when
new thread created.
Current RSA signature test takes as an input plaintext:
asym_op->rsa.message.data = rsaplaintext.data;
asym_op->rsa.message.length = rsaplaintext.len;
But we do not speci
Hi Akhil,
Please see inline.
Thanks,
Anoob
> -Original Message-
> From: dev On Behalf Of Akhil Goyal
> Sent: Friday, August 16, 2019 2:02 PM
> To: Anoob Joseph ; Adrien Mazarguil
> ; Declan Doherty
> ; Pablo de Lara
> ; Thomas Monjalon
>
> Cc: Jerin Jacob Kollanukkaran ; Narayana Prasa
Hi Anoob,
>
> Hi Akhil,
>
> > > > >
> > > > > The rte_security API which enables inline protocol/crypto feature
> > > > > mandates that for every security session an rte_flow is created.
> > > > > This would internally translate to a rule in the hardware which
> > > > > would do packet
> > > > cl
On 8/16/19 8:55 AM, pbhagavat...@marvell.com wrote:
From: Pavan Nikhilesh
Add ptype set default functionality i.e. enable ptype by default and
report ptypes even if application disables ptypes.
Signed-off-by: Pavan Nikhilesh
May be it is better to have rte_ethdev_supported_ptype_set_dummy()
The patch should add item in release notes (as well as all other
subsequent patches which add more features).
On 8/16/19 8:55 AM, pbhagavat...@marvell.com wrote:
From: Pavan Nikhilesh
Add `rte_eth_dev_set_supported_ptypes` function that will allow the
application to inform the PMD the packet t
On 8/16/19 8:55 AM, pbhagavat...@marvell.com wrote:
From: Pavan Nikhilesh
Add new Rx offload flag `DEV_RX_OFFLOAD_FLOW_MARK` that can be used to
enable/disable PMDs write to `rte_mbuf::hash::fdir::hi`.
Notes similar to RSS hash.
It requires better motivation why. It lets Rx queue know that
i
On 15-Aug-19 12:27 PM, Jim Harris wrote:
rte_eal_init() is much faster in secondary processes since
hugepages don't need to be zeroed. But there's still
non-trivial delays in the timer subsystem initialization
due to the 100ms sleep used to calculate TSC hz. So use
the rte_mp_msg framework to a
Prefix "net: " is typically used for lib/librte_net. It should be
"drivers/net: " here.
"Rx flow action offload" sounds strange. May be "Rx flow mark offload".
On 8/16/19 8:55 AM, pbhagavat...@marvell.com wrote:
From: Pavan Nikhilesh
Add DEV_RX_OFFLOAD_FLOW_MARK flag for all supported NICs.
Prefix "net: " is typically used for lib/librte_net. It should be
"drivers/net: " here.
On 8/16/19 8:55 AM, pbhagavat...@marvell.com wrote:
From: Pavan Nikhilesh
Add DEV_RX_OFFLOAD_RSS_HASH flag for all supported NICs.
"all supported NICs" sounds wrong here. I'd say
"all PMDs which support
On 8/16/19 8:55 AM, pbhagavat...@marvell.com wrote:
From: Pavan Nikhilesh
Add new Rx offload flag `DEV_RX_OFFLOAD_RSS_HASH` which can be used to
enable/disable PMDs write to `rte_mbuf::hash::rss`.
It should be highlighted that presence of the RSS hash is indicated
by PKT_RX_RSS_HASH flag in m
24 matches
Mail list logo
