Le 07/03/2018 à 04:56, sujith sankar a écrit :
Is PMD for Broadcom/Emulex OCe14000 OCP Skyhawk-R available? There
are a few documents in Broadcom's site. But could not find the source
code of it.
Right, it has not been upstreamed. Currently, it is even deprecated at
6WIND for our new release
Hi Akhil, Radu,
Can you review the patch set and share your comments?
Thanks,
Anoob
On 01/03/18 14:51, Anoob Joseph wrote:
This series enables application to set the sequence number soft limit
for IPsec offload. In inline IPsec offload, as the sequence number
(maintained by PMD/device) reaches
When allocating a new mbuf for Rx, the value of m->data_off should be
reset to its default value (RTE_PKTMBUF_HEADROOM), instead of reusing
the previous undefined value, which could cause the packet to have a too
small or too high headroom.
On Mon, Mar 5, 2018 at 11:28 PM Ferruh Yigit wrote:
> O
From: Hyong Youb Kim
Signed-off-by: Hyong Youb Kim
Reviewed-by: John Daley
---
drivers/net/enic/meson.build | 19 +++
drivers/net/meson.build | 2 +-
2 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/enic/meson.build
diff --git a/drivers/ne
From: Hyong Youb Kim
Signed-off-by: Hyong Youb Kim
Reviewed-by: John Daley
---
doc/guides/nics/enic.rst | 8
1 file changed, 8 insertions(+)
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index 7e19cf88a..0bc55936a 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/gui
From: Hyong Youb Kim
Signed-off-by: Hyong Youb Kim
Reviewed-by: John Daley
---
drivers/net/enic/enic_clsf.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/net/enic/enic_clsf.c b/drivers/net/enic/enic_clsf.c
index 3ef1d0832..9d95201ec 100644
-
From: Hyong Youb Kim
Enable rx queue interrupts if the app requests them, and vNIC has
enough interrupt resources. Use interrupt vector 0 for link status and
errors. Use vector 1 for rx queue 0, vector 2 for rx queue 1, and so
on. So, with n rx queues, vNIC needs to have at n + 1 interrupts.
For
From: Hyong Youb Kim
The driver provides a DMA buffer to the firmware when it requests port
stats. The NIC then fills that buffer with latest stats. Currently,
the driver allocates the DMA buffer the first time it requests stats
and saves it for later use. This can lead to crashes when
primary/se
From: Hyong Youb Kim
Signed-off-by: Hyong Youb Kim
Reviewed-by: John Daley
---
drivers/net/enic/enic_ethdev.c | 76 --
1 file changed, 65 insertions(+), 11 deletions(-)
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index e
From: Hyong Youb Kim
VIC does not support VLAN filtering at the moment. The firmware does
accept the filter add/del commands and returns success. But, they are
no-ops. To avoid confusion, remove the filter set handler so the app
sees an error instead of silent failure.
Also during the device con
From: Hyong Youb Kim
Currently, enic completely ignores the requested max Rx packet size
(rxmode.max_rx_pkt_len). The desired behavior is that the NIC hardware
drops packets larger than the requested size, even though they are
still smaller than MTU.
Cisco VIC does not have such a feature. But,
From: Hyong Youb Kim
Currently, when more than 1 receive queues are configured, the driver
always enables RSS with the driver's own default hash type, key, and
RETA. The user is unable to change any of the RSS settings. Address
this by implementing the ethdev RSS API as follows.
Correctly report
Signed-off-by: John Daley
Reviewed-by: Hyong Youb Kim
---
drivers/net/enic/enic.h | 80 -
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index c083985ee..e88af6bc9 100644
--- a/driv
V2: rebase, submit as patchset instead of individual patches so they
apply correctly.
V3: try again submitting patches one at a time so they are applied
in order (tester seems to be applying patches in order received
instead of looking at patch ID).
Hyong Youb Kim (9):
net/enic: allow the user t
Introduce API to install BPF based filters on ethdev RX/TX path.
Current implementation is pure SW one, based on ethdev RX/TX callback mechanism.
Signed-off-by: Konstantin Ananyev
---
lib/librte_bpf/Makefile| 2 +
lib/librte_bpf/bpf_pkt.c | 524 +++
Signed-off-by: Konstantin Ananyev
---
lib/librte_bpf/Makefile |3 +
lib/librte_bpf/bpf.c |4 +
lib/librte_bpf/bpf_jit_x86.c | 1155 ++
3 files changed, 1162 insertions(+)
create mode 100644 lib/librte_bpf/bpf_jit_x86.c
diff --git a/li
Introduce new testpmd commands to load/unload RX/TX BPF-based filters.
Signed-off-by: Konstantin Ananyev
---
app/test-pmd/cmdline.c | 144 +
1 file changed, 144 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index d1dc1
Add few simple eBPF programs as an example.
Signed-off-by: Konstantin Ananyev
---
test/bpf/dummy.c | 20 ++
test/bpf/mbuf.h | 556 +++
test/bpf/t1.c| 54 ++
test/bpf/t2.c| 31
4 files changed, 661 insertions(+)
create mode
librte_bpf provides a framework to load and execute eBPF bytecode
inside user-space dpdk based applications.
Not currently supported features:
- JIT
- cBPF
- tail-pointer call
- eBPF MAP
- skb
Signed-off-by: Konstantin Ananyev
---
config/common_base | 5 +
config/common_l
BPF is used quite intensively inside Linux (and BSD) kernels
for various different purposes and proved to be extremely useful.
In theory, BPF inside DPDK might also be used in a lot of places
for a lot of similar things.
As an example to:
- packet filtering/tracing (aka tcpdump)
- packet classifi
-Original Message-
From: Anatoly Burakov
Date: Wednesday, March 7, 2018 at 8:57 AM
To: "dev@dpdk.org"
Cc: "Mody, Rasesh" , Harish Patil
, "Shaikh, Shahed" ,
"keith.wi...@intel.com" , "jianfeng@intel.com"
, "andras.kov...@ericsson.com"
, "laszlo.vadk...@ericsson.com"
, "benjamin.wal...
> On Mar 6, 2018, at 8:28 AM, Ferruh Yigit wrote:
>
> It is not clear which per port offloads are enabled. Printing offloads
> values at forwarding start.
>
> CRC strip offload value was printed in more verbose manner, it is
> removed since Rx/Tx offload values covers it and printing only CRC o
Hi Pavan,
<... snipped ...>
> @@ -261,8 +267,12 @@ timvf_ring_create(struct rte_event_timer_adapter
> *adptr)
> timvf_write64(0x7, (uint8_t *)timr->vbar0 +
> TIM_VF_NRSPERR_ENA_W1C);
> timvf_write64(0x7, (uint8_t *)timr->vbar0 +
> TIM_VF_NRSPERR_ENA_W1S);
>
> - adptr->arm_burst =
Sure!! Thanks Ferruh.
-Original Message-
From: Yigit, Ferruh
Sent: Wednesday, March 7, 2018 2:45 AM
To: Koujalagi, MalleshX ; dev@dpdk.org
Cc: mtetsu...@gmail.com; step...@networkplumber.org
Subject: Re: [PATCH v3] net/null:Different mac address support
On 3/7/2018 3:31 AM, Mallesh Kouja
On Wed, 2018-03-07 at 17:44 +, Ferruh Yigit wrote:
> After experimental API process defined do we still need RTE_NEXT_ABI
> config and process which has similar targets?
>
> Are distros disable experimental APIs when delivering DPDK? And is
> there
> any config required to control this, as RTE
On 3/7/2018 5:17 PM, Ferruh Yigit wrote:
> On 2/27/2018 2:18 PM, Kirill Rybalchenko wrote:
>> In 18.02 release the ABI of ethdev component was changed.
>> To keep compatibility with previous versions of the library
>> the versioning of rte_eth_dev_filter_ctrl function was implemented.
>> As soon as
After experimental API process defined do we still need RTE_NEXT_ABI
config and process which has similar targets?
Are distros disable experimental APIs when delivering DPDK? And is there
any config required to control this, as RTE_NEXT_ABI intended to do?
Cc: Neil Horman
Cc: Thomas Monjalon
Cc
On 2/27/2018 2:18 PM, Kirill Rybalchenko wrote:
> In 18.02 release the ABI of ethdev component was changed.
> To keep compatibility with previous versions of the library
> the versioning of rte_eth_dev_filter_ctrl function was implemented.
> As soon as deprecation note was issued in 18.02 release,
07/03/2018 17:31, Arnon Warshavsky:
> > > Can we add a compile warning for adding new rte_panic's into code? It's
> a
>
> > > > nice tool while debugging, but it probably shouldn't be in any new
> > > > production code.
> >
> > Yes could be nice to automatically detect it in drivers/ or lib/
> > d
Signed-off-by: Anatoly Burakov
---
drivers/net/ena/base/ena_plat_dpdk.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ena/base/ena_plat_dpdk.h
b/drivers/net/ena/base/ena_plat_dpdk.h
index 8cba319..c1ebf00 100644
--- a/drivers/net/ena/base/ena_plat_dpdk.h
Signed-off-by: Anatoly Burakov
---
drivers/net/bnx2x/bnx2x.c | 2 +-
drivers/net/bnx2x/bnx2x_rxtx.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index fb02d0f..81f5dae 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++
Signed-off-by: Anatoly Burakov
---
Notes:
It is not 100% clear that all users of this function
need to allocate DMA memory. Corrections welcome.
drivers/net/i40e/i40e_ethdev.c | 2 +-
drivers/net/i40e/i40e_rxtx.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/d
It's there, so we might as well use it. Some operations will be
sped up by that.
Since we have to allocate an fbarray for memzones, we have to do
it before we initialize memory subsystem, because that, in
secondary processes, will (later) allocate more fbarrays than the
primary process, which will
Signed-off-by: Anatoly Burakov
---
Notes:
It is not 100% clear if this memzone is used for DMA,
corrections welcome.
drivers/net/cxgbe/sge.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/cxgbe/sge.c b/drivers/net/cxgbe/sge.c
index 3d5aa59..e31474c 100
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/linuxapp/eal/eal_memalloc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memalloc.c
b/lib/librte_eal/linuxapp/eal/eal_memalloc.c
index bbeeeba..c03e7bc 100644
--- a/lib/librte_eal/linuxapp/eal/e
This isn't used anywhere yet, but the support is now there. Also,
adding cleanup to allocation procedures, so that if we fail to
allocate everything we asked for, we can free all of it back.
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/common/eal_memalloc.h | 3 +
lib/librte_eal/lin
Signed-off-by: Anatoly Burakov
Reviewed-by: Venkatesh Srinivas
---
Notes:
Not sure if virtio needs to allocate DMA-capable memory,
being a software driver and all. Corrections welcome.
drivers/net/virtio/virtio_ethdev.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
dif
Nothing uses this code yet. The bulk of it is copied from old
memory allocation code (linuxapp eal_memory.c). We provide an
EAL-internal API to allocate either one page or multiple pages,
guaranteeing that we'll get contiguous VA for all of the pages
that we requested.
For single-file segments, we
This enables multiprocess synchronization for memory hotplug
requests at runtime (as opposed to initialization).
Basic workflow is the following. Primary process always does initial
mapping and unmapping, and secondary processes always follow primary
page map. Only one allocation request can be ac
Signed-off-by: Anatoly Burakov
---
Notes:
Not sure if DMA-capable memzones are needed for vmxnet3.
Corrections welcome.
drivers/net/vmxnet3/vmxnet3_ethdev.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmx
Signed-off-by: Anatoly Burakov
Acked-by: John Daley
---
Notes:
It is not 100% clear that second call to memzone_reserve
is allocating DMA memory. Corrections welcome.
drivers/net/enic/enic_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/enic/e
Signed-off-by: Anatoly Burakov
---
Notes:
Doing "grep -R rte_memzone_reserve drivers/net/qede" returns the following:
drivers/net/qede/qede_fdir.c: mz = rte_memzone_reserve_aligned(mz_name,
QEDE_MAX_FDIR_PKT_LEN,
drivers/net/qede/base/bcm_osal.c: mz =
rte_memzone_reserve_al
Signed-off-by: Anatoly Burakov
---
drivers/net/avf/avf_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/avf/avf_ethdev.c b/drivers/net/avf/avf_ethdev.c
index 4df6617..f69d697 100644
--- a/drivers/net/avf/avf_ethdev.c
+++ b/drivers/net/avf/avf_ethdev.c
@@ -1
Also, rewrite VFIO to rely on memory callbacks instead of manually
registering memory with VFIO. Callbacks will only be registered if
VFIO is enabled.
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/common/malloc_heap.c| 21 +
lib/librte_eal/linuxapp/eal/eal_memalloc.c
Currently it is not possible to use memory that is not owned by DPDK to
perform DMA. This scenarion might be used in vhost applications (like
SPDK) where guest send its own memory table. To fill this gap provide
API to allow registering arbitrary address in VFIO container.
Signed-off-by: Pawel Wod
for legacy memory mode, attach to primary's memseg list, and
map hugepages as before.
for non-legacy mode, preallocate all VA space and then do a
sync of local memory map.
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/bsdapp/eal/eal_hugepage_info.c | 7 ++
lib/librte_eal/common/eal_commo
This fixes the following drivers in one go:
grep -Rl rte_eth_dma_zone_reserve drivers/
drivers/net/avf/avf_rxtx.c
drivers/net/thunderx/nicvf_ethdev.c
drivers/net/e1000/igb_rxtx.c
drivers/net/e1000/em_rxtx.c
drivers/net/fm10k/fm10k_ethdev.c
drivers/net/vmxnet3/vmxnet3_rxtx.c
drivers/net/liquidio/l
This will be helpful down the line when we implement support for
allocating physically contiguous memory. We can no longer guarantee
physically contiguous memory unless we're in IOVA_AS_VA mode, but
we can certainly try and see if we succeed. In addition, this would
be useful for e.g. PMD's who may
Signed-off-by: Anatoly Burakov
Acked-by: Fiona Trahe
---
drivers/crypto/qat/qat_qp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/qat/qat_qp.c b/drivers/crypto/qat/qat_qp.c
index 87b9ce0..3f8ed4d 100644
--- a/drivers/crypto/qat/qat_qp.c
+++ b/drivers/cry
In preparation for implementing multiprocess support, we are adding
a version number and write locks to memseg lists.
There are two ways of implementing multiprocess support for memory
hotplug: either all information about mapped memory is shared
between processes, and secondary processes simply a
Each process will have its own callbacks. Callbacks will indicate
whether it's allocation and deallocation that's happened, and will
also provide start VA address and length of allocated block.
Since memory hotplug isn't supported on FreeBSD and in legacy mem
mode, it will not be possible to regis
If a user has specified that the zone should have contiguous memory,
use the new _contig allocation API's instead of normal ones.
Otherwise, account for the fact that unless we're in IOVA_AS_VA
mode, we cannot guarantee that the pages would be physically
contiguous, so we calculate the memzone size
This adds a new set of _contig API's to rte_memzone.
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/common/eal_common_memzone.c | 44
lib/librte_eal/common/include/rte_memzone.h | 154
2 files changed, 198 insertions(+)
diff --git a/lib/librte_eal/comm
This set of changes enables rte_malloc to allocate and free memory
as needed. The way it works is, first malloc checks if there is
enough memory already allocated to satisfy user's request. If there
isn't, we try and allocate more memory. The reverse happens with
free - we free an element, check it
Add a new (non-legacy) memory init path for EAL. It uses the
new memory hotplug facilities, although it's only being run
at startup.
If no -m or --socket-mem switches were specified, the new init
will not allocate anything, whereas if those switches were passed,
appropriate amounts of pages would
No major changes, just add some checks in a few key places, and
a new parameter to pass around.
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/common/eal_common_memzone.c | 20 +++---
lib/librte_eal/common/malloc_elem.c| 101 ++---
lib/librte_eal/common/malloc
Before, we were aggregating multiple pages into one memseg, so the
number of memsegs was small. Now, each page gets its own memseg,
so the list of memsegs is huge. To accommodate the new memseg list
size and to keep the under-the-hood workings sane, the memseg list
is now not just a single list, bu
rte_fbarray is a simple indexed array stored in shared memory
via mapping files into memory. Rationale for its existence is the
following: since we are going to map memory page-by-page, there
could be quite a lot of memory segments to keep track of (for
smaller page sizes, page count can easily rea
Malloc heap is now a doubly linked list, so it's now possible to
iterate over each malloc element regardless of its state.
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/common/include/rte_malloc.h | 9 +
lib/librte_eal/common/malloc_elem.c| 24
lib/l
We need this function to join newly allocated segments with the heap.
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/common/malloc_elem.c | 6 +++---
lib/librte_eal/common/malloc_elem.h | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib/librte_eal/common/malloc_elem.c
The test was expecting memory already being allocated on all sockets,
and thus was failing because calling rte_malloc could trigger memory
hotplug event and allocate memory where there was none before.
Fix it to instead report availability of memory on specific sockets
by attempting to allocate a
For now, this option does nothing, but it will be useful in
dynamic memory allocation down the line. Currently, DPDK stores
all pages as separate files in hugetlbfs. This option will allow
storing all pages in one file (one file per socket, per page size).
Signed-off-by: Anatoly Burakov
---
lib/
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/common/malloc_elem.c | 4 ++--
lib/librte_eal/common/malloc_elem.h | 2 +-
lib/librte_eal/common/malloc_heap.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/librte_eal/common/malloc_elem.c
b/lib/librte_eal/common/ma
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/common/malloc_elem.c | 12 ++--
lib/librte_eal/common/malloc_elem.h | 3 +++
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/lib/librte_eal/common/malloc_elem.c
b/lib/librte_eal/common/malloc_elem.c
index 2291ee1..008f5a3
For non-legacy memory init mode, instead of looking at generic
sysfs path, look at sysfs paths pertaining to each NUMA node
for hugepage counts. Note that per-NUMA node path does not
provide information regarding reserved pages, so we might not
get the best info from these paths, but this saves us
This adds a "--legacy-mem" command-line switch. It will be used to
go back to the old memory behavior, one where we can't dynamically
allocate/free memory (the downside), but one where the user can
get physically contiguous memory, like before (the upside).
For now, nothing but the legacy behavior
Signed-off-by: Anatoly Burakov
---
test/test/commands.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/test/test/commands.c b/test/test/commands.c
index cf0b726..6bfdc02 100644
--- a/test/test/commands.c
+++ b/test/test/commands.c
@@ -137,6 +137,8 @@ static void cmd_dump_parsed(void *pars
Down the line, we will need to do everything from the heap as any
alloc or free may trigger alloc/free OS memory, which would involve
growing/shrinking heap.
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/common/malloc_elem.c | 16 ++--
lib/librte_eal/common/malloc_heap.c | 38 +++
As we are preparing for dynamic memory allocation, we need to be
able to handle holes in our malloc heap, hence we're switching to
doubly linked list, and prepare infrastructure to support it.
Since our heap is now aware where are our first and last elements,
there is no longer any need to have a
This patchset introduces dynamic memory allocation for DPDK (aka memory
hotplug). Based upon RFC submitted in December [1].
Dependencies (to be applied in specified order):
- IPC bugfixes patchset [2]
- IPC improvements patchset [3]
- IPC asynchronous request API patch [4]
- Function to return num
Move get_virtual_area out of linuxapp EAL memory and make it
common to EAL, so that other code could reserve virtual areas
as well.
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/common/eal_common_memory.c | 101 ++
lib/librte_eal/common/eal_private.h | 33 +++
This API is similar to the blocking API that is already present,
but reply will be received in a separate callback by the caller.
Under the hood, we create a separate thread to deal with replies to
asynchronous requests, that will just wait to be notified by the
main thread, or woken up on a timer
Signed-off-by: Anatoly Burakov
---
Notes:
v5: remove lock files, leaving only socket paths code
v4: replace lock files with init files
lib/librte_eal/common/eal_common_proc.c | 48 -
1 file changed, 23 insertions(+), 25 deletions(-)
diff --git a/lib
This is an assortment of loosely related improvements to IPC, mostly
related to handling corner cases and avoiding race conditions.
Main addition is an attempt to avoid undefined behavior when receiving
messages while secondary process is initializing. It is assumed that
once callback is registere
If we receive messages that don't have a callback registered for
them, and we haven't finished initialization yet, it can be reasonably
inferred that we shouldn't have gotten the message in the first
place. Therefore, send requester a special message telling them to
ignore response to this request,
Currently, primary process initialization is finalized by setting
the RTE_MAGIC value in the shared config. However, it is not
possible to check whether secondary process initialization has
completed. Add such a value to internal config.
Signed-off-by: Anatoly Burakov
---
Notes:
v4: make ini
When sending IPC messages, prevent new sockets from initializing.
Signed-off-by: Anatoly Burakov
---
Notes:
v5: removed init files introduced in v4
v4: fixed resource leaks and added support for init files
introduced in v4 series
lib/librte_eal/common/eal_common_proc.c | 5
Currently, filter value is hardcoded and disconnected from actual
value returned by eal_mp_socket_path(). Fix this to generate filter
value by deriving it from eal_mp_socket_path() instead.
Signed-off-by: Anatoly Burakov
Acked-by: Jianfeng Tan
---
Notes:
v5: removed init files
v4:
Signed-off-by: Anatoly Burakov
---
Notes:
v4: add this patch
lib/librte_eal/common/eal_common_proc.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_proc.c
b/lib/librte_eal/common/eal_common_proc.c
index c6fef75..fe27
> > Can we add a compile warning for adding new rte_panic's into code? It's
a
> > > nice tool while debugging, but it probably shouldn't be in any new
> > > production code.
>
> Yes could be nice to automatically detect it in drivers/ or lib/
> directories.
>
How do we apply a warning only to new
> > maybe we should keep the callback patch until all the remains are gone.
>
> Why introducing a new API for a temporary solution?
> It has always been like that, so the remaining occurences could wait
> one more release, isn't it?
>
> Yes.
I guess I am over excited to get rid of my local changes
On 3/7/2018 1:41 PM, Kovacevic, Marko wrote:
>
>
>> -Original Message-
>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Alejandro Lucero
>> Sent: Thursday, February 22, 2018 12:16 PM
>> To: dev@dpdk.org
>> Cc: sta...@dpdk.org
>> Subject: [dpdk-dev] [PATCH] doc: fixing grammar
>>
>>
On 07-Mar-18 3:27 PM, Nélio Laranjeiro wrote:
Hi Anatoly,
I am trying to run some test with this series, but it seems to be based
on some other commits of yours. I have already identified the following
one [1] it seems I am missing some others.
It is possible to have a list of commits to apply
On 07-Mar-18 3:27 PM, Nélio Laranjeiro wrote:
Hi Anatoly,
I am trying to run some test with this series, but it seems to be based
on some other commits of yours. I have already identified the following
one [1] it seems I am missing some others.
It is possible to have a list of commits to apply
Hi Anatoly,
I am trying to run some test with this series, but it seems to be based
on some other commits of yours. I have already identified the following
one [1] it seems I am missing some others.
It is possible to have a list of commits to apply on the current master
branch [2] before this ser
On 2/27/2018 9:38 AM, Ananyev, Konstantin wrote:
>
>
>> -Original Message-
>> From: Awal, Mohammad Abdul
>> Sent: Tuesday, February 27, 2018 8:58 AM
>> To: tho...@monjalon.net
>> Cc: rke...@gmail.com; dev@dpdk.org; Ananyev, Konstantin
>> ; Awal, Mohammad Abdul
>>
>> Subject: [PATCH v2]
07/03/2018 14:23, Arnon Warshavsky:
> >
> > Can we add a compile warning for adding new rte_panic's into code? It's a
> > nice tool while debugging, but it probably shouldn't be in any new
> > production code.
Yes could be nice to automatically detect it in drivers/ or lib/ directories.
> I thou
07/03/2018 12:02, Arnon Warshavsky:
> > > Can this really go into current release without deprecation notices?
> >
> > If such an exception is done, it must be approved by the technical board.
> > We need to check few criterias:
> > - which functions need to be changed
> > - how the
Hi all,
Here is a new stable release:
http://fast.dpdk.org/rel/dpdk-16.11.5.tar.xz
The git tree is at:
http://dpdk.org/browse/dpdk-stable/
Apologies for the delays of a few days, but some extra time was necessary
to sort through the regression tests results.
Luca Boccassi
---
On 3/2/2018 4:41 PM, Anatoly Burakov wrote:
Unlocking the action list before sending message and locking it
again aftterwards introduces a window where a response might
Typo: afterwards
arrive before we have a chance to start waiting on a condition,
resulting in timeouts on valid messages.
On 04-Mar-18 3:30 PM, Jianfeng Tan wrote:
To scan the vdevs in primary, we send request to primary process
to obtain the names for vdevs.
Only the name is shared from the primary. In probe(), the device
driver is supposed to locate (or request more) the detail
information from the primary.
Sign
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Alejandro Lucero
> Sent: Thursday, February 22, 2018 12:16 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: fixing grammar
>
> My english is far worse than those from the marketing t
VLAN strip is a per queue offloading in PF. With this patch
it can be enabled or disabled on any Rx queue in PF.
Signed-off-by: Wei Dai
---
drivers/net/ixgbe/ixgbe_ethdev.c | 109 +--
drivers/net/ixgbe/ixgbe_ethdev.h | 4 +-
drivers/net/ixgbe/ixgbe_pf.c
Ethdev Rx offloads API has changed since:
commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API")
This commit support the new Rx offloads API.
Signed-off-by: Wei Dai
---
drivers/net/ixgbe/ixgbe_ethdev.c | 93 +
drivers/net/ixgbe/ixgbe_ipsec.c | 8 +-
This patch set adds support of per queue VLAN strip offloading
in ixgbe PF and VF.
This patch support new offloads API in ixgbe PF and VF.
---
v2: improve error checking
Wei Dai (4):
net/ixgbe: support VLAN strip per queue offloading in PF
net/ixgbe: support VLAN strip per queue offloading in
Ethdev Tx offloads API has changed since:
commit cba7f53b717d ("ethdev: introduce Tx queue offloads API")
This commit support the new Tx offloads API.
Signed-off-by: Wei Dai
---
drivers/net/ixgbe/ixgbe_ethdev.c | 56 +--
drivers/net/ixgbe/ixgbe_ipsec.c | 5 ++-
drivers/
VLAN strip is a per queue offloading in VF. With this patch
it can be enabled or disabled on any Rx queue in VF.
Signed-off-by: Wei Dai
---
drivers/net/ixgbe/ixgbe_ethdev.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/
>
> Can we add a compile warning for adding new rte_panic's into code? It's a
> nice tool while debugging, but it probably shouldn't be in any new
> production code.
>
I thought about renaming the current function and calls to something like
deprecated_rte_panic()
, and keep the old API with __rte
On 2/26/2018 6:38 PM, Patil, Harish wrote:
> -Original Message-
> From: Pascal Mazon
> Date: Monday, February 26, 2018 at 12:01 AM
> To: "dev@dpdk.org" , "Mody, Rasesh"
> , Harish Patil , "Shaikh,
> Shahed"
> Cc: "pascal.ma...@6wind.com" , "sta...@dpdk.org"
>
> Subject: [PATCH v2] net/qe
Hi Fiona
>-Original Message-
>From: Trahe, Fiona [mailto:fiona.tr...@intel.com]
>Sent: 09 February 2018 23:43
>To: dev@dpdk.org; Athreya, Narayana Prasad
>; Murthy, Nidadavolu
>; Sahu, Sunila ; Gupta,
>Ashish ; Verma,
>Shally ; Doherty, Declan ;
>Keating, Brian A ;
>Griffin, John
>Cc:
1 - 100 of 126 matches
Mail list logo
