Suppose we have 2 virtio devices for a VM, with only the first one,
virtio0, binding to igb_uio. Start a primary DPDK process, driving
only virtio0. Then start a secondary DPDK process, it encounters
segfault at eth_virtio_dev_init() because hw is NULL, when trying
to initialize the 2nd virtio devi
Hi Jianfeng,
> -Original Message-
> From: Tan, Jianfeng
> Sent: Sunday, July 2, 2017 6:20 PM
> To: Hu, Jiayu ; dev@dpdk.org
> Cc: Ananyev, Konstantin ;
> step...@networkplumber.org; y...@fridaylinux.org; Wu, Jingjing
> ; Yao, Lei A ; Bie, Tiwei
>
> Subject: Re: [PATCH v10 1/3] lib: add Ge
-Original Message-
>
> From: Harry van Haaren
> > Adi a new entry in the sample app user-guides,
> which details the working of the eventdev_pipeline_sw.
>
> Signed-off-by: Harry van Haaren
> Signed-off-by: David Hunt
> ---
> doc/guides/sample_app_ug/eventdev_pipeline_sw.rst | 190
>
Hi Jianfeng,
> -Original Message-
> From: Tan, Jianfeng
> Sent: Sunday, July 2, 2017 6:20 PM
> To: Hu, Jiayu ; dev@dpdk.org
> Cc: Ananyev, Konstantin ;
> step...@networkplumber.org; y...@fridaylinux.org; Wu, Jingjing
> ; Yao, Lei A ; Bie, Tiwei
>
> Subject: Re: [PATCH v10 2/3] lib/gro: ad
-Original Message-
>
> From: Harry van Haaren
>
> This commit adds a sample app for the eventdev library.
> The app has been tested with DPDK 17.05-rc2, hence this
> release (or later) is recommended.
>
> The sample app showcases a pipeline processing use-case,
> with event scheduling a
Hello,
With the most recent master tree we have:
git grep rte_ctrlmbuf_init
doc/guides/prog_guide/mbuf_lib.rst:The rte_pktmbuf_init() and
rte_ctrlmbuf_init() functions initialize some fields in the mbuf
structure that
lib/librte_mbuf/rte_mbuf.c:rte_ctrlmbuf_init(struct rte_mempool *mp,
lib/librte
VF performance is limited by the kernel PCI extended tag setting.
Update the document to explain the known issue and the workaround.
Signed-off-by: Qi Zhang
---
v2:
- follow number list format.
- improve the comments.
doc/guides/nics/i40e.rst | 27 +++
1 file changed, 2
Since now the private session data is initialized after
the session pool is created, there is no need to keep
this PMD function.
Signed-off-by: Pablo de Lara
---
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 8
lib/librte_cryptodev/rte_cryptodev_pmd.h| 16
2 files
Modified cryptodev library section in Programmer's Guide,
with the recent changes in the crypto sessions.
Signed-off-by: Slawomir Mrozowicz
Signed-off-by: Pablo de Lara
---
doc/guides/prog_guide/cryptodev_lib.rst | 59 ++--
doc/guides/prog_guide/img/cryptodev_sym_sess.svg | 418 ++
The session mempool pointer is needed in each queue pair,
if session-less operations are being handled.
Therefore, the API is changed to accept this parameter,
as the session mempool is created outside the
device configuration function, similar to what ethdev
does with the rx queues.
Signed-off-by
From: Slawomir Mrozowicz
Mempool pointer can be obtained from the object itself,
which means that it is not required to actually store the pointer
in the session.
Signed-off-by: Slawomir Mrozowicz
Signed-off-by: Pablo de Lara
---
doc/guides/rel_notes/release_17_08.rst | 1 +
lib/librte_crypto
From: Slawomir Mrozowicz
Change crypto device's session management to make it
device independent and simplify architecture when session
is intended to be used on more than one device.
Sessions private data is agnostic to underlying device
by adding an indirection in the sessions private data
usi
From: Slawomir Mrozowicz
Device id is going to be removed from session,
as the session will be device independent.
Therefore, the functions that attach/dettach a session
to a queue pair need to be updated, to accept the device id
as a parameter, apart from the queue pair id and the session.
Sign
From: Slawomir Mrozowicz
Device id is necessary in the crypto session,
as it was only used for the functions that attach/detach
a session to a queue pair.
Since the session is not going to be attached to a device
anymore, this is field is no longer necessary.
Signed-off-by: Slawomir Mrozowicz
From: Slawomir Mrozowicz
Since crypto session will not be attached to a specific
device or driver, the field driver_id is not required
anymore (only used to check that a session was being
handled by the right device).
Signed-off-by: Slawomir Mrozowicz
Signed-off-by: Pablo de Lara
---
doc/guid
Cryptodev session structure was a duplication of the
cryptodev symmetric structure.
It was used by some PMDs that should use the symmetric
structure instead.
Since this structure was internal, there is no deprecation
notice required.
Signed-off-by: Pablo de Lara
---
drivers/crypto/kasumi/rte_ka
Currently, the cryptodev library requires the session mempools
to be created inside each device.
This can be a waste of memory, as several devices with the same driver
could be using the same session.
This patchset makes changes in the library to allow session to contain multiple
driver private da
Prior to removing the session pool creation from cryptodev
configure function, session init function needs to be
separated from the pool creation.
Signed-off-by: Pablo de Lara
---
lib/librte_cryptodev/rte_cryptodev.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git
From: Slawomir Mrozowicz
Provide a function to get the private session size
of any crypto device (specifically, to its crypto driver).
This will be useful once the session mempool is created
outside the library.
Signed-off-by: Slawomir Mrozowicz
Signed-off-by: Pablo de Lara
---
lib/librte_cr
From: Slawomir Mrozowicz
Instead of creating the session mempool while configuring
the crypto device, apps will create the mempool themselves.
This way, it gives flexibility to the user to have a single
mempool for all devices (as long as the objects are big
enough to contain the biggest private
> -Original Message-
> From: akhil.go...@nxp.com [mailto:akhil.go...@nxp.com]
> Sent: Thursday, June 29, 2017 9:49 PM
> To: dev@dpdk.org
> Cc: hemant.agra...@nxp.com; De Lara Guarch, Pablo
> ; Doherty, Declan
> ; Akhil Goyal
> Subject: [PATCH 0/5] crypto/dpaa2_sec optimization and featur
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Harry van Haaren
> Sent: Sunday, July 2, 2017 10:35 PM
> To: dev@dpdk.org
> Cc: jerin.ja...@caviumnetworks.com; tho...@monjalon.net; Wiles, Keith
> ; Richardson, Bruce ;
> Van Haaren, Harry
> Subject: [dpdk-dev]
Add a section describing the fundamental concepts behind service
cores. Where service cores originate from, and how to enable services.
The release notes for 17.08 are updated, with an introductory paragraph
on the service cores concept. Finally the Eventdev SW PMD documentation
is amended to refle
Sign-up to be the maintainer of public header files and
implementation of the service-cores infrastructure.
Signed-off-by: Harry van Haaren
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 00351ff..2e5081c 100644
--- a/MAINTAINERS
+++ b/MA
This commit shows how easy it is to enable a specific
DPDK component with a service callback, in order to get
CPU cycles for it.
The beauty of this method is that the service is unaware
of how much CPU time it is getting - the application can
decide how to split and slice cores and map them to the
Add a bunch of unit tests, to ensure that the service
core functions are operating as expected.
As part of these tests a dummy service is registered which
allows identifying if a service callback has been invoked
by using the CPU tick counter. This allows identifying if
functions to start and stop
Add logic for parsing a coremask from EAL, which allows
the application to be unaware of the cores being taken from
its coremask.
Signed-off-by: Harry van Haaren
Acked-by: Jerin Jacob
---
v2:
- Remove printf() (Jerin)
- Remove commented code (Jerin)
- simplified core tracking, no requirement
Add header files, update .map files with new service
functions, and add the service header to the doxygen
for building.
This service header API allows DPDK to use services as
a concept of something that requires CPU cycles. An example
is a PMD that runs in software to schedule events, where a
hard
This commit shows the changes required in rte_eal_init()
to transparently launch the service threads. The threads
are launched into the service worker functions here because
after rte_eal_init() the application is not gauranteed to
call any other DPDK API.
As the registration of services happens a
This patchset introduces service cores to DPDK. A service core
is an lcore that performs functions to abstract away details of
differences in environment of the application.
An example is using the eventdev API, where either a software or hardware
PMD performs scheduling. In the case of the softwa
> -Original Message-
> From: Yigit, Ferruh
> Sent: Thursday, June 22, 2017 8:03 PM
> To: Mcnamara, John
> Cc: dev@dpdk.org; Yigit, Ferruh ; Thomas Monjalon
> ; Olivier Matz
> Subject: [PATCH v2] doc: document NIC features
>
> Document NIC features, add more information about them and a
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, June 30, 2017 5:51 PM
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; Stephen Hemminger
> ; Richardson, Bruce
> ; Burakov, Anatoly
> Subject: [dpdk-dev] [PATCH v9 06/20] doc: add ethtool lib
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, June 30, 2017 5:51 PM
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; Stephen Hemminger
> ; Richardson, Bruce
> ; Burakov, Anatoly
> Subject: [dpdk-dev] [PATCH v9 07/20] doc: update ethtool
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Pablo de Lara
> Sent: Friday, June 30, 2017 6:10 PM
> To: Doherty, Declan ;
> zbigniew.bo...@caviumnetworks.com; jerin.ja...@caviumnetworks.com;
> akhil.go...@nxp.com; hemant.agra...@nxp.com; Trahe, Fiona
> ; Grif
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, June 30, 2017 5:52 PM
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; Stephen Hemminger
> ; Richardson, Bruce
> ; Burakov, Anatoly
> Subject: [dpdk-dev] [PATCH v9 19/20] doc: add control int
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Sunday, July 2, 2017 6:49 PM
> To: Mcnamara, John
> Cc: dev@dpdk.org; Rao, Nikhil
> Subject: Re: [dpdk-dev] [PATCH] ethdev: fix a typo in eth device API doc
>
> 30/06/2017 16:47, Mcnamara, John:
> > >
> > >
> -Original Message-
> From: Zhang, Qi Z
> Sent: Sunday, July 2, 2017 1:07 PM
> To: Mcnamara, John ; Wu, Jingjing
>
> Cc: Zhang, Helin ; dev@dpdk.org; Zhang, Qi Z
>
> Subject: [PATCH] doc: add knowing issue for i40e VF performance
>
> VF performance is limited by some kernel PCI settin
30/06/2017 17:39, Declan Doherty:
> On 30/06/17 08:56, RongQiang Xie wrote:
> > In function cmd_show_bonding_config_parsed() used number represent
> > the bond type,in order more detailed,add bond type description
> > otherwise we may confused about the number type.
> > And also,the primary port ju
30/06/2017 16:47, Mcnamara, John:
> >
> > This patch fixes a typo in the eth device API doc, device config. not
> > stored between calls to rte_eth_dev_start/stop() should be restored before
> > a call to rte_eth_dev_start() instead of after a call to
> > rte_eth_dev_start().
> >
> > Signed-off-b
> > Signed-off-by: Yong Wang
>
> Acked-by: John McNamara
Applied, thanks
> > Signed-off-by: Xingyou Chen
>
> Acked-by: John McNamara
Applied, thanks
> > Signed-off-by: Harrison McCullough
>
> Acked-by: John McNamara
Applied, thanks
Now that all the structures/functions for AEAD algorithms
are in place, migrate the two supported algorithms
AES-GCM and AES-CCM to these, instead of using
cipher and authentication parameters.
Signed-off-by: Pablo de Lara
Acked-by: Akhil Goyal
Acked-by: Fiona Trahe
---
doc/guides/sample_app_u
Since there is a new operation type (AEAD), add parameters
for this in the application.
Signed-off-by: Pablo de Lara
Acked-by: Akhil Goyal
Acked-by: Fiona Trahe
---
doc/guides/sample_app_ug/l2_forward_crypto.rst | 24 +-
examples/l2fwd-crypto/main.c | 388 +++
Now that AAD is only used in AEAD algorithms,
there is no need to keep AAD in the authentication
structure.
Signed-off-by: Pablo de Lara
Acked-by: Akhil Goyal
Acked-by: Fiona Trahe
---
app/test-crypto-perf/cperf_ops.c | 2 --
doc/guides/prog_guide/cryptodev_lib.rst | 6 --
doc/g
Some extra functions have been created to avoid
too many nested conditionals.
Signed-off-by: Pablo de Lara
Acked-by: Akhil Goyal
Acked-by: Fiona Trahe
---
examples/l2fwd-crypto/main.c | 125 ++-
1 file changed, 77 insertions(+), 48 deletions(-)
diff --g
Since there is a new operation type (AEAD), add parameters
for this in the application.
Signed-off-by: Pablo de Lara
Acked-by: Akhil Goyal
Acked-by: Fiona Trahe
---
app/test-crypto-perf/cperf_ops.c | 138 ++-
app/test-crypto-perf/cperf_options.h
Since there is a new operation type (AEAD), add parameters
for this in the application.
Signed-off-by: Pablo de Lara
Acked-by: Akhil Goyal
Acked-by: Fiona Trahe
---
doc/guides/sample_app_ug/ipsec_secgw.rst | 32 +++--
examples/ipsec-secgw/ipsec.h | 1 +
examples/ipsec-secgw/
AEAD operation parameters can be set in the new
aead structure, in the crypto operation.
This structure is within a union with the cipher
and authentication parameters, since operations can be:
- AEAD: using the aead structure
- Cipher only: using only the cipher structure
- Auth only: using only
AEAD algorithms such as AES-GCM needed to be
used as a concatenation of a cipher transform and
an authentication transform.
Instead, a new transform and functions to handle it
are created to support these kind of algorithms,
making their use easier.
Signed-off-by: Pablo de Lara
Acked-by: Akhil G
AES-GMAC is an authentication algorithm, based on AES-GCM
without encryption. To simplify its usage, now it can be used
setting the authentication parameters, without requiring
to concatenate a ciphering transform.
Therefore, it is not required to set AAD, but authentication
data length and offset
Digest length was duplicated in the authentication transform
and the crypto operation structures.
Since digest length is not expected to change in a same
session, it is removed from the crypto operation.
Also, the length has been shrunk to 16 bits,
which should be sufficient for any digest.
Sign
For wireless algorithms (SNOW3G, KASUMI, ZUC),
the IV for the authentication algorithms (F9, UIA2 and EIA3)
was taken from the AAD parameter, as there was no IV parameter
in the authentication structure.
Now that IV is available for all algorithms, there is need
to keep doing this, so AAD is not u
Since IV parameters (offset and length) should not
change for operations in the same session, these parameters
are moved to the crypto transform structure, so they will
be stored in the sessions.
Signed-off-by: Pablo de Lara
Acked-by: Akhil Goyal
Acked-by: Fiona Trahe
---
app/test-crypto-perf/
Additional authenticated data (AAD) information was duplicated
in the authentication transform and in the crypto
operation structures.
Since AAD length is not meant to be changed in a same session,
it is removed from the crypto operation structure.
Signed-off-by: Pablo de Lara
Acked-by: Akhil Go
Since IV now is copied after the crypto operation, in
its private size, IV can be passed only with offset
and length.
Signed-off-by: Pablo de Lara
Acked-by: Akhil Goyal
Acked-by: Fiona Trahe
---
app/test-crypto-perf/cperf_ops.c| 49 +++--
doc/guides/prog_guide/cryptodev_li
Authentication algorithms, such as AES-GMAC or the wireless
algorithms (like SNOW3G) use IV, like cipher algorithms.
So far, AES-GMAC has used the IV from the cipher structure,
and the wireless algorithms have used the AAD field,
which is not technically correct.
Therefore, authentication IV param
Usually, IV will change for each crypto operation.
Therefore, instead of pointing at the same location,
IV is copied after each crypto operation.
This will let the IV to be passed as an offset from
the beginning of the crypto operation, instead of
a pointer.
Signed-off-by: Pablo de Lara
Acked-by
Usually, IV will change for each crypto operation.
Therefore, instead of pointing at the same location,
IV is copied after each crypto operation.
This will let the IV to be passed as an offset from
the beginning of the crypto operation, instead of
a pointer.
Signed-off-by: Pablo de Lara
Acked-by
Usually, IV will change for each crypto operation.
Therefore, instead of pointing at the same location,
IV is copied after each crypto operation.
This will let the IV to be passed as an offset from
the beginning of the crypto operation, instead of
a pointer.
Signed-off-by: Pablo de Lara
Acked-by
Usually, IV will change for each crypto operation.
Therefore, instead of pointing at the same location,
IV is copied after each crypto operation.
This will let the IV to be passed as an offset from
the beginning of the crypto operation, instead of
a pointer.
Signed-off-by: Pablo de Lara
Acked-by
In order to facilitate the access to the private data,
after the crypto operation, two new macros have been
implemented:
- rte_crypto_op_ctod_offset(c,t,o), which returns a pointer
to "o" bytes after the start of the crypto operation
(rte_crypto_op)
- rte_crypto_op_ctophys_offset(c, o), which
Usually, IV will change for each crypto operation.
Therefore, instead of pointing at the same location,
IV is copied after each crypto operation.
This will let the IV to be passed as an offset from
the beginning of the crypto operation, instead of
a pointer.
Signed-off-by: Pablo de Lara
Acked-by
Instead of storing a pointer to operation specific parameters,
such as symmetric crypto parameters, use a zero-length array,
to mark that these parameters will be stored after the
generic crypto operation structure, which was already assumed
in the code, reducing the memory footprint of the crypto
rte_crypto_op and rte_crypto_sym_op structures
were marked as cache aligned.
However, since these structures are always initialized
in a mempool, this alignment is useless, since the mempool
forces the alignment of its objects.
Signed-off-by: Pablo de Lara
Acked-by: Akhil Goyal
Acked-by: Fiona T
Storing a pointer to the user data is unnecessary,
since user can store additional data, after the crypto operation.
Signed-off-by: Pablo de Lara
Acked-by: Akhil Goyal
Acked-by: Fiona Trahe
---
app/test-crypto-perf/cperf_test_latency.c | 47 ---
doc/guides/prog_guid
Instead of storing some crypto operation flags,
such as operation status, as enumerations,
store them as uint8_t, for memory efficiency.
Also, reserve extra 5 bytes in the crypto operation,
for future additions.
Signed-off-by: Pablo de Lara
Acked-by: Akhil Goyal
Acked-by: Fiona Trahe
---
doc/
This patchset attempts to correct and improve the current crypto operation
(rte_crypto_op) and symmetric crypto operation (rte_crypto_sym_op) structures,
shrinking their sizes to fit both structures into two 64-byte cache lines
(with extra space for the IV and other user data) as one of the goals.
Session type (operation with or without session) is not
something specific to symmetric operations.
Therefore, the variable is moved to the generic crypto operation
structure.
Signed-off-by: Pablo de Lara
Acked-by: Akhil Goyal
Acked-by: Fiona Trahe
---
doc/guides/prog_guide/cryptodev_lib.rst
This commit adds support for the flow API RSS action with the following
limitations:
- Only supported when isolated mode is enabled.
- The number of queues specified by the action (rte_flow_action_rss.num)
must be a power of two.
- Each queue index can be specified at most once in the config
A special "parent" queue must be allocated in addition to a group of
standard Rx queues for RSS to work. This is done automatically outside of
isolated mode by the PMD when applications request several Rx queues.
Since each configured flow rule with the RSS action may target a different
set of que
The user must request isolated mode before device configuration,
the default RSS ring isn't created in this case.
Signed-off-by: Vasily Philipov
---
drivers/net/mlx4/mlx4.c | 58 +++-
drivers/net/mlx4/mlx4.h | 1 +
drivers/net/mlx4/mlx4_flow.c |
Providing this parameter requests flow API isolated mode on all ports at
initialization time. It ensures all traffic is received through the
configured flow rules only (see flow command).
Ports that do not support this mode are automatically discarded.
Signed-off-by: Vasily Philipov
---
app/tes
-Original Message-
> Date: Fri, 30 Jun 2017 14:51:13 +0100
> From: David Hunt
> To: dev@dpdk.org
> CC: jerin.ja...@caviumnetworks.com, harry.van.haa...@intel.com
> Subject: [PATCH v5 3/3] doc: add eventdev library to programmers guide
> X-Mailer: git-send-email 2.7.4
>
> From: Harry van H
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Trahe, Fiona
> Sent: Friday, June 30, 2017 5:36 PM
> To: Gonzalez Monroy, Sergio ;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] app/crypto-perf: set crypto op pool cache
>
>
>
> > -Original Message-
VF performance is limited by some kernel PCI setting.
Update the document to explain the knowing issue and
work around solution.
Signed-off-by: Qi Zhang
---
doc/guides/nics/i40e.rst | 24
1 file changed, 24 insertions(+)
diff --git a/doc/guides/nics/i40e.rst b/doc/guide
> -Original Message-
> From: Trahe, Fiona
> Sent: Friday, June 30, 2017 5:13 PM
> To: Gonzalez Monroy, Sergio ;
> dev@dpdk.org
> Cc: De Lara Guarch, Pablo
> Subject: RE: [dpdk-dev] [PATCH] app/crypto-perf: use
> rte_mempool_put_bulk
>
>
>
> > -Original Message-
> > From: dev [
> -Original Message-
> From: stable [mailto:stable-boun...@dpdk.org] On Behalf Of Trahe, Fiona
> Sent: Friday, June 30, 2017 5:35 PM
> To: Gonzalez Monroy, Sergio ;
> dev@dpdk.org; sta...@dpdk.org
> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] app/crypto-perf: fix digest
> data for chain
Intel IPSec Multi-buffer library v0.46 has been released,
which among other features, adds support for 12-byte IVs
for AES Counter mode (AES-CTR), since IPSec requires only
12 bytes from the user, which are appended 4 extra bytes,
set to 1 always.
There are no major changes made in the PMD, just d
IPSec Multi-buffer library v0.46 has been released,
which includes, among othe features, support for 12-byte IV,
for AES-CTR, keeping also the previous 16-byte IV,
for backward compatibility reasons.
Signed-off-by: Pablo de Lara
---
doc/guides/cryptodevs/aesni_mb.rst | 19 +++
AESNI MB PMD supports now 12-byte IVs, so some tests
are added to check that, apart from the ones with 16-byte IVs,
as this is still compatible.
Signed-off-by: Pablo de Lara
---
test/test/test_cryptodev_aes_test_vectors.h | 186
1 file changed, 186 insertions(+)
dif
> -Original Message-
> From: Gonzalez Monroy, Sergio
> Sent: Friday, June 30, 2017 2:52 PM
> To: De Lara Guarch, Pablo ; Doherty,
> Declan
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/2] crypto/aesni_mb: support IPSec Multi-
> buffer lib v0.46
>
> On 28/06/2017 12:48, Pablo de
On 7/1/2017 7:08 PM, Jiayu Hu wrote:
Generic Receive Offload (GRO) is a widely used SW-based offloading
technique to reduce per-packet processing overhead. It gains
performance by reassembling small packets into large ones. This
patchset is to support GRO in DPDK. To support GRO, this patch
imp
On 7/1/2017 7:08 PM, Jiayu Hu wrote:
In this patch, we introduce five APIs to support TCP/IPv4 GRO.
- gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used
to merge packets.
- gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table.
- gro_tcp4_tbl_timeout_fl
84 matches
Mail list logo
