Re: [dpdk-dev] [PATCH 03/13] rte_ether: set PKT_RX_VLAN_STRIPPED in rte_vlan_strip()
Hi Thomas,
On Sun, 30 Apr 2017 17:58:45 +0200, Thomas Monjalon wrote:
> 09/02/2017 16:56, Olivier MATZ:
> > Hi,
> >
> > On Mon, 30 Jan 2017 10:54:08 +0100, Thomas Monjalon
> > wrote:
> > > It is fixing the introduction of the new flag PKT_RX_VLAN_STRIPPED.
> > >
> > > Fixes: b37b528d957c ("mbuf: add new Rx flags for stripped VLAN")
> > >
> > > This patch is applying the flag to the software emulation case
> > > (currently only for virtio).
> > > So the comment of this flag should be changed:
> > >
> > > /**
> > > * A vlan has been stripped by the hardware and its tci is saved in
> > > * mbuf->vlan_tci. This can only happen if vlan stripping is enabled
> > > * in the RX configuration of the PMD.
> > > */
> > > #define PKT_RX_VLAN_STRIPPED (1ULL <<
> > > 6)
> > >
> > >
> > >
> > > > Signed-off-by: Michał Mirosław
> > > [...]
> > > > --- a/lib/librte_net/rte_ether.h
> > > > +++ b/lib/librte_net/rte_ether.h
> > > > @@ -357,7 +357,7 @@ static inline int rte_vlan_strip(struct
> > > > rte_mbuf *m) return -1;
> > > >
> > > > struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 1);
> > > > - m->ol_flags |= PKT_RX_VLAN_PKT;
> > > > + m->ol_flags |= PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED;
> > > > m->vlan_tci = rte_be_to_cpu_16(vh->vlan_tci);
> > > >
> > > > /* Copy ether header over rather than moving whole packet
> > > > */
> > >
> > > I think this flag should also be removed in the function
> > > rte_vlan_insert().
> >
> > Agree with Thomas, I think rte_vlan_insert() should be updated too.
> >
> > But I don't think the comment of the mbuf flag should be changed:
> > "stripped by the hardware" is a bit ambiguous for virtual drivers, but
> > we can understand that for virtual drivers the same work is done in
> > software.
>
> No more comment?
>
> Olivier, the author is not replying.
> I think we should have updated the patch ourself.
> How risky it is for 17.05?
> Should it wait for 17.08?
I don't feel it's too risky for 17.05.
It's used in virtio and af_packet drivers, only when using vlan offload.
FYI, for 17.08, I plan to put the mbuf vlan flag subject on the table
again: when I introduced the new flag VLAN_STRIPPED, we acted that another
flag or pkt_type had to be introduced, but it was not really finished.
Olivier
Re: [dpdk-dev] [PATCH] [RFC] cryptodev: crypto operation restructuring
On 04/05/2017 07:09, Akhil Goyal wrote:
Hi Sergio,
On 5/3/2017 7:48 PM, Sergio Gonzalez Monroy wrote:
On 03/05/2017 12:01, Akhil Goyal wrote:
Hi Pablo,
On 4/28/2017 11:33 PM, Pablo de Lara wrote:
This is a proposal 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 as
one of the goals.
The following changes are proposed:
In rte_crypto_op:
- Move session type (with session/sessionless) from symmetric op to
crypto op,
as this could be used for other types
- Combine operation type, operation status and session type into a
64-bit flag (each one taking 1 byte),
instead of having enums taking 4 bytes each
[Akhil] wouldn't this be a problem? Bit fields create endianness
issues. Can we have uint8_t for each of the field.
Sure, as it is proposed it would be the same as having 3 uint8_t fields.
The idea was to possibly compact those fields (ie. we do not need 8 bits
for sess_type) to make better use of the bits and add asym fields there
if needed.
I don't think bitfields would be a problem in this case. Agree, we
should not use both bitmask and bitfields, but we would use just
bitfields.
Can you elaborate on the issue you see?
Regards,
Sergio
The problem will come when we run on systems with different
endianness. The bit field positioning will be different for LE and BE.
It would be like in LE
uint64_t type:8;
uint64_t status:8;
uint64_t sess_type:8;
uint64_t reserved:40;
and on BE it would be
uint64_t reserved:40;
uint64_t sess_type:8;
uint64_t status:8;
uint64_t type:8;
So it would be better to use uint8_t for each of the field.
Understood, but why is that an issue? Those fields are used by
application code and PMD, same system.
Do you have a use case where you are offloading crypto ops to a
different arch/system?
Sergio
- Remove opaque data from crypto operation, as private data can be
allocated
just after the symmetric (or other type) crypto operation
- Modify symmetric operation pointer to zero-array, as the symmetric
op should be always after the crypto operation
In rte_crypto_sym_xform:
- Remove AAD length from sym_xform (will be taken from operation only)
- Add IV length in sym_xform, so this length will be fixed for all
the operations in a session
A much needed change. This would remove hard codings for iv length
while configuring sessions.
In rte_crypto_sym_op:
- Separate IV from cipher structure in symmetric crypto operation, as
it is also used in authentication, for some algorithms
- Remove IV pointer and length from sym crypto op, and leave just the
offset (from the beginning of the crypto operation),
as the IV can reside after the crypto operation
- Create union with authentication data and AAD, as these two values
cannot be used at the same time
[Akhil] Does this mean, in case of AEAD, additional authentication
data and auth data are contiguous as we do not have explicit auth data
offset here.
- Remove digest length from sym crypto op, so this length will be
fixed for all the operations in a session
- Add zero-array at the end of sym crypto op to be used to get extra
allocated memory (IV + other user data)
Previous rte_crypto_op (40 bytes) and rte_crypto_sym_op (114 bytes)
structures:
struct rte_crypto_op {
enum rte_crypto_op_type type;
enum rte_crypto_op_status status;
struct rte_mempool *mempool;
phys_addr_t phys_addr;
void *opaque_data;
union {
struct rte_crypto_sym_op *sym;
};
} __rte_cache_aligned;
struct rte_crypto_sym_op {
struct rte_mbuf *m_src;
struct rte_mbuf *m_dst;
enum rte_crypto_sym_op_sess_type sess_type;
RTE_STD_C11
union {
struct rte_cryptodev_sym_session *session;
struct rte_crypto_sym_xform *xform;
};
struct {
struct {
uint32_t offset;
uint32_t length;
} data;
struct {
uint8_t *data;
phys_addr_t phys_addr;
uint16_t length;
} iv;
} cipher;
struct {
struct {
uint32_t offset;
uint32_t length;
} data;
struct {
uint8_t *data;
phys_addr_t phys_addr;
uint16_t length;
} digest; /**< Digest parameters */
struct {
uint8_t *data;
phys_addr_t phys_addr;
uint16_t length;
} aad;
} auth;
} __rte_cache_aligned;
New rte_crypto_op (24 bytes) and rte_crypto_sym_op (72 bytes)
structures:
struct rte_crypto_op {
uint64_t type:
Re: [dpdk-dev] [PATCH] [RFC] cryptodev: crypto operation restructuring
On 5/4/2017 1:01 PM, Sergio Gonzalez Monroy wrote:
On 04/05/2017 07:09, Akhil Goyal wrote:
Hi Sergio,
On 5/3/2017 7:48 PM, Sergio Gonzalez Monroy wrote:
On 03/05/2017 12:01, Akhil Goyal wrote:
Hi Pablo,
On 4/28/2017 11:33 PM, Pablo de Lara wrote:
This is a proposal 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 as
one of the goals.
The following changes are proposed:
In rte_crypto_op:
- Move session type (with session/sessionless) from symmetric op to
crypto op,
as this could be used for other types
- Combine operation type, operation status and session type into a
64-bit flag (each one taking 1 byte),
instead of having enums taking 4 bytes each
[Akhil] wouldn't this be a problem? Bit fields create endianness
issues. Can we have uint8_t for each of the field.
Sure, as it is proposed it would be the same as having 3 uint8_t fields.
The idea was to possibly compact those fields (ie. we do not need 8 bits
for sess_type) to make better use of the bits and add asym fields there
if needed.
I don't think bitfields would be a problem in this case. Agree, we
should not use both bitmask and bitfields, but we would use just
bitfields.
Can you elaborate on the issue you see?
Regards,
Sergio
The problem will come when we run on systems with different
endianness. The bit field positioning will be different for LE and BE.
It would be like in LE
uint64_t type:8;
uint64_t status:8;
uint64_t sess_type:8;
uint64_t reserved:40;
and on BE it would be
uint64_t reserved:40;
uint64_t sess_type:8;
uint64_t status:8;
uint64_t type:8;
So it would be better to use uint8_t for each of the field.
Understood, but why is that an issue? Those fields are used by
application code and PMD, same system.
Do you have a use case where you are offloading crypto ops to a
different arch/system?
Sergio
same application may run on LE or BE machines. So if we use masks for
accessing these fields and take the complete field as uint64_t, then LE
and BE machine would interpret it differently as the code is same.
Akhil
- Remove opaque data from crypto operation, as private data can be
allocated
just after the symmetric (or other type) crypto operation
- Modify symmetric operation pointer to zero-array, as the symmetric
op should be always after the crypto operation
In rte_crypto_sym_xform:
- Remove AAD length from sym_xform (will be taken from operation only)
- Add IV length in sym_xform, so this length will be fixed for all
the operations in a session
A much needed change. This would remove hard codings for iv length
while configuring sessions.
In rte_crypto_sym_op:
- Separate IV from cipher structure in symmetric crypto operation, as
it is also used in authentication, for some algorithms
- Remove IV pointer and length from sym crypto op, and leave just the
offset (from the beginning of the crypto operation),
as the IV can reside after the crypto operation
- Create union with authentication data and AAD, as these two values
cannot be used at the same time
[Akhil] Does this mean, in case of AEAD, additional authentication
data and auth data are contiguous as we do not have explicit auth data
offset here.
- Remove digest length from sym crypto op, so this length will be
fixed for all the operations in a session
- Add zero-array at the end of sym crypto op to be used to get extra
allocated memory (IV + other user data)
Previous rte_crypto_op (40 bytes) and rte_crypto_sym_op (114 bytes)
structures:
struct rte_crypto_op {
enum rte_crypto_op_type type;
enum rte_crypto_op_status status;
struct rte_mempool *mempool;
phys_addr_t phys_addr;
void *opaque_data;
union {
struct rte_crypto_sym_op *sym;
};
} __rte_cache_aligned;
struct rte_crypto_sym_op {
struct rte_mbuf *m_src;
struct rte_mbuf *m_dst;
enum rte_crypto_sym_op_sess_type sess_type;
RTE_STD_C11
union {
struct rte_cryptodev_sym_session *session;
struct rte_crypto_sym_xform *xform;
};
struct {
struct {
uint32_t offset;
uint32_t length;
} data;
struct {
uint8_t *data;
phys_addr_t phys_addr;
uint16_t length;
} iv;
} cipher;
struct {
struct {
uint32_t offset;
uint32_t length;
} data;
struct {
uint8_t *data;
phys_addr_t phys_addr;
uint16_t length;
} digest; /**< Digest parameters */
struct {
uint8_t *data;
Re: [dpdk-dev] [PATCH] [RFC] cryptodev: crypto operation restructuring
On 04/05/2017 08:38, Akhil Goyal wrote:
On 5/4/2017 1:01 PM, Sergio Gonzalez Monroy wrote:
On 04/05/2017 07:09, Akhil Goyal wrote:
Hi Sergio,
On 5/3/2017 7:48 PM, Sergio Gonzalez Monroy wrote:
On 03/05/2017 12:01, Akhil Goyal wrote:
Hi Pablo,
On 4/28/2017 11:33 PM, Pablo de Lara wrote:
This is a proposal 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 as
one of the goals.
The following changes are proposed:
In rte_crypto_op:
- Move session type (with session/sessionless) from symmetric op to
crypto op,
as this could be used for other types
- Combine operation type, operation status and session type into a
64-bit flag (each one taking 1 byte),
instead of having enums taking 4 bytes each
[Akhil] wouldn't this be a problem? Bit fields create endianness
issues. Can we have uint8_t for each of the field.
Sure, as it is proposed it would be the same as having 3 uint8_t
fields.
The idea was to possibly compact those fields (ie. we do not need 8
bits
for sess_type) to make better use of the bits and add asym fields
there
if needed.
I don't think bitfields would be a problem in this case. Agree, we
should not use both bitmask and bitfields, but we would use just
bitfields.
Can you elaborate on the issue you see?
Regards,
Sergio
The problem will come when we run on systems with different
endianness. The bit field positioning will be different for LE and BE.
It would be like in LE
uint64_t type:8;
uint64_t status:8;
uint64_t sess_type:8;
uint64_t reserved:40;
and on BE it would be
uint64_t reserved:40;
uint64_t sess_type:8;
uint64_t status:8;
uint64_t type:8;
So it would be better to use uint8_t for each of the field.
Understood, but why is that an issue? Those fields are used by
application code and PMD, same system.
Do you have a use case where you are offloading crypto ops to a
different arch/system?
Sergio
same application may run on LE or BE machines. So if we use masks for
accessing these fields and take the complete field as uint64_t, then
LE and BE machine would interpret it differently as the code is same.
Right, either you use bitfields or you define macros and work on the
complete uint64_t. The proposal here was to just use bitfields and for
the given use case it would not be an issue while IMHO allowing better
packing and readability than defining each field as a Byte.
Anyway, if you feel strongly against bitfields, we can just define it as
uint8_t as you suggest or single uint64_t with macros.
Sergio
Akhil
- Remove opaque data from crypto operation, as private data can be
allocated
just after the symmetric (or other type) crypto operation
- Modify symmetric operation pointer to zero-array, as the symmetric
op should be always after the crypto operation
In rte_crypto_sym_xform:
- Remove AAD length from sym_xform (will be taken from operation
only)
- Add IV length in sym_xform, so this length will be fixed for all
the operations in a session
A much needed change. This would remove hard codings for iv length
while configuring sessions.
In rte_crypto_sym_op:
- Separate IV from cipher structure in symmetric crypto
operation, as
it is also used in authentication, for some algorithms
- Remove IV pointer and length from sym crypto op, and leave just
the
offset (from the beginning of the crypto operation),
as the IV can reside after the crypto operation
- Create union with authentication data and AAD, as these two values
cannot be used at the same time
[Akhil] Does this mean, in case of AEAD, additional authentication
data and auth data are contiguous as we do not have explicit auth
data
offset here.
- Remove digest length from sym crypto op, so this length will be
fixed for all the operations in a session
- Add zero-array at the end of sym crypto op to be used to get extra
allocated memory (IV + other user data)
Previous rte_crypto_op (40 bytes) and rte_crypto_sym_op (114 bytes)
structures:
struct rte_crypto_op {
enum rte_crypto_op_type type;
enum rte_crypto_op_status status;
struct rte_mempool *mempool;
phys_addr_t phys_addr;
void *opaque_data;
union {
struct rte_crypto_sym_op *sym;
};
} __rte_cache_aligned;
struct rte_crypto_sym_op {
struct rte_mbuf *m_src;
struct rte_mbuf *m_dst;
enum rte_crypto_sym_op_sess_type sess_type;
RTE_STD_C11
union {
struct rte_cryptodev_sym_session *session;
struct rte_crypto_sym_xform *xform;
};
struct {
struct {
uint32_t offset;
uint32_t length;
} data;
struct {
uint8_t *data;
phys_addr_t phys_addr;
uint16_t leng
Re: [dpdk-dev] [PATCH 5/5] examples/l3fwd: add neon support for l3fwd
Hi Ashwin, On 3 May 2017 at 13:24, Jianbo Liu wrote: > Hi Ashwin, > > On 2 May 2017 at 19:47, Sekhar, Ashwin wrote: >> Hi Jianbo, >> >> I tested your neon changes on thunderx. I am seeing a performance >> regression of ~10% for LPM case and ~20% for EM case with your changes. >> Did you see improvement on any arm64 platform with these changes. If >> yes, how much was the improvement? > > Thanks for your reviewing and testing. > For some reason, I have not done much with the performance testing. > I'll send a new version later after tuning the performance. > Can you tell me how did you test? My testing shows that EM case is much better, while LPM is almost the same as before. Thanks! Jianbo
[dpdk-dev] Patches verified by Intel engineers for DPDK 17.05 RC4.
Hi Thomas, Below patches have been verified. It would be great if they can get included into DPDK17.05. http://www.dpdk.org/dev/patchwork/patch/23957/ http://dpdk.org/dev/patchwork/patch/24044/ http://dpdk.org/dev/patchwork/patch/24021/ http://dpdk.org/dev/patchwork/patch/24022/ http://dpdk.org/dev/patchwork/patch/24023/ http://dpdk.org/dev/patchwork/patch/24051/ http://dpdk.org/dev/patchwork/patch/24052/ http://dpdk.org/dev/patchwork/patch/24053/ http://www.dpdk.org/dev/patchwork/patch/24060/ http://www.dpdk.org/dev/patchwork/patch/24061/ Thanks & Best Regards, Yu Liu
[dpdk-dev] [PATCH] app/testpmd: fix port_numa and ring_numa not initialize issue
Previous numa_support = 0 by default, it need to add --numa to testpmd
command line to enable numa, so port_numa and ring_numa were initialized
at function launch_args_parse(), now testpmd change numa_support = 1 as
default, so port_numa and ring_numa also need to initialize by default,
otherwise port->socket_id will be probed to wrong value.
Fixes: 999b2ee0fe45 ("app/testpmd: enable NUMA support by default")
Signed-off-by: Yulong Pei
---
app/test-pmd/parameters.c | 6 +-
app/test-pmd/testpmd.c| 7 +++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 787e143..36f7dd8 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -680,12 +680,8 @@ launch_args_parse(int argc, char** argv)
parse_fwd_portmask(optarg);
if (!strcmp(lgopts[opt_idx].name, "no-numa"))
numa_support = 0;
- if (!strcmp(lgopts[opt_idx].name, "numa")) {
+ if (!strcmp(lgopts[opt_idx].name, "numa"))
numa_support = 1;
-
memset(port_numa,NUMA_NO_CONFIG,RTE_MAX_ETHPORTS);
-
memset(rxring_numa,NUMA_NO_CONFIG,RTE_MAX_ETHPORTS);
-
memset(txring_numa,NUMA_NO_CONFIG,RTE_MAX_ETHPORTS);
- }
if (!strcmp(lgopts[opt_idx].name, "mp-anon")) {
mp_anon = 1;
}
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index dfe6442..78423ee 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -529,6 +529,13 @@ init_config(void)
uint8_t port_per_socket[RTE_MAX_NUMA_NODES];
memset(port_per_socket,0,RTE_MAX_NUMA_NODES);
+
+ if (numa_support) {
+ memset(port_numa, NUMA_NO_CONFIG, RTE_MAX_ETHPORTS);
+ memset(rxring_numa, NUMA_NO_CONFIG, RTE_MAX_ETHPORTS);
+ memset(txring_numa, NUMA_NO_CONFIG, RTE_MAX_ETHPORTS);
+ }
+
/* Configuration of logical cores. */
fwd_lcores = rte_zmalloc("testpmd: fwd_lcores",
sizeof(struct fwd_lcore *) * nb_lcores,
--
2.5.0
Re: [dpdk-dev] Patches verified by Intel engineers for DPDK 17.05 RC4.
04/05/2017 11:00, Liu, Yu Y: > Hi Thomas, > > Below patches have been verified. It would be great if they can get included > into DPDK17.05. Thanks for the list Yu. > http://www.dpdk.org/dev/patchwork/patch/23957/ > > http://dpdk.org/dev/patchwork/patch/24044/ > > http://dpdk.org/dev/patchwork/patch/24021/ > http://dpdk.org/dev/patchwork/patch/24022/ > http://dpdk.org/dev/patchwork/patch/24023/ > > http://dpdk.org/dev/patchwork/patch/24051/ > http://dpdk.org/dev/patchwork/patch/24052/ > http://dpdk.org/dev/patchwork/patch/24053/ > > http://www.dpdk.org/dev/patchwork/patch/24060/ > http://www.dpdk.org/dev/patchwork/patch/24061/ > > Thanks & Best Regards, > Yu Liu >
[dpdk-dev] [PATCH v5] app/testpmd: fix port_numa and ring_numa not initialize issue
Previous numa_support = 0 by default, it need to add --numa to testpmd
command line to enable numa, so port_numa and ring_numa were initialized
at function launch_args_parse(), now testpmd change numa_support = 1 as
default, so port_numa and ring_numa also need to initialize by default,
otherwise port->socket_id will be probed to wrong value.
Fixes: 999b2ee0fe45 ("app/testpmd: enable NUMA support by default")
Signed-off-by: Yulong Pei
---
app/test-pmd/parameters.c | 6 +-
app/test-pmd/testpmd.c| 7 +++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 787e143..36f7dd8 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -680,12 +680,8 @@ launch_args_parse(int argc, char** argv)
parse_fwd_portmask(optarg);
if (!strcmp(lgopts[opt_idx].name, "no-numa"))
numa_support = 0;
- if (!strcmp(lgopts[opt_idx].name, "numa")) {
+ if (!strcmp(lgopts[opt_idx].name, "numa"))
numa_support = 1;
-
memset(port_numa,NUMA_NO_CONFIG,RTE_MAX_ETHPORTS);
-
memset(rxring_numa,NUMA_NO_CONFIG,RTE_MAX_ETHPORTS);
-
memset(txring_numa,NUMA_NO_CONFIG,RTE_MAX_ETHPORTS);
- }
if (!strcmp(lgopts[opt_idx].name, "mp-anon")) {
mp_anon = 1;
}
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index dfe6442..78423ee 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -529,6 +529,13 @@ init_config(void)
uint8_t port_per_socket[RTE_MAX_NUMA_NODES];
memset(port_per_socket,0,RTE_MAX_NUMA_NODES);
+
+ if (numa_support) {
+ memset(port_numa, NUMA_NO_CONFIG, RTE_MAX_ETHPORTS);
+ memset(rxring_numa, NUMA_NO_CONFIG, RTE_MAX_ETHPORTS);
+ memset(txring_numa, NUMA_NO_CONFIG, RTE_MAX_ETHPORTS);
+ }
+
/* Configuration of logical cores. */
fwd_lcores = rte_zmalloc("testpmd: fwd_lcores",
sizeof(struct fwd_lcore *) * nb_lcores,
--
2.5.0
[dpdk-dev] [PATCH] doc: announce public crypto PMD names removal
The following PMD names definitions will be moved to the individual PMDs to remove the coupling between crypto PMDs and the librte_cryptodev: CRYPTODEV_NAME_NULL_PMD CRYPTODEV_NAME_AESNI_MB_PMD CRYPTODEV_NAME_AESNI_GCM_PMD CRYPTODEV_NAME_OPENSSL_PMD CRYPTODEV_NAME_QAT_SYM_PMD CRYPTODEV_NAME_SNOW3G_PMD CRYPTODEV_NAME_KASUMI_PMD CRYPTODEV_NAME_ZUC_PMD CRYPTODEV_NAME_ARMV8_PMD CRYPTODEV_NAME_SCHEDULER_PMD CRYPTODEV_NAME_DPAA2_SEC_PMD Signed-off-by: Slawomir Mrozowicz --- doc/guides/rel_notes/deprecation.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index a3e7c72..7dde7da 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -81,3 +81,6 @@ Deprecation Notices - ``rte_crpytodev_scheduler_mode_get``, replaced by ``rte_cryptodev_scheduler_mode_get`` - ``rte_crpytodev_scheduler_mode_set``, replaced by ``rte_cryptodev_scheduler_mode_set`` + +* cryptodev: All PMD names definitions will be moved to the individual PMDs + in 17.08. \ No newline at end of file -- 2.5.0
[dpdk-dev] [PATCH] net/ixgbe: fix VF Rx mode if allmulticast is disabled
Some customers find that 82599 NIC DPDK VF PMD can't receive any
broadcast packets when it is bound to igb_uio in the first time
to run a DPDK application like testpmd. But when the application
is quited and run again, the DPDK VF PMD can receive broadcast
packets again. The associated PF is run by kernel driver when
the VF is driven by DPDK PMD.
When patch fixes this issue.
Fixes: 260e2e22e26f ("net/ixgbe/base: move multicast mode update")
Fixes: 72dec9e37a84 ("ixgbe: support multicast promiscuous mode on VF")
Cc: sta...@dpdk.org
Signed-off-by: Wei Dai
---
drivers/net/ixgbe/ixgbe_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index bbae4f9..dbe777d 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -7852,7 +7852,7 @@ ixgbevf_dev_allmulticast_disable(struct rte_eth_dev *dev)
{
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- hw->mac.ops.update_xcast_mode(hw, IXGBEVF_XCAST_MODE_NONE);
+ hw->mac.ops.update_xcast_mode(hw, IXGBEVF_XCAST_MODE_MULTI);
}
static void ixgbevf_mbx_process(struct rte_eth_dev *dev)
--
2.7.4
[dpdk-dev] Sharing tables among pipelines
Hi, For my pipeline application, I want to share same table between two different pipeline. Is that possible? If yes, how can I do it? Thanks for your reply and help. -- Regards, Nidhia Varghese
[dpdk-dev] [PATCH 1/2] usertools: fix adding devices of same class
From: Guduri Prathyusha
If multiple devices of same class are added to a device type,
only devices that match first device listed in device type list are
processed.
Fixing it in device_type_match() by returning false after iterating
through all the devices listed in a device type list.
Fixes: 8ad08a287918 ("usertools: define DPDK PCI functional device")
Signed-off-by: Guduri Prathyusha
---
usertools/dpdk-devbind.py | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
index 2d99e9d82..79e7e8938 100755
--- a/usertools/dpdk-devbind.py
+++ b/usertools/dpdk-devbind.py
@@ -354,8 +354,7 @@ def device_type_match(dev, devices_type):
# count must be the number of non None parameters to match
if match_count == param_count:
return True
-else:
-return False
+return False
def dev_id_from_dev_name(dev_name):
'''Take a device "name" - a string passed in by user to identify a NIC
--
2.12.2
[dpdk-dev] [PATCH 2/2] usertools: add cavium pkx device as network device
Signed-off-by: Jerin Jacob
---
usertools/dpdk-devbind.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
index 79e7e8938..f0225b6ce 100755
--- a/usertools/dpdk-devbind.py
+++ b/usertools/dpdk-devbind.py
@@ -49,8 +49,10 @@
'SVendor': None, 'SDevice': None}
cavium_fpa = {'Class': '08', 'Vendor': '177d', 'Device': 'a053',
'SVendor': None, 'SDevice': None}
+cavium_pkx = {'Class': '08', 'Vendor': '177d', 'Device': 'a0dd,a049',
+ 'SVendor': None, 'SDevice': None}
-network_devices = [network_class]
+network_devices = [network_class, cavium_pkx]
crypto_devices = [encryption_class, intel_processor_class]
eventdev_devices = [cavium_sso]
mempool_devices = [cavium_fpa]
--
2.12.2
[dpdk-dev] DPDK support for wireless NICs
Hi Developers, I believe wireless NICs would be able to handle higher amount of data in future and bringing in support of DPDK for wireless NICs earlier would be beneficial to the wireless community. I would like to work on this. Could you please share some light on how to proceed further. Whether this is a feasible idea and what might be the benefits and cons. Linux has the mac80211 framework helping 802.11 driver developers. Suggestion on how to use this mac80211 framework along with DPDK would be useful for me to proceed further. Thanks, Arun
[dpdk-dev] [PATCH] net/af_packet: prefer snprintf against strncpy
strncpy may left destination buffer not NULL terminated, switched using
snprintf to be sure destination buffer is NULL terminated.
Coverity issue: 1407495
Coverity issue: 1407498
Fixes: cc68ac4847bc ("net/af_packet: support MTU change")
Fixes: 218259590ea4 ("net/af_packet: support promiscuous")
Signed-off-by: Ferruh Yigit
---
Cc: Chas Williams
---
drivers/net/af_packet/rte_eth_af_packet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index 6f6ba0c..68de45c 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -452,7 +452,7 @@ eth_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
if (s < 0)
return -EINVAL;
- strncpy(ifr.ifr_name, internals->if_name, IFNAMSIZ);
+ snprintf(ifr.ifr_name, IFNAMSIZ, "%s", internals->if_name);
ret = ioctl(s, SIOCSIFMTU, &ifr);
close(s);
@@ -472,7 +472,7 @@ eth_dev_change_flags(char *if_name, uint32_t flags,
uint32_t mask)
if (s < 0)
return;
- strncpy(ifr.ifr_name, if_name, IFNAMSIZ);
+ snprintf(ifr.ifr_name, IFNAMSIZ, "%s", if_name);
if (ioctl(s, SIOCGIFFLAGS, &ifr) < 0)
goto out;
ifr.ifr_flags &= mask;
--
2.9.3
Re: [dpdk-dev] [PATCH] [RFC] cryptodev: crypto operation restructuring
On 5/4/2017 1:49 PM, Sergio Gonzalez Monroy wrote:
On 04/05/2017 08:38, Akhil Goyal wrote:
On 5/4/2017 1:01 PM, Sergio Gonzalez Monroy wrote:
On 04/05/2017 07:09, Akhil Goyal wrote:
Hi Sergio,
On 5/3/2017 7:48 PM, Sergio Gonzalez Monroy wrote:
On 03/05/2017 12:01, Akhil Goyal wrote:
Hi Pablo,
On 4/28/2017 11:33 PM, Pablo de Lara wrote:
This is a proposal 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 as
one of the goals.
The following changes are proposed:
In rte_crypto_op:
- Move session type (with session/sessionless) from symmetric op to
crypto op,
as this could be used for other types
- Combine operation type, operation status and session type into a
64-bit flag (each one taking 1 byte),
instead of having enums taking 4 bytes each
[Akhil] wouldn't this be a problem? Bit fields create endianness
issues. Can we have uint8_t for each of the field.
Sure, as it is proposed it would be the same as having 3 uint8_t
fields.
The idea was to possibly compact those fields (ie. we do not need 8
bits
for sess_type) to make better use of the bits and add asym fields
there
if needed.
I don't think bitfields would be a problem in this case. Agree, we
should not use both bitmask and bitfields, but we would use just
bitfields.
Can you elaborate on the issue you see?
Regards,
Sergio
The problem will come when we run on systems with different
endianness. The bit field positioning will be different for LE and BE.
It would be like in LE
uint64_t type:8;
uint64_t status:8;
uint64_t sess_type:8;
uint64_t reserved:40;
and on BE it would be
uint64_t reserved:40;
uint64_t sess_type:8;
uint64_t status:8;
uint64_t type:8;
So it would be better to use uint8_t for each of the field.
Understood, but why is that an issue? Those fields are used by
application code and PMD, same system.
Do you have a use case where you are offloading crypto ops to a
different arch/system?
Sergio
same application may run on LE or BE machines. So if we use masks for
accessing these fields and take the complete field as uint64_t, then
LE and BE machine would interpret it differently as the code is same.
Right, either you use bitfields or you define macros and work on the
complete uint64_t. The proposal here was to just use bitfields and for
the given use case it would not be an issue while IMHO allowing better
packing and readability than defining each field as a Byte.
Anyway, if you feel strongly against bitfields, we can just define it as
uint8_t as you suggest or single uint64_t with macros.
Sergio
I am not against bitfields. But we should take care of the endianness
using the compile time flags for byte ordering or we can use the uint8_t.
I am ok with both.
Thanks,
Akhil
Akhil
- Remove opaque data from crypto operation, as private data can be
allocated
just after the symmetric (or other type) crypto operation
- Modify symmetric operation pointer to zero-array, as the symmetric
op should be always after the crypto operation
In rte_crypto_sym_xform:
- Remove AAD length from sym_xform (will be taken from operation
only)
- Add IV length in sym_xform, so this length will be fixed for all
the operations in a session
A much needed change. This would remove hard codings for iv length
while configuring sessions.
In rte_crypto_sym_op:
- Separate IV from cipher structure in symmetric crypto
operation, as
it is also used in authentication, for some algorithms
- Remove IV pointer and length from sym crypto op, and leave just
the
offset (from the beginning of the crypto operation),
as the IV can reside after the crypto operation
- Create union with authentication data and AAD, as these two values
cannot be used at the same time
[Akhil] Does this mean, in case of AEAD, additional authentication
data and auth data are contiguous as we do not have explicit auth
data
offset here.
Pablo/Sergio,
Is my understanding correct here?
Akhil
- Remove digest length from sym crypto op, so this length will be
fixed for all the operations in a session
- Add zero-array at the end of sym crypto op to be used to get extra
allocated memory (IV + other user data)
Previous rte_crypto_op (40 bytes) and rte_crypto_sym_op (114 bytes)
structures:
struct rte_crypto_op {
enum rte_crypto_op_type type;
enum rte_crypto_op_status status;
struct rte_mempool *mempool;
phys_addr_t phys_addr;
void *opaque_data;
union {
struct rte_crypto_sym_op *sym;
};
} __rte_cache_aligned;
struct rte_crypto_sym_op {
struct rte_mbuf *m_src;
struct rte_mbuf *m_dst;
enum rte_crypto_sym_op_sess_type sess_type;
RTE_STD_C11
union {
struct rte_cryptodev_sym_session *session;
struct rte_crypto_sym_xform *xform;
};
struct {
[dpdk-dev] Proposed schedule dates for DPDK 17.08, 17.11 and 18.02
Hi, The current 17.08 schedule dates are: 17.08 * Proposal deadline:March 3, 2017 * Integration deadline: March 30, 2017 * Release: May1, 2017 http://dpdk.org/dev/roadmap#dates The following are proposed dates for 17.11 and 18.02. 17.11 * Proposal deadline:August25, 2017 * Integration deadline: September 29, 2017 * Release: November 2, 2017 18.02 * Proposal deadline:November 24, 2017 * Integration deadline: December 29, 2017 * Release: February 2, 2018 These dates need to be discussed/agreed in the community since there are a lot of different holidays in these periods: August holidays, Christmas, New Year, Spring Festival. John
Re: [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify library
> -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 CCing techbo...@dpdk.org since we would like this RFC added to the agenda for discussion at the next Tech Board meeting. John
Re: [dpdk-dev] Minutes of tech-board meeting 2017-04-27
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Hemant Agrawal > Sent: Wednesday, May 3, 2017 6:57 AM > To: dev@dpdk.org; techbo...@dpdk.org > Subject: [dpdk-dev] Minutes of tech-board meeting 2017-04-27 > > Hi all, > > Here is the meeting notes for the last DPDK technical board meeting held > on 2017-04-27. > Hi, What is the date for the next Tech Board meeting? John
Re: [dpdk-dev] [RFC] service core concept header implementation
-Original Message- > Date: Thu, 4 May 2017 12:05:54 +0530 > From: Jerin Jacob > To: Harry van Haaren > Cc: dev@dpdk.org, bruce.richard...@intel.com, hemant.agra...@nxp.com, > nipun.gu...@nxp.com, narender.vang...@intel.com, gage.e...@intel.com > Subject: Re: [RFC] service core concept header implementation > User-Agent: Mutt/1.8.2 (2017-04-18) > > -Original Message- > > Date: Wed, 3 May 2017 12:29:21 +0100 > > From: Harry van Haaren > > To: dev@dpdk.org > > CC: Harry van Haaren , > > bruce.richard...@intel.com, hemant.agra...@nxp.com, nipun.gu...@nxp.com, > > narender.vang...@intel.com, jerin.ja...@caviumnetworks.com, > > gage.e...@intel.com > > Subject: [RFC] service core concept header implementation > > X-Mailer: git-send-email 2.7.4 > > Hi Harry, > > Overall it looks good. Some initial comments > > > > > This patch adds a service header to DPDK EAL. This header is > > an RFC for a mechanism to allow DPDK components request a > > callback function to be invoked. > > > > The application can set the number of service cores, and > > a coremask for each particular services. The implementation > > of this functionality in rte_services.c (not completed) would > > use atomics to ensure that a service can only be polled by a > > single lcore at a time. > > single lcore at a time "if multipthread_capable flag is not set". Right? > > > > > Signed-off-by: Harry van Haaren > > --- > > lib/librte_eal/common/include/rte_service.h | 211 > > > > 1 file changed, 211 insertions(+) > > create mode 100644 lib/librte_eal/common/include/rte_service.h > > > > diff --git a/lib/librte_eal/common/include/rte_service.h > > b/lib/librte_eal/common/include/rte_service.h > > new file mode 100644 > > index 000..cfa26f3 > > --- /dev/null > > +++ b/lib/librte_eal/common/include/rte_service.h > > @@ -0,0 +1,211 @@ > > +/* > > + * BSD LICENSE > > + * > > + * Copyright(c) 2017 Intel Corporation. All rights reserved. > > + * > > + * Redistribution and use in source and binary forms, with or without > > + * modification, are permitted provided that the following conditions > > + * are met: > > + * > > + * * Redistributions of source code must retain the above copyright > > + * notice, this list of conditions and the following disclaimer. > > + * * Redistributions in binary form must reproduce the above copyright > > + * notice, this list of conditions and the following disclaimer in > > + * the documentation and/or other materials provided with the > > + * distribution. > > + * * Neither the name of Intel Corporation nor the names of its > > + * contributors may be used to endorse or promote products derived > > + * from this software without specific prior written permission. > > + * > > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > > + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > > + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR > > + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT > > + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, > > + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT > > + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY > > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE > > + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > > + */ > > + > > +#ifndef _RTE_SERVICE_H_ > > +#define _RTE_SERVICE_H_ > > + > > +/** > > + * @file > > + * > > + * Service functions > > + * > > + * The service functionality provided by this header allows a DPDK > > component > > + * to indicate that it requires a function call in order for it to perform > > + * its processing. > > + * > > + * An example usage of this functionality would be a component that > > registers > > + * a service to perform a particular packet processing duty: for example > > the > > + * eventdev software PMD. At startup the application requests all services > > + * that have been registered, and the app decides how many cores will run > > the > > s/app/application > > > + * required services. The EAL removes these number of cores from the > > available > > + * runtime cores, and dedicates them to performing service-core workloads. > > The > > + * application has access to the remaining lcores as normal. > > + * > > + * An example of the service core infrastructure with an application > > + * configuring a single service (the eventdev sw PMD), and dedicating one > > core > > + * exclusively to run the service would interact with the API as follows: > > + * > > + * 1. Eventdev SW PMD calls *rte_eal_service_register*, indicating that it > > + *
[dpdk-dev] Occasional instability in RSS Hashes/Queues from X540 NIC
Hey Folks, I'm seeing some strange behavior with regard to the RSS hash values in my applications and was hoping somebody might have some pointers on where to look. In my application, I'm using RSS to divide work among multiple cores, each of which services a single RX queue. When dealing with a single long-lived TCP connection, I occasionally see packets going to the wrong core. That is, almost all of the packets in the connection go to core 5 in this case, but every once in a while, one goes to core 0 instead. Upon further investigation, I find two problems are occurring. The first is that problem packets have the RSS hash value in the mbuf incorrectly set to zero. They are therefore put in queue zero, where they are read by core zero. Other packets from the same connection that occur immediately before and after the packet in question have the correct hash value and therefore go to a different core. The second problem is that we sometimes see packets in which the RSS hash in the mbuf appears correct, but the packets are incorrectly put into queue zero. As with the first, this results in the wrong core getting the packet. Either one of these confuses the state tracking we're doing per-core. A few details: - Using an Intel X540-AT2 NIC and the igb_uio driver - DPDK 16.04 - A particular packet in our workflow always encounters this problem. - Retransmissions of the packet in question also encounter the problem - The packet is IPv4, with header length of 20 (so no options), no fragmentation. - The only differences I can see in the IP header between packets that get the right hash value and those that get the wrong one are in the IP ID, total length, and checksum fields. - Using ETH_RSS_IPV4 - The packet is TCP with about 100 bytes of payload - it's not a jumbo or a runt - We fill the key in with 0x6d5a to get symmetric hashing of both sides of the connection - We only configure RSS information at boot; things like the key or header fields are not being changed dynamically - Traffic load is light when the problem occurs Is anybody aware of an errata, either in the NIC or the PMD's configuration of it that might explain something like this? Failing that, if you ran into this sort of behavior, how would you approach finding the reason for the error? Every failure mode I can think of would tend to affect all of the packets in the connection consistently, even if incorrectly. Thanks in advance for any ideas. -- Matt Laswell lasw...@infinite.io
[dpdk-dev] [PATCH] drivers/net: add generic ethdev macro to get PCI device
Instead of many PMD define their own macro, define a generic one in
ethdev and use that in PMDs.
Signed-off-by: Ferruh Yigit
---
drivers/net/ark/ark_ethdev.c | 4 ++--
drivers/net/ark/ark_ethdev.h | 4
drivers/net/avp/avp_ethdev.c | 25 +++--
drivers/net/e1000/e1000_ethdev.h | 2 --
drivers/net/e1000/em_ethdev.c | 13 ++---
drivers/net/e1000/igb_ethdev.c| 24
drivers/net/e1000/igb_pf.c| 2 +-
drivers/net/i40e/i40e_ethdev.c| 30 +++---
drivers/net/i40e/i40e_ethdev.h| 3 ---
drivers/net/i40e/i40e_ethdev_vf.c | 18 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 38 +++---
drivers/net/ixgbe/ixgbe_ethdev.h | 3 ---
drivers/net/ixgbe/ixgbe_pf.c | 2 +-
drivers/net/ixgbe/rte_pmd_ixgbe.c | 20 ++--
drivers/net/sfc/sfc.c | 4 ++--
drivers/net/sfc/sfc.h | 3 ---
drivers/net/sfc/sfc_debug.h | 3 ++-
drivers/net/sfc/sfc_ethdev.c | 2 +-
drivers/net/sfc/sfc_intr.c| 10 +-
drivers/net/sfc/sfc_log.h | 3 ++-
drivers/net/sfc/sfc_rx.c | 2 +-
drivers/net/sfc/sfc_tx.c | 2 +-
lib/librte_ether/rte_ethdev.h | 2 ++
23 files changed, 102 insertions(+), 117 deletions(-)
diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index 83961f5..230d3f5 100644
--- a/drivers/net/ark/ark_ethdev.c
+++ b/drivers/net/ark/ark_ethdev.c
@@ -278,7 +278,7 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
ret = check_for_ext(ark);
if (ret)
return ret;
- pci_dev = ARK_DEV_TO_PCI(dev);
+ pci_dev = RTE_ETH_DEV_TO_PCI(dev);
rte_eth_copy_pci_info(dev, pci_dev);
/* Use dummy function until setup */
@@ -751,7 +751,7 @@ eth_ark_dev_info_get(struct rte_eth_dev *dev,
ETH_LINK_SPEED_40G |
ETH_LINK_SPEED_50G |
ETH_LINK_SPEED_100G);
- dev_info->pci_dev = ARK_DEV_TO_PCI(dev);
+ dev_info->pci_dev = RTE_ETH_DEV_TO_PCI(dev);
}
static int
diff --git a/drivers/net/ark/ark_ethdev.h b/drivers/net/ark/ark_ethdev.h
index 9f8d32f..df5547b 100644
--- a/drivers/net/ark/ark_ethdev.h
+++ b/drivers/net/ark/ark_ethdev.h
@@ -34,8 +34,4 @@
#ifndef _ARK_ETHDEV_H_
#define _ARK_ETHDEV_H_
-#define ARK_DEV_TO_PCI(eth_dev)\
- RTE_DEV_TO_PCI((eth_dev)->device)
-
-
#endif
diff --git a/drivers/net/avp/avp_ethdev.c b/drivers/net/avp/avp_ethdev.c
index fe6849f..d8ca213 100644
--- a/drivers/net/avp/avp_ethdev.c
+++ b/drivers/net/avp/avp_ethdev.c
@@ -113,9 +113,6 @@ static void avp_dev_stats_get(struct rte_eth_dev *dev,
static void avp_dev_stats_reset(struct rte_eth_dev *dev);
-#define AVP_DEV_TO_PCI(eth_dev) RTE_DEV_TO_PCI((eth_dev)->device)
-
-
#define AVP_MAX_RX_BURST 64
#define AVP_MAX_TX_BURST 64
#define AVP_MAX_MAC_ADDRS 1
@@ -393,7 +390,7 @@ static void *
avp_dev_translate_address(struct rte_eth_dev *eth_dev,
phys_addr_t host_phys_addr)
{
- struct rte_pci_device *pci_dev = AVP_DEV_TO_PCI(eth_dev);
+ struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(eth_dev);
struct rte_mem_resource *resource;
struct rte_avp_memmap_info *info;
struct rte_avp_memmap *map;
@@ -446,7 +443,7 @@ avp_dev_version_check(uint32_t version)
static int
avp_dev_check_regions(struct rte_eth_dev *eth_dev)
{
- struct rte_pci_device *pci_dev = AVP_DEV_TO_PCI(eth_dev);
+ struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(eth_dev);
struct rte_avp_memmap_info *memmap;
struct rte_avp_device_info *info;
struct rte_mem_resource *resource;
@@ -582,7 +579,7 @@ _avp_set_rx_queue_mappings(struct rte_eth_dev *eth_dev,
uint16_t rx_queue_id)
static void
_avp_set_queue_counts(struct rte_eth_dev *eth_dev)
{
- struct rte_pci_device *pci_dev = AVP_DEV_TO_PCI(eth_dev);
+ struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(eth_dev);
struct avp_dev *avp = AVP_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
struct rte_avp_device_info *host_info;
void *addr;
@@ -642,7 +639,7 @@ avp_dev_attach(struct rte_eth_dev *eth_dev)
* re-run the device create utility which will parse the new host info
* and setup the AVP device queue pointers.
*/
- ret = avp_dev_create(AVP_DEV_TO_PCI(eth_dev), eth_dev);
+ ret = avp_dev_create(RTE_ETH_DEV_TO_PCI(eth_dev), eth_dev);
if (ret < 0) {
PMD_DRV_LOG(ERR, "Failed to re-create AVP device, ret=%d\n",
ret);
@@ -696,7 +693,7 @@ static void
avp_dev_interrupt_handler(void *data)
{
struct rte_eth_dev *eth_dev = data;
- struct rte_pci_device *pci_dev = AVP_DEV_TO_PCI(eth_dev);
+ struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(eth_dev);
void *registe
Re: [dpdk-dev] [PATCH] drivers/net: add generic ethdev macro to get PCI device
> -Original Message- > From: Ferruh Yigit [mailto:ferruh.yi...@intel.com] > Sent: Thursday, May 04, 2017 9:08 AM > To: Thomas Monjalon; Shepard Siegel; Ed Czeck; John Miller; Legacy, Allain; > Peters, Matt; LU, WENZHUO; ZHANG, HELIN; WU, JINGJING; ANANYEV, > KONSTANTIN; Andrew Rybchenko > Cc: dev@dpdk.org; YIGIT, FERRUH > Subject: [PATCH] drivers/net: add generic ethdev macro to get PCI device > > 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
[dpdk-dev] [PATCH] usertools: add option to unbind all devices
-u accepts "dpdk" argument to unbind all devices bound to a DPDK driver. Usage: usertools/dpdk-devbind.py -u dpdk Example: $ usertools/dpdk-devbind.py -s Network devices using DPDK-compatible driver :08:00.1 '...' drv=igb_uio unused= :81:00.0 '...' drv=igb_uio unused= :88:00.0 '...' drv=igb_uio unused= :88:00.1 '...' drv=igb_uio unused= ... $ usertools/dpdk-devbind.py -u dpdk $ usertools/dpdk-devbind.py -s Network devices using DPDK-compatible driver Signed-off-by: Ferruh Yigit --- usertools/dpdk-devbind.py | 8 1 file changed, 8 insertions(+) diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py index 2d99e9d..1a51c26 100755 --- a/usertools/dpdk-devbind.py +++ b/usertools/dpdk-devbind.py @@ -517,6 +517,14 @@ def bind_one(dev_id, driver, force): def unbind_all(dev_list, force=False): """Unbind method, takes a list of device locations""" + +if dev_list[0] == "dpdk": +for d in devices.keys(): +if "Driver_str" in devices[d]: +if devices[d]["Driver_str"] in dpdk_drivers: +unbind_one(devices[d]["Slot"], force) +return + dev_list = map(dev_id_from_dev_name, dev_list) for d in dev_list: unbind_one(d, force) -- 2.9.3
Re: [dpdk-dev] [PATCH] kni: fix unit test segfault
On 5/4/2017 6:23 AM, gowrishankar muthukrishnan wrote:
> Hi Ferruh,
> Even w/o this patch, I mostly find mbufs returned by rte_kni_rx_burst()
> always 0
> (or sometimes 1) where as more than 32000 mbufs approx created in
> ingress side
> for this test.
>
>dpdk/test/test $ ./test -l 0,1,2 --socket-mem 1024
>
> Am I missing something required for this unit test ?.
Hi Gowrishankar,
KNI module should be inserted with one of the loopback options [1] for
the unit test.
[1]
There are two loopback options supported, both loopbacks Rx/Tx path in
kernel side, this is easy way to test KNI.
options are: lo_mode_fifo and lo_mode_fifo_skb
usage:
insmod build/kmod/rte_kni.ko lo_mode=lo_mode_fifo
or
insmod build/kmod/rte_kni.ko lo_mode=lo_mode_fifo_skb
Regards,
ferruh
>
> Thanks,
> Gowrishankar
>
> On Wednesday 03 May 2017 09:40 PM, Ferruh Yigit wrote:
>> To clean alloc_q, which has physicall addresses of the mbufs, kni lib
>> free the pkt_mempool, but this leads a crash in kni unit test.
>>
>> KNI library shouldn't free the pkt_mempool.
>>
>> Implementation updated to find the mbufs in the alloc_q and return them
>> back to mempool.
>>
>> Fixes: 8eba5ebd1811 ("kni: fix possible memory leak")
>>
>> Signed-off-by: Ferruh Yigit
>> ---
>> lib/librte_kni/rte_kni.c | 34 ++
>> 1 file changed, 22 insertions(+), 12 deletions(-)
>>
>> diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
>> index 52fcd4b..c3f9208 100644
>> --- a/lib/librte_kni/rte_kni.c
>> +++ b/lib/librte_kni/rte_kni.c
>> @@ -451,17 +451,35 @@ kni_free_fifo(struct rte_kni_fifo *fifo)
>> } while (ret);
>> }
>>
>> +static void *
>> +va2pa(struct rte_mbuf *m)
>> +{
>> +return (void *)((unsigned long)m -
>> +((unsigned long)m->buf_addr -
>> + (unsigned long)m->buf_physaddr));
>> +}
>> +
>> static void
>> -kni_free_fifo_phy(struct rte_mempool *pktmbuf_pool, struct rte_kni_fifo
>> *fifo)
>> +obj_free(struct rte_mempool *mp __rte_unused, void *opaque, void *obj,
>> +unsigned obj_idx __rte_unused)
>> +{
>> +struct rte_mbuf *m = obj;
>> +void *mbuf_phys = opaque;
>> +
>> +if (va2pa(m) == mbuf_phys)
>> +rte_pktmbuf_free(m);
>> +}
>> +
>> +static void
>> +kni_free_fifo_phy(struct rte_mempool *mp, struct rte_kni_fifo *fifo)
>> {
>> void *mbuf_phys;
>> int ret;
>>
>> -rte_mempool_free(pktmbuf_pool);
>> -
>> -/* All mbufs alredy freed with rte_mempoll_free, just free the fifo */
>> do {
>> ret = kni_fifo_get(fifo, &mbuf_phys, 1);
>> +if (ret)
>> +rte_mempool_obj_iter(mp, obj_free, mbuf_phys);
>> } while (ret);
>> }
>>
>> @@ -557,14 +575,6 @@ rte_kni_handle_request(struct rte_kni *kni)
>> return 0;
>> }
>>
>> -static void *
>> -va2pa(struct rte_mbuf *m)
>> -{
>> -return (void *)((unsigned long)m -
>> -((unsigned long)m->buf_addr -
>> - (unsigned long)m->buf_physaddr));
>> -}
>> -
>> unsigned
>> rte_kni_tx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned
>> num)
>> {
>
>
Re: [dpdk-dev] [PATCH v3 1/4] mk: add crypto capability for generic armv8a and thunderx
On Wed, 3 May 2017 23:56:59 -0700 Ashwin Sekhar T K wrote: > armv8-a has optional CRYPTO extension which adds the > AES, PMULL, SHA1 and SHA2 capabilities. -march=armv8-a+crypto > enables code generation for the ARMv8-A architecture together > with the optional CRYPTO extensions. > > added the following flags to detect the corresponding > capability at compile time > * RTE_MACHINE_CPUFLAG_AES > * RTE_MACHINE_CPUFLAG_PMULL > * RTE_MACHINE_CPUFLAG_SHA1 > * RTE_MACHINE_CPUFLAG_SHA2 > > at run-time, the following flags can be used to detect these > capabilities > * RTE_CPUFLAG_AES > * RTE_CPUFLAG_PMULL > * RTE_CPUFLAG_SHA1 > * RTE_CPUFLAG_SHA2 > > Signed-off-by: Ashwin Sekhar T K Reviewed-by: Jan Viktorin
Re: [dpdk-dev] [PATCH v3 2/4] eal: move gcc version definition to common header
On Wed, 3 May 2017 23:57:00 -0700 Ashwin Sekhar T K wrote: > moved the definition of GCC_VERSION from lib/librte_table/rte_lru.h s/moved/Moved/ > to lib/librte_eal/common/include/rte_common.h dot after the sentence > > Tested compilation on arm64 with gcc > > Tested compilation on x86 with gcc and clang Tested compilation on: * arm64 with gcc * x86 with gcc and clang > > Signed-off-by: Ashwin Sekhar T K Reviewed-by: Jan Viktorin
[dpdk-dev] [RFC PATCH] cryptodev: make crypto session device independent
This RFC describes a proposal to 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. 1. Overview Limitations of existing implementation: a) Each session can store only private data for one device type. It makes impossible to use the same session with different device types (e.g. QAT, openssl) and requires to create multiple instances of session for each device type. b) Session objects are stored in the device instances. Use of session created on other instance of the device with the same type is not possible. Removing limitations listed above, should: a) Share one session with different devices in a transparent way, b) Simplify architecture by coupling sessions not with device instance, but external session mempool created and managed by application. c) Increase performance, consistency and reliability in terms of: - Session management time, - Number of sessions that should be created and initialized, - One session can be used on multiple devices (with transparent access to the session private data) - Simplify session management and utilizaton in the application, - Sessions are stored outside of the device instance and can be used and managed regardless of the state of the device (e.g. failures) 2. Scope of work a) Make the create sessions private data be agnostic to underlying device by adding an indirection in the sessions private_data using the crypto device identifier. b) Make necessary changes to the crypto session mempool infrastructure to remove coupling with crypto PMD. c) A single session can contain indirections to multiple device types. d) Lazy retrieval of private session material at run time in each PMD 3. Proposal architecture SESSION MEMPOOL <---|---> DEVICE INSTANCES .-. .. | Crypto|. | mempool obj| | sym-session |<--. | .--+ | mempool || | | | rte_cryptodev_session| .-. `-'| | | | - session type | | DEVICE| `-|---' | | | - supported device mask | | INSTANCE | | `--- mempool| | - device id | +>| | - private data[type idx] | .--| - session | | `-+=|..|=' | | mempool | | | || `-' | | || | .--.| || .-. +>| mempool obj || | .. | | DEVICE| | | .+| | | DRIVER | | | INSTANCE | | | | PMD's private data |<---+--| - type |<--+--| | | +-++ | `' | ... | || | | || `-' || | .--. | .-. `>| mempool obj | | .. | DEVICE| | .+ | | DRIVER | | INSTANCE | | | PMD's private data |<--+---| - type |<-| | `-+' `' | ... | | | `-' Crypto sym-session mempool Mempool created to store rte_cryptodev_session objects as well as private data for supported device types. This mempool should replace existing session mempools in device instances to ease session management and improve consistency (especially if the session is intended to be used for operations performed on different devices). Device type id Device type id is an unique number identifing device driver type. rte_crypto_session New rte_cryptodev_session structure is taken from crypto session mempool and can store more than one PMD's private data object (one for each device type supported by sesion). Crypto operations will use device type id (unique for each driver) to retrieve private data from rte_crypto_session right for the device type they are performed on. 4. API proposal Crypto session pool /**< * Create symmetric crypto sess
Re: [dpdk-dev] [PATCH] eal: remove generic driver and device lists
02/05/2017 01:05, Thomas Monjalon: > These lists were unused and useless because they are maintained per bus: > struct rte_driver_list dev_driver_list > struct rte_device_list dev_device_list > > Signed-off-by: Thomas Monjalon > --- > lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 -- > lib/librte_eal/common/eal_common_dev.c | 34 - > lib/librte_eal/common/eal_common_vdev.c | 11 --- > lib/librte_eal/common/include/rte_dev.h | 39 > - > lib/librte_eal/linuxapp/eal/rte_eal_version.map | 2 -- > 5 files changed, 88 deletions(-) Applied
[dpdk-dev] [PATCH 00/10] Enable DPDK core build with gcc 7
Since GCC 7 is now yesterday's news :-), I figured we should try and make DPDK compile successfully with that new version. The main difficulties are because of new warnings being triggered. * New warnings for fall-though in case statements * New warnings for possible truncation using snprintf * New warnings about uninitialized values. This set of patches fixes or works around those new issues, fixing a couple of bugs in the process, so that DPDK can compile using gcc 7. NOTE: this set only covers the basic DPDK libs, apps and tests. It does not cover the example apps, which still have issues. Bruce Richardson (10): mk: adjust gcc flags for new gcc 7 warnings drivers/net: disable new gcc 7 warnings for base code net/bnx2x: fix warnings about switch fall-through net/ixgbe: fix gcc 7 warning for switch fallthrough net/vmxnet3: fix compile error with gcc 7 lib: fix gcc 7 warnings for switch fall-through net: fix missing break inside conditional compile block app/testpmd: document explicit switch fall-through test/test: fix missing break in switch test/test: fix gcc 7 compiler error app/test-pmd/cmdline.c | 2 ++ drivers/net/bnx2x/ecore_sp.c | 2 +- drivers/net/bnx2x/elink.c | 3 +++ drivers/net/e1000/Makefile | 3 +++ drivers/net/fm10k/Makefile | 3 +++ drivers/net/ixgbe/Makefile | 3 +++ drivers/net/ixgbe/ixgbe_fdir.c | 2 ++ drivers/net/qede/Makefile | 3 +++ drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 +- lib/librte_cmdline/cmdline_parse_num.c | 4 ++-- lib/librte_hash/rte_hash_crc.h | 6 ++ lib/librte_mbuf/rte_mbuf.h | 4 lib/librte_net/rte_net_crc.c | 2 +- mk/toolchain/gcc/rte.vars.mk | 7 +++ test/test/test_cmdline_num.c | 1 + test/test/test_eventdev_sw.c | 2 +- 16 files changed, 43 insertions(+), 6 deletions(-) -- 2.9.3
[dpdk-dev] [PATCH 02/10] drivers/net: disable new gcc 7 warnings for base code
For base code in drivers shared with other projects, disable the new warnings from gcc 7 about unlabelled fall-through in switch statements. Signed-off-by: Bruce Richardson --- drivers/net/e1000/Makefile | 3 +++ drivers/net/fm10k/Makefile | 3 +++ drivers/net/ixgbe/Makefile | 3 +++ drivers/net/qede/Makefile | 3 +++ 4 files changed, 12 insertions(+) diff --git a/drivers/net/e1000/Makefile b/drivers/net/e1000/Makefile index a32fabe..b5592d6 100644 --- a/drivers/net/e1000/Makefile +++ b/drivers/net/e1000/Makefile @@ -57,6 +57,9 @@ CFLAGS_BASE_DRIVER += -Wno-unused-variable ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) ifeq ($(shell test $(GCC_VERSION) -ge 60 && echo 1), 1) CFLAGS_BASE_DRIVER += -Wno-misleading-indentation +ifeq ($(shell test $(GCC_VERSION) -ge 70 && echo 1), 1) +CFLAGS_BASE_DRIVER += -Wno-implicit-fallthrough +endif endif endif endif diff --git a/drivers/net/fm10k/Makefile b/drivers/net/fm10k/Makefile index a8e8136..e0024f0 100644 --- a/drivers/net/fm10k/Makefile +++ b/drivers/net/fm10k/Makefile @@ -71,6 +71,9 @@ CFLAGS_BASE_DRIVER += -Wno-missing-field-initializers ifeq ($(shell test $(GCC_VERSION) -ge 44 && echo 1), 1) CFLAGS += -Wno-deprecated CFLAGS_BASE_DRIVER += -Wno-unused-but-set-variable +ifeq ($(shell test $(GCC_VERSION) -ge 70 && echo 1), 1) +CFLAGS_BASE_DRIVER += -Wno-implicit-fallthrough +endif endif endif diff --git a/drivers/net/ixgbe/Makefile b/drivers/net/ixgbe/Makefile index 0a6b7f2..5529d81 100644 --- a/drivers/net/ixgbe/Makefile +++ b/drivers/net/ixgbe/Makefile @@ -76,6 +76,9 @@ endif ifeq ($(shell test $(GCC_VERSION) -ge 50 && echo 1), 1) CFLAGS_ixgbe_common.o += -Wno-logical-not-parentheses +ifeq ($(shell test $(GCC_VERSION) -ge 70 && echo 1), 1) +CFLAGS_BASE_DRIVER += -Wno-implicit-fallthrough +endif endif endif diff --git a/drivers/net/qede/Makefile b/drivers/net/qede/Makefile index 8acef00..3323914 100644 --- a/drivers/net/qede/Makefile +++ b/drivers/net/qede/Makefile @@ -56,6 +56,9 @@ endif CFLAGS_BASE_DRIVER += -Wno-strict-prototypes ifeq ($(shell test $(GCC_VERSION) -ge 60 && echo 1), 1) CFLAGS_BASE_DRIVER += -Wno-shift-negative-value +ifeq ($(shell test $(GCC_VERSION) -ge 70 && echo 1), 1) +CFLAGS_BASE_DRIVER += -Wno-implicit-fallthrough +endif endif else ifeq ($(CONFIG_RTE_TOOLCHAIN_CLANG),y) CFLAGS_BASE_DRIVER += -Wno-format-extra-args -- 2.9.3
[dpdk-dev] [PATCH 01/10] mk: adjust gcc flags for new gcc 7 warnings
There are two new warnings in GCC 7 that cause problems in the DPDK compile. 1. GCC now warns if you have a switch fall-through without a suitable comment indicating that it was intentional. The compiler supports a number of levels of warning which are triggered depending on the type of message used, with level 3 being the default. To accept a wider range of possible fall-through messages, we adjust this down to level 2. 2. GCC also warns about an snprintf where there may be truncation and the return value is not checked. Given that we often use snprintf in DPDK in place of strncpy, and in many cases where truncation is not a problem, we can just disable this particular warning. Signed-off-by: Bruce Richardson --- mk/toolchain/gcc/rte.vars.mk | 7 +++ 1 file changed, 7 insertions(+) diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk index 5caa600..3834e00 100644 --- a/mk/toolchain/gcc/rte.vars.mk +++ b/mk/toolchain/gcc/rte.vars.mk @@ -99,5 +99,12 @@ ifeq ($(shell test $(GCC_VERSION) -lt 47 && echo 1), 1) WERROR_FLAGS += -Wno-uninitialized endif +ifeq ($(shell test $(GCC_VERSION) -gt 70 && echo 1), 1) +# Tell GCC only to error for switch fallthroughs without a suitable comment +WERROR_FLAGS += -Wimplicit-fallthrough=2 +# Ignore errors for snprintf truncation +WERROR_FLAGS += -Wno-format-truncation +endif + export CC AS AR LD OBJCOPY OBJDUMP STRIP READELF export TOOLCHAIN_CFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS -- 2.9.3
[dpdk-dev] [PATCH 03/10] net/bnx2x: fix warnings about switch fall-through
Add in a comment for each switch fall-through indicating that it is
intentional. This will fix compiler warnings with GCC 7.
Fixes: b5bf7719221d ("bnx2x: driver support routines")
Signed-off-by: Bruce Richardson
---
drivers/net/bnx2x/ecore_sp.c | 2 +-
drivers/net/bnx2x/elink.c| 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bnx2x/ecore_sp.c b/drivers/net/bnx2x/ecore_sp.c
index e6fecd8..22f2dc9 100644
--- a/drivers/net/bnx2x/ecore_sp.c
+++ b/drivers/net/bnx2x/ecore_sp.c
@@ -2725,7 +2725,7 @@ static int ecore_mcast_validate_e2(__rte_unused struct
bnx2x_softc *sc,
/* DEL command deletes all currently configured MACs */
case ECORE_MCAST_CMD_DEL:
o->set_registry_size(o, 0);
- /* Don't break */
+ /* fall-through */
/* RESTORE command will restore the entire multicast
configuration */
case ECORE_MCAST_CMD_RESTORE:
diff --git a/drivers/net/bnx2x/elink.c b/drivers/net/bnx2x/elink.c
index 5329396..9ffa7dc 100644
--- a/drivers/net/bnx2x/elink.c
+++ b/drivers/net/bnx2x/elink.c
@@ -5898,6 +5898,7 @@ elink_status_t elink_set_led(struct elink_params *params,
*/
if (!vars->link_up)
break;
+ /* fall-through */
case ELINK_LED_MODE_ON:
if (((params->phy[ELINK_EXT_PHY1].type ==
PORT_HW_CFG_XGXS_EXT_PHY_TYPE_BNX2X8727) ||
@@ -11534,11 +11535,13 @@ static void elink_phy_def_cfg(struct elink_params
*params,
switch (link_config & PORT_FEATURE_LINK_SPEED_MASK) {
case PORT_FEATURE_LINK_SPEED_10M_HALF:
phy->req_duplex = DUPLEX_HALF;
+ /* fall-through */
case PORT_FEATURE_LINK_SPEED_10M_FULL:
phy->req_line_speed = ELINK_SPEED_10;
break;
case PORT_FEATURE_LINK_SPEED_100M_HALF:
phy->req_duplex = DUPLEX_HALF;
+ /* fall-through */
case PORT_FEATURE_LINK_SPEED_100M_FULL:
phy->req_line_speed = ELINK_SPEED_100;
break;
--
2.9.3
[dpdk-dev] [PATCH 04/10] net/ixgbe: fix gcc 7 warning for switch fallthrough
Add a comment documenting explicitly that we are falling through the case
statements to the next one.
Fixes: f9072f8b90bb ("ixgbe: migrate flow director filtering to new API")
Signed-off-by: Bruce Richardson
---
drivers/net/ixgbe/ixgbe_fdir.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ixgbe/ixgbe_fdir.c b/drivers/net/ixgbe/ixgbe_fdir.c
index d6e48e9..7f6c7b5 100644
--- a/drivers/net/ixgbe/ixgbe_fdir.c
+++ b/drivers/net/ixgbe/ixgbe_fdir.c
@@ -730,6 +730,7 @@ ixgbe_fdir_filter_to_atr_input(const struct
rte_eth_fdir_filter *fdir_filter,
fdir_filter->input.flow.udp4_flow.src_port;
input->formatted.dst_port =
fdir_filter->input.flow.udp4_flow.dst_port;
+ /* fall-through */
/*for SCTP flow type, port and verify_tag are meaningless in ixgbe.*/
case RTE_ETH_FLOW_NONFRAG_IPV4_SCTP:
case RTE_ETH_FLOW_NONFRAG_IPV4_OTHER:
@@ -745,6 +746,7 @@ ixgbe_fdir_filter_to_atr_input(const struct
rte_eth_fdir_filter *fdir_filter,
fdir_filter->input.flow.udp6_flow.src_port;
input->formatted.dst_port =
fdir_filter->input.flow.udp6_flow.dst_port;
+ /* fall-through */
/*for SCTP flow type, port and verify_tag are meaningless in ixgbe.*/
case RTE_ETH_FLOW_NONFRAG_IPV6_SCTP:
case RTE_ETH_FLOW_NONFRAG_IPV6_OTHER:
--
2.9.3
[dpdk-dev] [PATCH 05/10] net/vmxnet3: fix compile error with gcc 7
GCC 7 flags a value as uninitialized before used. While it's a false
positive, there is little harm in providing an initial value for the
variable.
Fixes: bb1d14b87fc3 ("vmxnet3: fix link state handling")
Signed-off-by: Bruce Richardson
---
drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 0e8eb75..1cd72c1 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -935,7 +935,7 @@ vmxnet3_dev_link_update(struct rte_eth_dev *dev,
__rte_unused int wait_to_complete)
{
struct vmxnet3_hw *hw = dev->data->dev_private;
- struct rte_eth_link old, link;
+ struct rte_eth_link old = {0}, link;
uint32_t ret;
/* Link status doesn't change for stopped dev */
--
2.9.3
[dpdk-dev] [PATCH 06/10] lib: fix gcc 7 warnings for switch fall-through
With GCC 7 we need to explicitly document when we are falling through from
one switch case to another.
Fixes: af75078fece3 ("first public release")
Fixes: 8bae1da2afe0 ("hash: fallback to software CRC32 implementation")
Fixes: 9ec201f5d6e7 ("mbuf: provide bulk allocation")
Signed-off-by: Bruce Richardson
---
lib/librte_cmdline/cmdline_parse_num.c | 4 ++--
lib/librte_hash/rte_hash_crc.h | 6 ++
lib/librte_mbuf/rte_mbuf.h | 4
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/lib/librte_cmdline/cmdline_parse_num.c
b/lib/librte_cmdline/cmdline_parse_num.c
index b0f9a35..e507ec4 100644
--- a/lib/librte_cmdline/cmdline_parse_num.c
+++ b/lib/librte_cmdline/cmdline_parse_num.c
@@ -250,7 +250,7 @@ cmdline_parse_num(cmdline_parse_token_hdr_t *tk, const char
*srcbuf, void *res,
case HEX:
st = HEX_OK;
- /* no break */
+ /* fall-through no break */
case HEX_OK:
if (c >= '0' && c <= '9') {
if (add_to_res(c - '0', &res1, 16) < 0)
@@ -282,7 +282,7 @@ cmdline_parse_num(cmdline_parse_token_hdr_t *tk, const char
*srcbuf, void *res,
case BIN:
st = BIN_OK;
- /* no break */
+ /* fall-through */
case BIN_OK:
if (c >= '0' && c <= '1') {
if (add_to_res(c - '0', &res1, 2) < 0)
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h
index 63e74aa..0f485b8 100644
--- a/lib/librte_hash/rte_hash_crc.h
+++ b/lib/librte_hash/rte_hash_crc.h
@@ -476,9 +476,15 @@ rte_hash_crc_set_alg(uint8_t alg)
case CRC32_SSE42_x64:
if (! rte_cpu_get_flag_enabled(RTE_CPUFLAG_EM64T))
alg = CRC32_SSE42;
+#if __GNUC__ >= 7
+ __attribute__ ((fallthrough));
+#endif
case CRC32_SSE42:
if (! rte_cpu_get_flag_enabled(RTE_CPUFLAG_SSE4_2))
alg = CRC32_SW;
+#if __GNUC__ >= 7
+ __attribute__ ((fallthrough));
+#endif
#endif
case CRC32_SW:
crc32_alg = alg;
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 466ec00..9097f18 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -1156,21 +1156,25 @@ static inline int rte_pktmbuf_alloc_bulk(struct
rte_mempool *pool,
rte_mbuf_refcnt_set(mbufs[idx], 1);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
+ /* fall-through */
case 3:
RTE_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
rte_mbuf_refcnt_set(mbufs[idx], 1);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
+ /* fall-through */
case 2:
RTE_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
rte_mbuf_refcnt_set(mbufs[idx], 1);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
+ /* fall-through */
case 1:
RTE_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
rte_mbuf_refcnt_set(mbufs[idx], 1);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
+ /* fall-through */
}
}
return 0;
--
2.9.3
[dpdk-dev] [PATCH 07/10] net: fix missing break inside conditional compile block
The #ifdef only had the break in the else leg rather than in the first leg,
leading to the value set their being overridden on fall-through.
Fixes: 986ff526fb84 ("net: add CRC computation API")
Signed-off-by: Bruce Richardson
---
lib/librte_net/rte_net_crc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_net/rte_net_crc.c b/lib/librte_net/rte_net_crc.c
index e8326fe..9d1ee63 100644
--- a/lib/librte_net/rte_net_crc.c
+++ b/lib/librte_net/rte_net_crc.c
@@ -167,8 +167,8 @@ rte_net_crc_set_alg(enum rte_net_crc_alg alg)
handlers = handlers_sse42;
#else
alg = RTE_NET_CRC_SCALAR;
- break;
#endif
+ break;
case RTE_NET_CRC_SCALAR:
default:
handlers = handlers_scalar;
--
2.9.3
[dpdk-dev] [PATCH 09/10] test/test: fix missing break in switch
Issue flagged by GCC 7 as a switch fall-through.
Fixes: dbb860e03eb1 ("cmdline: tests")
CC: sta...@dpdk.org
Signed-off-by: Bruce Richardson
---
test/test/test_cmdline_num.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/test/test/test_cmdline_num.c b/test/test/test_cmdline_num.c
index 04263d3..e8f60cf 100644
--- a/test/test/test_cmdline_num.c
+++ b/test/test/test_cmdline_num.c
@@ -315,6 +315,7 @@ can_parse_signed(int64_t expected_result, enum
cmdline_numtype type)
case UINT64:
if (expected_result < 0)
return 0;
+ break;
case INT8:
if (expected_result > INT8_MAX || expected_result < INT8_MIN)
return 0;
--
2.9.3
[dpdk-dev] [PATCH 08/10] app/testpmd: document explicit switch fall-through
This fixes compiler warnings with GCC 7.
Fixes: 28d62131a1b1 ("app/testpmd: extend flow director input set commands")
Signed-off-by: Bruce Richardson
---
app/test-pmd/cmdline.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 06c1ce2..0afac68 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -8741,6 +8741,7 @@ cmd_flow_director_filter_parsed(void *parsed_result,
case RTE_ETH_FLOW_FRAG_IPV4:
case RTE_ETH_FLOW_NONFRAG_IPV4_OTHER:
entry.input.flow.ip4_flow.proto = res->proto_value;
+ /* fall-through */
case RTE_ETH_FLOW_NONFRAG_IPV4_UDP:
case RTE_ETH_FLOW_NONFRAG_IPV4_TCP:
IPV4_ADDR_TO_UINT(res->ip_dst,
@@ -8773,6 +8774,7 @@ cmd_flow_director_filter_parsed(void *parsed_result,
case RTE_ETH_FLOW_FRAG_IPV6:
case RTE_ETH_FLOW_NONFRAG_IPV6_OTHER:
entry.input.flow.ipv6_flow.proto = res->proto_value;
+ /* fall-through */
case RTE_ETH_FLOW_NONFRAG_IPV6_UDP:
case RTE_ETH_FLOW_NONFRAG_IPV6_TCP:
IPV6_ADDR_TO_ARRAY(res->ip_dst,
--
2.9.3
[dpdk-dev] [PATCH 10/10] test/test: fix gcc 7 compiler error
GCC flags an uninitialized value, so provide an initializer.
Fixes: 3a17ff401f1e ("test/eventdev: add basic SW tests")
Signed-off-by: Bruce Richardson
---
test/test/test_eventdev_sw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/test/test_eventdev_sw.c b/test/test/test_eventdev_sw.c
index fd6447e..3abeaef 100644
--- a/test/test/test_eventdev_sw.c
+++ b/test/test/test_eventdev_sw.c
@@ -2526,7 +2526,7 @@ parallel_basic(struct test *t, int check_order)
int i;
uint32_t deq_pkts, j;
struct rte_mbuf *mbufs[3];
- struct rte_mbuf *mbufs_out[3];
+ struct rte_mbuf *mbufs_out[3] = {0};
const uint32_t MAGIC_SEQN = 1234;
/* Create instance with 4 ports */
--
2.9.3
[dpdk-dev] [PATCH] doc: announce API changes in crypto library
API changes are planned for 17.08 to made sessions agnostic to the
underlaying devices, removing coupling with crypto PMDs, so a single
session can be used on multiple devices.
It requires to change "struct rte_cryptodev_sym_session" to store more
than one private data for devices, as well as remove redundant dev_id
and dev_type.
Effected public functions:
- rte_cryptodev_sym_session_pool_create
- rte_cryptodev_sym_session_create
- rte_cryptodev_sym_session_free
While session will not be directly associated with device, followed API
will be changed adding uint8_t dev_id to the argument list:
- rte_cryptodev_queue_pair_attach_sym_session
- rte_cryptodev_queue_pair_detach_sym_session
Signed-off-by: Tomasz Kulasek
---
Detailed list of changes and scope of work is sent in the separate RFC:
http://dpdk.org/dev/patchwork/patch/24091/ ("[dpdk-dev,RFC] cryptodev:
make crypto session device independent")
doc/guides/rel_notes/deprecation.rst | 21 +
1 file changed, 21 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index a3e7c72..5527c20 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -81,3 +81,24 @@ Deprecation Notices
- ``rte_crpytodev_scheduler_mode_get``, replaced by
``rte_cryptodev_scheduler_mode_get``
- ``rte_crpytodev_scheduler_mode_set``, replaced by
``rte_cryptodev_scheduler_mode_set``
+
+* cryptodev: API changes are planned for 17.08 for the sessions management
+ to make it agnostic to the underlying devices, removing coupling with
+ crypto PMDs, so a single session can be used on multiple devices.
+
+ - ``struct rte_cryptodev_sym_session``, dev_id, dev_type will be removed,
+_private field changed to the indirect array of private data pointers of
+all supported devices
+
+ An API of followed functions will be changed to allow operate on multiple
+ devices with one session:
+
+ - ``rte_cryptodev_sym_session_create``
+ - ``rte_cryptodev_sym_session_free``
+ - ``rte_cryptodev_sym_session_pool_create``
+
+ While dev_id will not be stored in the ``struct rte_cryptodev_sym_session``,
+ directly, the change of followed API is required:
+
+ - ``rte_cryptodev_queue_pair_attach_sym_session``
+ - ``rte_cryptodev_queue_pair_detach_sym_session``
\ No newline at end of file
--
1.9.1
[dpdk-dev] [PATCH] net/null: do not touch mbuf next or nb segs on Rx
mbuf next and nb_segs fields already have the default values when get
from mempool, no need to update them in PMD.
See: 8f094a9ac5d7 ("mbuf: set mbuf fields while in pool")
Signed-off-by: Ferruh Yigit
---
Cc: Olivier Matz
---
drivers/net/null/rte_eth_null.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index abf3ec7..2c94339 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -139,8 +139,6 @@ eth_null_copy_rx(void *q, struct rte_mbuf **bufs, uint16_t
nb_bufs)
packet_size);
bufs[i]->data_len = (uint16_t)packet_size;
bufs[i]->pkt_len = packet_size;
- bufs[i]->nb_segs = 1;
- bufs[i]->next = NULL;
bufs[i]->port = h->internals->port_id;
}
--
2.9.3
[dpdk-dev] [PATCH] eal: remove forward declaration of generic driver
We can just move rte_driver definition before rte_device
(which depends on rte_driver).
Signed-off-by: Thomas Monjalon
---
lib/librte_eal/common/include/rte_dev.h | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_dev.h
b/lib/librte_eal/common/include/rte_dev.h
index b63d0540d..759059889 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -123,8 +123,14 @@ struct rte_mem_resource {
void *addr; /**< Virtual address, NULL when not mapped. */
};
-/* Forward declaration */
-struct rte_driver;
+/**
+ * A structure describing a device driver.
+ */
+struct rte_driver {
+ TAILQ_ENTRY(rte_driver) next; /**< Next in list. */
+ const char *name; /**< Driver name. */
+ const char *alias; /**< Driver alias. */
+};
/**
* A structure describing a generic device.
@@ -138,15 +144,6 @@ struct rte_device {
};
/**
- * A structure describing a device driver.
- */
-struct rte_driver {
- TAILQ_ENTRY(rte_driver) next; /**< Next in list. */
- const char *name; /**< Driver name. */
- const char *alias; /**< Driver alias. */
-};
-
-/**
* Initialize a driver specified by name.
*
* @param name
--
2.12.2
[dpdk-dev] [PATCH] net/ixgbe: do not touch mbuf initialized fields
See: 8f094a9ac5d7 ("mbuf: set mbuf fields while in pool")
Signed-off-by: Ferruh Yigit
---
Cc: Olivier Matz
---
drivers/net/ixgbe/ixgbe_rxtx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 1e07895..590ab63 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -4111,10 +4111,7 @@ ixgbe_alloc_rx_queue_mbufs(struct ixgbe_rx_queue *rxq)
return -ENOMEM;
}
- rte_mbuf_refcnt_set(mbuf, 1);
- mbuf->next = NULL;
mbuf->data_off = RTE_PKTMBUF_HEADROOM;
- mbuf->nb_segs = 1;
mbuf->port = rxq->port_id;
dma_addr =
--
2.9.3
[dpdk-dev] [PATCH 0/2] prepare function names for bus move
It is planned to move the bus PCI and VDEV to /drivers/bus/ during 17.08. So the eal_ prefix will not make sense. Let's rename now before releasing 17.05 where EAL API has already some breaking changes. Thomas Monjalon (2): pci: remove eal prefix vdev: remove eal prefix app/test-pmd/testpmd.c | 2 +- doc/guides/cryptodevs/aesni_gcm.rst| 4 +- doc/guides/cryptodevs/aesni_mb.rst | 4 +- doc/guides/cryptodevs/kasumi.rst | 4 +- doc/guides/cryptodevs/null.rst | 4 +- doc/guides/cryptodevs/scheduler.rst| 4 +- doc/guides/cryptodevs/snow3g.rst | 4 +- doc/guides/cryptodevs/zuc.rst | 4 +- doc/guides/eventdevs/octeontx.rst | 4 +- doc/guides/eventdevs/sw.rst| 4 +- doc/guides/prog_guide/cryptodev_lib.rst| 4 +- .../sample_app_ug/l2_forward_real_virtual.rst | 4 +- doc/guides/sample_app_ug/link_status_intr.rst | 4 +- doc/guides/sample_app_ug/multi_process.rst | 2 +- doc/guides/sample_app_ug/netmap_compatibility.rst | 2 +- doc/guides/sample_app_ug/quota_watermark.rst | 4 +- drivers/net/bnx2x/bnx2x.h | 6 +- drivers/net/bonding/rte_eth_bond_api.c | 4 +- drivers/net/cxgbe/base/adapter.h | 10 +-- drivers/net/i40e/i40e_ethdev.c | 6 +- drivers/net/mlx4/mlx4.c| 2 +- drivers/net/mlx5/mlx5.c| 2 +- drivers/net/virtio/virtio_ethdev.c | 10 +-- drivers/net/virtio/virtio_pci.c| 81 ++ drivers/net/virtio/virtio_user_ethdev.c| 2 +- lib/librte_cryptodev/rte_cryptodev.c | 6 +- lib/librte_eal/bsdapp/eal/eal_pci.c| 40 +-- lib/librte_eal/bsdapp/eal/rte_eal_version.map | 38 +- lib/librte_eal/common/eal_common_dev.c | 8 +-- lib/librte_eal/common/eal_common_pci.c | 42 +-- lib/librte_eal/common/eal_common_vdev.c| 8 +-- lib/librte_eal/common/eal_private.h| 8 +-- lib/librte_eal/common/include/rte_dev.h| 4 +- lib/librte_eal/common/include/rte_pci.h| 46 ++-- lib/librte_eal/common/include/rte_vdev.h | 6 +- lib/librte_eal/linuxapp/eal/eal_pci.c | 38 +- lib/librte_eal/linuxapp/eal/rte_eal_version.map| 38 +- lib/librte_eventdev/rte_eventdev.c | 4 +- test/test/test_cryptodev.c | 20 +++--- test/test/test_cryptodev_perf.c| 10 +-- test/test/test_eventdev.c | 2 +- test/test/test_eventdev_octeontx.c | 2 +- test/test/test_eventdev_sw.c | 2 +- test/test/test_link_bonding_rssconf.c | 2 +- 44 files changed, 250 insertions(+), 255 deletions(-) -- 2.12.2
[dpdk-dev] [PATCH 1/2] pci: remove eal prefix
The PCI code will move to the bus drivers directory.
Rename functions from rte_eal_pci_ to rte_pci_
to prepare the move of the driver out of EAL.
Signed-off-by: Thomas Monjalon
---
app/test-pmd/testpmd.c | 2 +-
.../sample_app_ug/l2_forward_real_virtual.rst | 4 +-
doc/guides/sample_app_ug/link_status_intr.rst | 4 +-
doc/guides/sample_app_ug/multi_process.rst | 2 +-
doc/guides/sample_app_ug/netmap_compatibility.rst | 2 +-
doc/guides/sample_app_ug/quota_watermark.rst | 4 +-
drivers/net/bnx2x/bnx2x.h | 6 +-
drivers/net/cxgbe/base/adapter.h | 10 +--
drivers/net/i40e/i40e_ethdev.c | 6 +-
drivers/net/mlx4/mlx4.c| 2 +-
drivers/net/mlx5/mlx5.c| 2 +-
drivers/net/virtio/virtio_ethdev.c | 10 +--
drivers/net/virtio/virtio_pci.c| 81 ++
drivers/net/virtio/virtio_user_ethdev.c| 2 +-
lib/librte_cryptodev/rte_cryptodev.c | 4 +-
lib/librte_eal/bsdapp/eal/eal_pci.c| 40 +--
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 30
lib/librte_eal/common/eal_common_dev.c | 4 +-
lib/librte_eal/common/eal_common_pci.c | 42 +--
lib/librte_eal/common/eal_private.h| 8 +--
lib/librte_eal/common/include/rte_pci.h| 46 ++--
lib/librte_eal/linuxapp/eal/eal_pci.c | 38 +-
lib/librte_eal/linuxapp/eal/rte_eal_version.map| 30
lib/librte_eventdev/rte_eventdev.c | 4 +-
24 files changed, 189 insertions(+), 194 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index dfe64427d..cd1240b24 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1779,7 +1779,7 @@ rmv_event_callback(void *arg)
if (da->type == RTE_DEVTYPE_VIRTUAL)
snprintf(name, sizeof(name), "%s", da->virt.drv_name);
else if (da->type == RTE_DEVTYPE_WHITELISTED_PCI)
- rte_eal_pci_device_name(&da->pci.addr, name, sizeof(name));
+ rte_pci_device_name(&da->pci.addr, name, sizeof(name));
printf("removing device %s\n", name);
rte_eal_dev_detach(name);
dev->state = RTE_ETH_DEV_UNUSED;
diff --git a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
index 609c8f531..f579c8fe9 100644
--- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
+++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
@@ -238,7 +238,7 @@ in the *DPDK Programmer's Guide* - Rel 1.4 EAR and the
*DPDK API Reference*.
.. code-block:: c
-if (rte_eal_pci_probe() < 0)
+if (rte_pci_probe() < 0)
rte_exit(EXIT_FAILURE, "Cannot probe PCI\n");
nb_ports = rte_eth_dev_count();
@@ -279,7 +279,7 @@ Observe that:
* rte_igb_pmd_init_all() simultaneously registers the driver as a PCI driver
and as an Ethernet* Poll Mode Driver.
-* rte_eal_pci_probe() parses the devices on the PCI bus and initializes
recognized devices.
+* rte_pci_probe() parses the devices on the PCI bus and initializes
recognized devices.
The next step is to configure the RX and TX queues.
For each port, there is only one RX queue (only one lcore is able to poll a
given port).
diff --git a/doc/guides/sample_app_ug/link_status_intr.rst
b/doc/guides/sample_app_ug/link_status_intr.rst
index 5234bc083..f9af47492 100644
--- a/doc/guides/sample_app_ug/link_status_intr.rst
+++ b/doc/guides/sample_app_ug/link_status_intr.rst
@@ -138,7 +138,7 @@ To fully understand this code, it is recommended to study
the chapters that rela
.. code-block:: c
-if (rte_eal_pci_probe() < 0)
+if (rte_pci_probe() < 0)
rte_exit(EXIT_FAILURE, "Cannot probe PCI\n");
nb_ports = rte_eth_dev_count();
@@ -171,7 +171,7 @@ To fully understand this code, it is recommended to study
the chapters that rela
Observe that:
-* rte_eal_pci_probe() parses the devices on the PCI bus and initializes
recognized devices.
+* rte_pci_probe() parses the devices on the PCI bus and initializes
recognized devices.
The next step is to configure the RX and TX queues.
For each port, there is only one RX queue (only one lcore is able to poll a
given port).
diff --git a/doc/guides/sample_app_ug/multi_process.rst
b/doc/guides/sample_app_ug/multi_process.rst
index c0d441753..d4df2fa72 100644
--- a/doc/guides/sample_app_ug/multi_process.rst
+++ b/doc/guides/sample_app_ug/multi_process.rst
@@ -254,7 +254,7 @@ How the Application Works
^
The initialization calls in both the primary and secondary instances are the
same for the most part,
-calling the rte_eal_init(), 1 G and 10 G driver initialization and then
rte_eal_pci_probe() functions.
+calling the rte_eal_init(), 1 G and 10 G driver initi
[dpdk-dev] [PATCH 2/2] vdev: remove eal prefix
The VDEV code will move to the bus drivers directory.
Rename functions from rte_eal_vdev_ to rte_vdev_
to prepare the move of the driver out of EAL.
The prefix rte_eal_vdrv_ is also renamed to rte_vdev_.
It was used for registration of vdev drivers.
Signed-off-by: Thomas Monjalon
---
doc/guides/cryptodevs/aesni_gcm.rst | 4 ++--
doc/guides/cryptodevs/aesni_mb.rst | 4 ++--
doc/guides/cryptodevs/kasumi.rst| 4 ++--
doc/guides/cryptodevs/null.rst | 4 ++--
doc/guides/cryptodevs/scheduler.rst | 4 ++--
doc/guides/cryptodevs/snow3g.rst| 4 ++--
doc/guides/cryptodevs/zuc.rst | 4 ++--
doc/guides/eventdevs/octeontx.rst | 4 ++--
doc/guides/eventdevs/sw.rst | 4 ++--
doc/guides/prog_guide/cryptodev_lib.rst | 4 ++--
drivers/net/bonding/rte_eth_bond_api.c | 4 ++--
lib/librte_cryptodev/rte_cryptodev.c| 2 +-
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 8
lib/librte_eal/common/eal_common_dev.c | 4 ++--
lib/librte_eal/common/eal_common_vdev.c | 8
lib/librte_eal/common/include/rte_dev.h | 4 ++--
lib/librte_eal/common/include/rte_vdev.h| 6 +++---
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 8
test/test/test_cryptodev.c | 20 ++--
test/test/test_cryptodev_perf.c | 10 +-
test/test/test_eventdev.c | 2 +-
test/test/test_eventdev_octeontx.c | 2 +-
test/test/test_eventdev_sw.c| 2 +-
test/test/test_link_bonding_rssconf.c | 2 +-
24 files changed, 61 insertions(+), 61 deletions(-)
diff --git a/doc/guides/cryptodevs/aesni_gcm.rst
b/doc/guides/cryptodevs/aesni_gcm.rst
index ba9ecb5b4..84cdc52ab 100644
--- a/doc/guides/cryptodevs/aesni_gcm.rst
+++ b/doc/guides/cryptodevs/aesni_gcm.rst
@@ -67,9 +67,9 @@ In order to enable this virtual crypto PMD, user must:
To use the PMD in an application, user must:
-* Call rte_eal_vdev_init("crypto_aesni_gcm") within the application.
+* Call rte_vdev_init("crypto_aesni_gcm") within the application.
-* Use --vdev="crypto_aesni_gcm" in the EAL options, which will call
rte_eal_vdev_init() internally.
+* Use --vdev="crypto_aesni_gcm" in the EAL options, which will call
rte_vdev_init() internally.
The following parameters (all optional) can be provided in the previous two
calls:
diff --git a/doc/guides/cryptodevs/aesni_mb.rst
b/doc/guides/cryptodevs/aesni_mb.rst
index 1a0402325..ecb52a10d 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -113,9 +113,9 @@ In order to enable this virtual crypto PMD, user must:
To use the PMD in an application, user must:
-* Call rte_eal_vdev_init("crypto_aesni_mb") within the application.
+* Call rte_vdev_init("crypto_aesni_mb") within the application.
-* Use --vdev="crypto_aesni_mb" in the EAL options, which will call
rte_eal_vdev_init() internally.
+* Use --vdev="crypto_aesni_mb" in the EAL options, which will call
rte_vdev_init() internally.
The following parameters (all optional) can be provided in the previous two
calls:
diff --git a/doc/guides/cryptodevs/kasumi.rst b/doc/guides/cryptodevs/kasumi.rst
index bb8522b9e..bff9321e3 100644
--- a/doc/guides/cryptodevs/kasumi.rst
+++ b/doc/guides/cryptodevs/kasumi.rst
@@ -90,9 +90,9 @@ In order to enable this virtual crypto PMD, user must:
To use the PMD in an application, user must:
-* Call rte_eal_vdev_init("crypto_kasumi") within the application.
+* Call rte_vdev_init("crypto_kasumi") within the application.
-* Use --vdev="crypto_kasumi" in the EAL options, which will call
rte_eal_vdev_init() internally.
+* Use --vdev="crypto_kasumi" in the EAL options, which will call
rte_vdev_init() internally.
The following parameters (all optional) can be provided in the previous two
calls:
diff --git a/doc/guides/cryptodevs/null.rst b/doc/guides/cryptodevs/null.rst
index e712e2bd7..4a3bfdfd2 100644
--- a/doc/guides/cryptodevs/null.rst
+++ b/doc/guides/cryptodevs/null.rst
@@ -76,9 +76,9 @@ Initialization
To use the PMD in an application, user must:
-* Call rte_eal_vdev_init("crypto_null") within the application.
+* Call rte_vdev_init("crypto_null") within the application.
-* Use --vdev="crypto_null" in the EAL options, which will call
rte_eal_vdev_init() internally.
+* Use --vdev="crypto_null" in the EAL options, which will call rte_vdev_init()
internally.
The following parameters (all optional) can be provided in the previous two
calls:
diff --git a/doc/guides/cryptodevs/scheduler.rst
b/doc/guides/cryptodevs/scheduler.rst
index ddc02b4b8..32e565373 100644
--- a/doc/guides/cryptodevs/scheduler.rst
+++ b/doc/guides/cryptodevs/scheduler.rst
@@ -72,10 +72,10 @@ Initialization
To use the PMD in an application, user must:
-* Call rte_
Re: [dpdk-dev] [PATCH] [RFC] cryptodev: crypto operation restructuring
> -Original Message- > From: Akhil Goyal [mailto:akhil.go...@nxp.com] > Sent: Thursday, May 04, 2017 12:23 PM > To: Gonzalez Monroy, Sergio; De Lara Guarch, Pablo; dev@dpdk.org > Cc: Doherty, Declan; hemant.agra...@nxp.com; > zbigniew.bo...@caviumnetworks.com; jerin.ja...@caviumnetworks.com > Subject: Re: [PATCH] [RFC] cryptodev: crypto operation restructuring > > On 5/4/2017 1:49 PM, Sergio Gonzalez Monroy wrote: > > On 04/05/2017 08:38, Akhil Goyal wrote: > >> On 5/4/2017 1:01 PM, Sergio Gonzalez Monroy wrote: > >>> On 04/05/2017 07:09, Akhil Goyal wrote: > Hi Sergio, > > On 5/3/2017 7:48 PM, Sergio Gonzalez Monroy wrote: > > On 03/05/2017 12:01, Akhil Goyal wrote: > >> Hi Pablo, > >> > >> On 4/28/2017 11:33 PM, Pablo de Lara wrote: > >>> This is a proposal 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 as > >>> one of the goals. > >>> > >>> The following changes are proposed: > >>> > >>> In rte_crypto_op: > >>> > >>> - Move session type (with session/sessionless) from symmetric op > to > >>> crypto op, > >>> as this could be used for other types > >>> > >>> - Combine operation type, operation status and session type into > a > >>> 64-bit flag (each one taking 1 byte), > >>> instead of having enums taking 4 bytes each > >> [Akhil] wouldn't this be a problem? Bit fields create endianness > >> issues. Can we have uint8_t for each of the field. > > > > Sure, as it is proposed it would be the same as having 3 uint8_t > > fields. > > The idea was to possibly compact those fields (ie. we do not need 8 > > bits > > for sess_type) to make better use of the bits and add asym fields > > there > > if needed. > > > > I don't think bitfields would be a problem in this case. Agree, we > > should not use both bitmask and bitfields, but we would use just > > bitfields. > > Can you elaborate on the issue you see? > > > > Regards, > > Sergio > > > > The problem will come when we run on systems with different > endianness. The bit field positioning will be different for LE and BE. > It would be like in LE > uint64_t type:8; > uint64_t status:8; > uint64_t sess_type:8; > uint64_t reserved:40; > > and on BE it would be > uint64_t reserved:40; > uint64_t sess_type:8; > uint64_t status:8; > uint64_t type:8; > > So it would be better to use uint8_t for each of the field. > >>> > >>> Understood, but why is that an issue? Those fields are used by > >>> application code and PMD, same system. > >>> Do you have a use case where you are offloading crypto ops to a > >>> different arch/system? > >>> > >>> Sergio > >> same application may run on LE or BE machines. So if we use masks for > >> accessing these fields and take the complete field as uint64_t, then > >> LE and BE machine would interpret it differently as the code is same. > >> > > > > Right, either you use bitfields or you define macros and work on the > > complete uint64_t. The proposal here was to just use bitfields and for > > the given use case it would not be an issue while IMHO allowing better > > packing and readability than defining each field as a Byte. > > > > Anyway, if you feel strongly against bitfields, we can just define it as > > uint8_t as you suggest or single uint64_t with macros. > > > > Sergio > > > > I am not against bitfields. But we should take care of the endianness > using the compile time flags for byte ordering or we can use the uint8_t. > I am ok with both. > > Thanks, > Akhil > > >> Akhil > >>> > > >>> > >>> - Remove opaque data from crypto operation, as private data can > be > >>> allocated > >>> just after the symmetric (or other type) crypto operation > >>> > >>> - Modify symmetric operation pointer to zero-array, as the > symmetric > >>> op should be always after the crypto operation > >>> > >>> In rte_crypto_sym_xform: > >>> > >>> - Remove AAD length from sym_xform (will be taken from > operation > >>> only) > >>> > >>> - Add IV length in sym_xform, so this length will be fixed for all > >>> the operations in a session > >> A much needed change. This would remove hard codings for iv > length > >> while configuring sessions. > >>> > >>> In rte_crypto_sym_op: > >>> > >>> - Separate IV from cipher structure in symmetric crypto > >>> operation, as > >>> it is also used in authentication, for some algorithms > >>> > >>> - Remove IV pointer and length from sym crypto op, and leave just > >>> the > >>> offset (from the beginning of the crypto operation), > >>> as the IV can resid
[dpdk-dev] [PATCH v2] app/testpmd: disable latency stats by default
Disable latency stats gathering by default,
so there is not performance degradation if user
is not interested in them.
Signed-off-by: Pablo de Lara
---
This patch depends on http://dpdk.org/dev/patchwork/patch/24064/
app/test-pmd/testpmd.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 776b8dd..0a4f15d 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -971,7 +971,8 @@ run_pkt_fwd_on_lcore(struct fwd_lcore *fc, packet_fwd_t
pkt_fwd)
}
#endif
#ifdef RTE_LIBRTE_LATENCY_STATS
- if (latencystats_lcore_id == rte_lcore_id())
+ if (latencystats_enabled != 0 &&
+ latencystats_lcore_id == rte_lcore_id())
rte_latencystats_update();
#endif
@@ -2238,10 +2239,13 @@ main(int argc, char** argv)
rte_panic("Empty set of forwarding logical cores - check the "
"core mask supplied in the command parameters\n");
- /* Bitrate stats disabled by default */
+ /* Bitrate/latency stats disabled by default */
#ifdef RTE_LIBRTE_BITRATE
bitrate_enabled = 0;
#endif
+#ifdef RTE_LIBRTE_LATENCY_STATS
+ latencystats_enabled = 0;
+#endif
argc -= diag;
argv += diag;
--
2.7.4
Re: [dpdk-dev] Occasional instability in RSS Hashes/Queues from X540 NIC
> On May 4, 2017, at 8:04 AM, Matt Laswell wrote: > > Hey Folks, > > I'm seeing some strange behavior with regard to the RSS hash values in my > applications and was hoping somebody might have some pointers on where to > look. In my application, I'm using RSS to divide work among multiple > cores, each of which services a single RX queue. When dealing with a > single long-lived TCP connection, I occasionally see packets going to the > wrong core. That is, almost all of the packets in the connection go to > core 5 in this case, but every once in a while, one goes to core 0 instead. > > Upon further investigation, I find two problems are occurring. The first > is that problem packets have the RSS hash value in the mbuf incorrectly set > to zero. They are therefore put in queue zero, where they are read by core > zero. Other packets from the same connection that occur immediately before > and after the packet in question have the correct hash value and therefore > go to a different core. The second problem is that we sometimes see > packets in which the RSS hash in the mbuf appears correct, but the packets > are incorrectly put into queue zero. As with the first, this results in > the wrong core getting the packet. Either one of these confuses the state > tracking we're doing per-core. > > A few details: > > - Using an Intel X540-AT2 NIC and the igb_uio driver > - DPDK 16.04 > - A particular packet in our workflow always encounters this problem. > - Retransmissions of the packet in question also encounter the problem > - The packet is IPv4, with header length of 20 (so no options), no > fragmentation. > - The only differences I can see in the IP header between packets that > get the right hash value and those that get the wrong one are in the IP ID, > total length, and checksum fields. > - Using ETH_RSS_IPV4 > - The packet is TCP with about 100 bytes of payload - it's not a jumbo > or a runt > - We fill the key in with 0x6d5a to get symmetric hashing of both sides > of the connection > - We only configure RSS information at boot; things like the key or > header fields are not being changed dynamically > - Traffic load is light when the problem occurs > > Is anybody aware of an errata, either in the NIC or the PMD's configuration > of it that might explain something like this? Failing that, if you ran > into this sort of behavior, how would you approach finding the reason for > the error? Every failure mode I can think of would tend to affect all of > the packets in the connection consistently, even if incorrectly. Just to add more information to this email, can you provide hexdumps of the packets to help someone maybe spot the problem? Need the previous OK packet plus the one after it and the failing packets you are seeing. I do not know why this is happening as I do not know of any errata to explain this issue. > > Thanks in advance for any ideas. > > -- > Matt Laswell > lasw...@infinite.io Regards, Keith
Re: [dpdk-dev] [PATCH 01/10] mk: adjust gcc flags for new gcc 7 warnings
On Thu, 4 May 2017 16:38:13 +0100 Bruce Richardson wrote: > There are two new warnings in GCC 7 that cause problems in the DPDK > compile. > > 1. GCC now warns if you have a switch fall-through without a suitable > comment indicating that it was intentional. The compiler supports a number > of levels of warning which are triggered depending on the type of message > used, with level 3 being the default. To accept a wider range of possible > fall-through messages, we adjust this down to level 2. > > 2. GCC also warns about an snprintf where there may be truncation and the > return value is not checked. Given that we often use snprintf in DPDK in > place of strncpy, and in many cases where truncation is not a problem, we > can just disable this particular warning. > > Signed-off-by: Bruce Richardson > --- > mk/toolchain/gcc/rte.vars.mk | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk > index 5caa600..3834e00 100644 > --- a/mk/toolchain/gcc/rte.vars.mk > +++ b/mk/toolchain/gcc/rte.vars.mk > @@ -99,5 +99,12 @@ ifeq ($(shell test $(GCC_VERSION) -lt 47 && echo 1), 1) > WERROR_FLAGS += -Wno-uninitialized > endif > > +ifeq ($(shell test $(GCC_VERSION) -gt 70 && echo 1), 1) > +# Tell GCC only to error for switch fallthroughs without a suitable comment > +WERROR_FLAGS += -Wimplicit-fallthrough=2 > +# Ignore errors for snprintf truncation > +WERROR_FLAGS += -Wno-format-truncation > +endif > + > export CC AS AR LD OBJCOPY OBJDUMP STRIP READELF > export TOOLCHAIN_CFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS Please fix the code not neuter warnings
Re: [dpdk-dev] [PATCH 05/10] net/vmxnet3: fix compile error with gcc 7
On Thu, 4 May 2017 16:38:17 +0100
Bruce Richardson wrote:
> diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
> b/drivers/net/vmxnet3/vmxnet3_ethdev.c
> index 0e8eb75..1cd72c1 100644
> --- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
> +++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
> @@ -935,7 +935,7 @@ vmxnet3_dev_link_update(struct rte_eth_dev *dev,
> __rte_unused int wait_to_complete)
> {
> struct vmxnet3_hw *hw = dev->data->dev_private;
> - struct rte_eth_link old, link;
> + struct rte_eth_link old = {0}, link;
Please add space around the initializer.
ie.
struct rte_eth_link old = { 0 }, link;
Re: [dpdk-dev] [PATCH 0/2] prepare function names for bus move
On Thu, 4 May 2017 18:18:49 +0200 Thomas Monjalon wrote: > It is planned to move the bus PCI and VDEV to /drivers/bus/ > during 17.08. So the eal_ prefix will not make sense. > Let's rename now before releasing 17.05 where EAL API has > already some breaking changes. > > Thomas Monjalon (2): > pci: remove eal prefix > vdev: remove eal prefix > > app/test-pmd/testpmd.c | 2 +- > doc/guides/cryptodevs/aesni_gcm.rst| 4 +- > doc/guides/cryptodevs/aesni_mb.rst | 4 +- > doc/guides/cryptodevs/kasumi.rst | 4 +- > doc/guides/cryptodevs/null.rst | 4 +- > doc/guides/cryptodevs/scheduler.rst| 4 +- > doc/guides/cryptodevs/snow3g.rst | 4 +- > doc/guides/cryptodevs/zuc.rst | 4 +- > doc/guides/eventdevs/octeontx.rst | 4 +- > doc/guides/eventdevs/sw.rst| 4 +- > doc/guides/prog_guide/cryptodev_lib.rst| 4 +- > .../sample_app_ug/l2_forward_real_virtual.rst | 4 +- > doc/guides/sample_app_ug/link_status_intr.rst | 4 +- > doc/guides/sample_app_ug/multi_process.rst | 2 +- > doc/guides/sample_app_ug/netmap_compatibility.rst | 2 +- > doc/guides/sample_app_ug/quota_watermark.rst | 4 +- > drivers/net/bnx2x/bnx2x.h | 6 +- > drivers/net/bonding/rte_eth_bond_api.c | 4 +- > drivers/net/cxgbe/base/adapter.h | 10 +-- > drivers/net/i40e/i40e_ethdev.c | 6 +- > drivers/net/mlx4/mlx4.c| 2 +- > drivers/net/mlx5/mlx5.c| 2 +- > drivers/net/virtio/virtio_ethdev.c | 10 +-- > drivers/net/virtio/virtio_pci.c| 81 > ++ > drivers/net/virtio/virtio_user_ethdev.c| 2 +- > lib/librte_cryptodev/rte_cryptodev.c | 6 +- > lib/librte_eal/bsdapp/eal/eal_pci.c| 40 +-- > lib/librte_eal/bsdapp/eal/rte_eal_version.map | 38 +- > lib/librte_eal/common/eal_common_dev.c | 8 +-- > lib/librte_eal/common/eal_common_pci.c | 42 +-- > lib/librte_eal/common/eal_common_vdev.c| 8 +-- > lib/librte_eal/common/eal_private.h| 8 +-- > lib/librte_eal/common/include/rte_dev.h| 4 +- > lib/librte_eal/common/include/rte_pci.h| 46 ++-- > lib/librte_eal/common/include/rte_vdev.h | 6 +- > lib/librte_eal/linuxapp/eal/eal_pci.c | 38 +- > lib/librte_eal/linuxapp/eal/rte_eal_version.map| 38 +- > lib/librte_eventdev/rte_eventdev.c | 4 +- > test/test/test_cryptodev.c | 20 +++--- > test/test/test_cryptodev_perf.c| 10 +-- > test/test/test_eventdev.c | 2 +- > test/test/test_eventdev_octeontx.c | 2 +- > test/test/test_eventdev_sw.c | 2 +- > test/test/test_link_bonding_rssconf.c | 2 +- > 44 files changed, 250 insertions(+), 255 deletions(-) > Acked-by: Stephen Hemminger
Re: [dpdk-dev] [PATCH] doc: notice for changes in kni structures
On 5/3/2017 4:50 PM, Stephen Hemminger wrote: > On Wed, 3 May 2017 17:01:31 +0530 > Hemant Agrawal wrote: > >> Signed-off-by: Hemant Agrawal >> --- >> doc/guides/rel_notes/deprecation.rst | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/doc/guides/rel_notes/deprecation.rst >> b/doc/guides/rel_notes/deprecation.rst >> index a3e7c72..0c1ef2c 100644 >> --- a/doc/guides/rel_notes/deprecation.rst >> +++ b/doc/guides/rel_notes/deprecation.rst >> @@ -81,3 +81,10 @@ Deprecation Notices >> >>- ``rte_crpytodev_scheduler_mode_get``, replaced by >> ``rte_cryptodev_scheduler_mode_get`` >>- ``rte_crpytodev_scheduler_mode_set``, replaced by >> ``rte_cryptodev_scheduler_mode_set`` >> + >> +* kni: additional functionality is planned to be added in kni to support >> mtu, macaddr, >> + gso_size, promiscusity configuration. >> + some of the kni structure will be changed to support additional >> functionality >> + e.g ``rte_kni_request`` to support promiscusity`` and mac_addr, >> + ``rte_kni_mbu`` to support the configured gso_size, >> + ``rte_kni_device_info`` and ``rte_kni_conf`` to also support mtu and >> macaddr. > > Why are these exposed as something applications should care about? > The data structures in rte_kni_common.h are not an API +1, rte_kni_common.h is a contract between user - kernel space, not part of API.
Re: [dpdk-dev] [PATCH] doc: notice for changes in kni structures
On 5/3/2017 12:31 PM, Hemant Agrawal wrote: > Signed-off-by: Hemant Agrawal > --- > doc/guides/rel_notes/deprecation.rst | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index a3e7c72..0c1ef2c 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -81,3 +81,10 @@ Deprecation Notices > >- ``rte_crpytodev_scheduler_mode_get``, replaced by > ``rte_cryptodev_scheduler_mode_get`` >- ``rte_crpytodev_scheduler_mode_set``, replaced by > ``rte_cryptodev_scheduler_mode_set`` > + > +* kni: additional functionality is planned to be added in kni to support > mtu, macaddr, > + gso_size, promiscusity configuration. > + some of the kni structure will be changed to support additional > functionality > + e.g ``rte_kni_request`` to support promiscusity`` and mac_addr, rte_kni_request is between KNI library and KNI kernel module, shouldn't be part of API. > + ``rte_kni_mbu`` to support the configured gso_size, Again, rte_kni_mbuf should be only concern of KNI kernel module. > + ``rte_kni_device_info`` and ``rte_kni_conf`` to also support mtu and > macaddr. rte_kni_device_info also between KNI library and KNI kernel module. I think deprecation notice not required for above ones. But you KNI patchset updates rte_kni_conf and rte_kni_ops. These are part of KNI API and changing them cause ABI breakage, but if new fields appended in these structs, this will not cause an ABI breakage, and I think that is better to do instead of deprecation notice, what do you think? And apart from above ABI issues, adding new fields to "rte_kni_ops" means DPDK application that use KNI should implement them, right? So this suggest everyone require to set promiscuity of KNI device should implement this. Can't we find another way that all can benefit from a common implementation? Thanks, ferruh
Re: [dpdk-dev] Proposed schedule dates for DPDK 17.08, 17.11 and 18.02
Hi, The previous email had the 17.05 dates instead of the 17.08 dates due to an ENOC0FFEE error. Fixed 17.08 dates below. The current 17.08 schedule dates are: 17.08 * Proposal deadline:May 28, 2017 * Integration deadline: June 29, 2017 * Release: August1, 2017 http://dpdk.org/dev/roadmap#dates The following are proposed dates for 17.11 and 18.02. 17.11 * Proposal deadline:August25, 2017 * Integration deadline: September 29, 2017 * Release: November 2, 2017 18.02 * Proposal deadline:November 24, 2017 * Integration deadline: December 29, 2017 * Release: February 2, 2018 These dates need to be discussed/agreed in the community since there are a lot of different holidays in these periods: August holidays, Christmas, New Year, Spring Festival. John
[dpdk-dev] [PATCH 2/2] app/testpmd: fix MAC endian issue in flow command
MAC addresses are implicitly handled in network order since they are
actually byte strings, however this is not properly enforced with MAC masks
provided as prefix lengths, which end up inverted on little endian
systems.
Fixes: 6df81b325fa4 ("app/testpmd: add items eth/vlan to flow command")
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline_flow.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index e952c91..0fd69f9 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -1057,13 +1057,13 @@ static const struct token token_list[] = {
.name = "dst",
.help = "destination MAC",
.next = NEXT(item_eth, NEXT_ENTRY(MAC_ADDR), item_param),
- .args = ARGS(ARGS_ENTRY(struct rte_flow_item_eth, dst)),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_eth, dst)),
},
[ITEM_ETH_SRC] = {
.name = "src",
.help = "source MAC",
.next = NEXT(item_eth, NEXT_ENTRY(MAC_ADDR), item_param),
- .args = ARGS(ARGS_ENTRY(struct rte_flow_item_eth, src)),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_eth, src)),
},
[ITEM_ETH_TYPE] = {
.name = "type",
@@ -2238,6 +2238,9 @@ parse_mac_addr(struct context *ctx, const struct token
*token,
/* Bit-mask fill is not supported. */
if (arg->mask || size != sizeof(tmp))
goto error;
+ /* Only network endian is supported. */
+ if (!arg->hton)
+ goto error;
ret = cmdline_parse_etheraddr(NULL, str, &tmp, size);
if (ret < 0 || (unsigned int)ret != len)
goto error;
--
2.1.4
[dpdk-dev] [PATCH 1/2] app/testpmd: fix stack overwriting by flow command
The parameter type parser function stores a stack-local address in the
global parser context when parsing a "prefix" keyword.
This usually translates to "Bad arguments" errors even for correct flow
rules as stack gets overwritten by subsequent function calls.
Fixes: d3f61b7bad20 ("app/testpmd: add flow item spec prefix length")
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline_flow.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 0a40005..e952c91 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -1808,6 +1808,8 @@ parse_vc_spec(struct context *ctx, const struct token
*token,
return -1;
/* Parse parameter types. */
switch (ctx->curr) {
+ static const enum index prefix[] = NEXT_ENTRY(PREFIX);
+
case ITEM_PARAM_IS:
index = 0;
objmask = 1;
@@ -1822,7 +1824,7 @@ parse_vc_spec(struct context *ctx, const struct token
*token,
/* Modify next token to expect a prefix. */
if (ctx->next_num < 2)
return -1;
- ctx->next[ctx->next_num - 2] = NEXT_ENTRY(PREFIX);
+ ctx->next[ctx->next_num - 2] = prefix;
/* Fall through. */
case ITEM_PARAM_MASK:
index = 2;
--
2.1.4
[dpdk-dev] Proposal - ARM Support for Arkville PMD in DPDK 17.08
This email is notification ahead of the May 28 proposal deadline for 17.08 that Atomic Rules proposes to implement, test and support our Arkville net/ark PMD for ARM architecture in the DPDK 17.08 release. Our intent is for ARM architecture support with Arkville to stand equal with the current deep level of testing that is done with x86. Informally, we are reaching out to other DPDK developers who are currently supporting ARM so that we may share their best-practices and avoid their pitfalls. Shep for AR team Shepard Siegel, CTO atomicrules.com
Re: [dpdk-dev] Occasional instability in RSS Hashes/Queues from X540 NIC
Hey Keith, Here is a hexdump of a subset of one of my packet captures. In this capture, all of the packets are part of the same TCP connection, which happens to be NFSv3 traffic. All of them except packet number 6 get the correct RSS hash and go to the right queue. Packet number 6 (an NFS rename reply with an NFS error) gets RSS hash 0 and goes to queue 0. Whenever I repeat this test, the reply to this particular rename attempt always goes to the wrong core, though it seemingly differs from the rest of the flow only in layers 4-7. I'll also attach a pcap to this email, in case that's a more convenient way to interact with the packets. -- Matt Laswell lasw...@infinite.io 16:08:37.093306 IP 10.151.3.81.disclose > 10.151.3.161.nfsd: Flags [P.], seq 3173509264:3173509380, ack 3244259549, win 580, options [nop,nop,TS val 23060466 ecr 490971270], length 116: NFS request xid 2690728524 112 access fh Unknown/8B6BFEBB0400CFABD1030100DABC05020100 NFS_ACCESS_READ|NFS_ACCESS_LOOKUP|NFS_ACCESS_MODIFY|NFS_ACCESS_EXTEND|NFS_ACCESS_DELETE 0x: 4500 00a8 6d0f 4000 4006 b121 0a97 0351 E...m.@.@..!...Q 0x0010: 0a97 03a1 029b 0801 bd27 e890 c15f 78dd .'..._x. 0x0020: 8018 0244 1cba 0101 080a 015f dff2 ...D._.. 0x0030: 1d43 a086 8000 0070 a061 424c .C.p.aBL 0x0040: 0002 0001 86a3 0003 0004 0x0050: 0001 0020 0107 8d2f 0007 .../ 0x0060: 6573 7869 3275 3100 esxi2u1. 0x0070: 0001 0x0080: 0020 8b6b febb 0400 cfab d103 .k.. 0x0090: 0100 dabc 0502 0x00a0: 0100 001f 16:08:37.095837 IP 10.151.3.161.nfsd > 10.151.3.81.disclose: Flags [P.], seq 1:125, ack 116, win 28688, options [nop,nop,TS val 490971270 ecr 23060466], length 124: NFS reply xid 2690728524 reply ok 120 access c 001f 0x: 4500 00b0 1b80 4000 4006 02a9 0a97 03a1 E.@.@... 0x0010: 0a97 0351 0801 029b c15f 78dd bd27 e904 ...Q._x..'.. 0x0020: 8018 7010 a61a 0101 080a 1d43 a086 ..p..C.. 0x0030: 015f dff2 8000 0078 a061 424c 0001 ._.x.aBL 0x0040: 0x0050: 0001 0002 01ed 0x0060: 0003 0x0070: 0029 0800 00ff ...) 0x0080: 00ff bbfe 6b8b 0001 ..k. 0x0090: 03d1 abcf 5908 f554 3272 e4e6 5908 f554 Y..T2r..Y..T 0x00a0: 3272 e4e6 5908 f554 3365 2612 001f 2r..Y..T3e&. 16:08:37.096235 IP 10.151.3.81.disclose > 10.151.3.161.nfsd: Flags [P.], seq 256:372, ack 285, win 589, options [nop,nop,TS val 23060467 ecr 490971270], length 116: NFS request xid 2724282956 112 access fh Unknown/8B6BFEBB0400D0ABD1030100DABC05020100 NFS_ACCESS_READ|NFS_ACCESS_LOOKUP|NFS_ACCESS_MODIFY|NFS_ACCESS_EXTEND|NFS_ACCESS_DELETE 0x: 4500 00a8 6d11 4000 4006 b11f 0a97 0351 E...m.@.@..Q 0x0010: 0a97 03a1 029b 0801 bd27 e990 c15f 79f9 .'..._y. 0x0020: 8018 024d 1cba 0101 080a 015f dff3 ...M._.. 0x0030: 1d43 a086 8000 0070 a261 424c .C.p.aBL 0x0040: 0002 0001 86a3 0003 0004 0x0050: 0001 0020 0107 8d2f 0007 .../ 0x0060: 6573 7869 3275 3100 esxi2u1. 0x0070: 0001 0x0080: 0020 8b6b febb 0400 d0ab d103 .k.. 0x0090: 0100 dabc 0502 0x00a0: 0100 001f 16:08:37.098361 IP 10.151.3.161.nfsd > 10.151.3.81.disclose: Flags [P.], seq 285:409, ack 372, win 28688, options [nop,nop,TS val 490971270 ecr 23060467], length 124: NFS reply xid 2724282956 reply ok 120 access c 001f 0x: 4500 00b0 1b81 4000 4006 02a8 0a97 03a1 E.@.@... 0x0010: 0a97 0351 0801 029b c15f 79f9 bd27 ea04 ...Q._y..'.. 0x0020: 8018 7010 ec45 0101 080a 1d43 a086 ..p..E...C.. 0x0030: 015f dff3 8000 0078 a261 424c 0001 ._.x.aBL 0x0040: 0x0050: 0001 0002 01ed 0x0060: 0004 0x0070: 0050 0800 00ff ...P 0x0080: 00ff bbfe 6b8b 0001 ..k. 0x0090: 03d1 abd0 5908 f554 3536 88ea 5908 f554 Y..T56..Y..T 0x00a0: 3536 88ea 5908 f555 01ff bf76 001f 56..Y..U...v 16:08:37.099013 IP 10.151.3.81.disclose > 10.151.3.161.nfsd: Flags [P.], seq 652:856, ack 813, win 605, options [nop,nop,TS val 23060467 ecr 490971270], length 204: NFS request xid 277461
Re: [dpdk-dev] [PATCH v2 01/13] EAL: count nr_overcommit_hugepages as available
On Sun, Apr 30, 2017 at 05:53:55PM +0200, Thomas Monjalon wrote: > 13/12/2016 02:28, Michał Mirosław: > > Signed-off-by: Michał Mirosław > > --- > > lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 43 > > ++--- > > 1 file changed, 32 insertions(+), 11 deletions(-) > There is neither explanation nor comments for this patch. > Michal, please check with Sergio (mem maintainer) what can be done. I think the patch needs to be rebased and verified on new version. I won't be able to come back to this in next two weeks, but if you have any comments, please send them in. Best Regards, Michał Mirosław
[dpdk-dev] [PATCH] doc: factorize overview table CSS
There were several tables in NIC and crypto guides with the same
copy-pasted CSS addition.
It is moved into one unique place: conf.py.
Signed-off-by: Thomas Monjalon
---
doc/guides/conf.py | 75 +++--
doc/guides/cryptodevs/overview.rst | 212 -
doc/guides/nics/overview.rst | 53 --
3 files changed, 66 insertions(+), 274 deletions(-)
diff --git a/doc/guides/conf.py b/doc/guides/conf.py
index ef0e1c607..c3cd0bd69 100644
--- a/doc/guides/conf.py
+++ b/doc/guides/conf.py
@@ -178,7 +178,7 @@ def process_numref(app, doctree, from_docname):
node.replace_self(newnode)
-def generate_overview_table(output_filename, section, table_name, title):
+def generate_overview_table(output_filename, table_id, section, table_name,
title):
"""
Function to generate the Overview Table from the ini files that define
the features for each driver.
@@ -258,9 +258,8 @@ def generate_overview_table(output_filename, section,
table_name, title):
outfile = open(output_filename, 'w')
num_cols = len(header_names)
-print('.. table:: ' + table_name + '\n',
- file=outfile)
-
+print_table_css(outfile, table_id)
+print('.. table:: ' + table_name + '\n', file=outfile)
print_table_header(outfile, num_cols, header_names, title)
print_table_body(outfile, num_cols, ini_files, ini_data, default_features)
@@ -316,29 +315,87 @@ def print_table_divider(outfile, num_cols):
print_table_row(outfile, feature, line)
+def print_table_css(outfile, table_id):
+template = """
+.. raw:: html
+
+
+ .wy-nav-content {
+ opacity: .99;
+ }
+ table#idx {
+ cursor: default;
+ overflow: hidden;
+ }
+ table#idx th, table#idx td {
+ text-align: center;
+ }
+ table#idx th {
+ font-size: 80%;
+ white-space: pre-wrap;
+ vertical-align: top;
+ padding: 2px;
+ }
+ table#idx th:first-child {
+ vertical-align: bottom;
+ }
+ table#idx td {
+ font-size: 70%;
+ padding: 1px;
+ }
+ table#idx td:first-child {
+ padding-left: 1em;
+ text-align: left;
+ }
+ table#idx tr:nth-child(2n-1) td {
+ background-color: rgba(210, 210, 210, 0.2);
+ }
+ table#idx th:not(:first-child):hover,
+ table#idx td:not(:first-child):hover {
+ position: relative;
+ }
+ table#idx th:not(:first-child):hover::after,
+ table#idx td:not(:first-child):hover::after {
+ content: '';
+ height: 6000px;
+ top: -3000px;
+ width: 100%;
+ left: 0;
+ position: absolute;
+ z-index: -1;
+ background-color: #ffb;
+ }
+ table#idx tr:hover td {
+ background-color: #ffb;
+ }
+
+"""
+print(template.replace("idx", "id%d" % (table_id)), file=outfile)
+
+
def setup(app):
table_file = dirname(__file__) + '/nics/overview_table.txt'
-generate_overview_table(table_file,
+generate_overview_table(table_file, 1,
'Features',
'Features availability in networking drivers',
'Feature')
table_file = dirname(__file__) + '/cryptodevs/overview_feature_table.txt'
-generate_overview_table(table_file,
+generate_overview_table(table_file, 1,
'Features',
'Features availability in crypto drivers',
'Feature')
table_file = dirname(__file__) + '/cryptodevs/overview_cipher_table.txt'
-generate_overview_table(table_file,
+generate_overview_table(table_file, 2,
'Cipher',
'Cipher algorithms in crypto drivers',
'Cipher algorithm')
table_file = dirname(__file__) + '/cryptodevs/overview_auth_table.txt'
-generate_overview_table(table_file,
+generate_overview_table(table_file, 3,
'Auth',
'Authentication algorithms in crypto drivers',
'Authentication algorithm')
table_file = dirname(__file__) + '/cryptodevs/overview_aead_table.txt'
-generate_overview_table(table_file,
+generate_overview_table(table_file, 4,
'AEAD',
'AEAD algorithms in crypto drivers',
'AEAD algorithm')
diff --git a/doc/guides/cryptodevs/overview.rst
b/doc/guides/cryptodevs/overview.rst
index 656cf18c9..6764d0d93 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -35,59 +35,6 @@ Supported Feature Flags
.. _table_crypto_pmd_features:
-.. raw:: html
-
-
- .wy-nav-content {
- opacity: .99;
- }
- table#id1 {
- cursor: default;
- overflow: hidden;
Re: [dpdk-dev] [PATCH] maintainers: claim responsability for xen
Ping The Xen dom0 support in DPDK seems dead. Reminder: Last time we talked about, it was because of a severe bug which is not fixed yet: http://dpdk.org/ml/archives/dev/2016-July/044207.html http://dpdk.org/ml/archives/dev/2016-July/044376.html The request (9 months ago) was to give more time for feedbacks: http://dpdk.org/ml/archives/dev/2016-July/044847.html 23/02/2017 09:49, Thomas Monjalon: > 2017-02-20 15:33, Joao Martins: > > On 02/17/2017 04:07 PM, Konrad Rzeszutek Wilk wrote: > > > On Thu, Feb 16, 2017 at 10:51:44PM +0100, Vincent JARDIN wrote: > > >> Le 16/02/2017 à 14:36, Konrad Rzeszutek Wilk a écrit : > > Is it time now to officially remove Dom0 support? > > >>> So we do have an prototype implementation of netback but it is waiting > > >>> for review of xen-devel to the spec. > > >>> > > >>> And I believe the implementation does utilize some of the dom0 > > >>> parts of code in DPDK. > > >> > > >> Please, do you have URLs/pointers about it? It would be interesting to > > >> share > > >> it with DPDK community too. > > > > > > Joao, would it be possible to include an tarball of the patches? I know > > > they are no in the right state with the review of the staging > > > grants API - they are incompatible, but it may help folks to get > > > a feel for what DPDK APIs you used? > > OK, see attached - I should note that its a WIP as Konrad noted, but once > > the > > staging grants work is finished, the code would be improved to have it in > > better > > shape (as well as in feature parity) for a proper RFC [and adhering to the > > project coding style]. > > Excuse my ignorance on Xen. > Is xen-netback for Dom0? > Is the DPDK Dom0 support working and useful?
Re: [dpdk-dev] [PATCH v3 1/4] mk: add crypto capability for generic armv8a and thunderx
04/05/2017 17:20, Jan Viktorin: > On Wed, 3 May 2017 23:56:59 -0700 > Ashwin Sekhar T K wrote: > > > armv8-a has optional CRYPTO extension which adds the > > AES, PMULL, SHA1 and SHA2 capabilities. -march=armv8-a+crypto > > enables code generation for the ARMv8-A architecture together > > with the optional CRYPTO extensions. > > > > added the following flags to detect the corresponding > > capability at compile time > > * RTE_MACHINE_CPUFLAG_AES > > * RTE_MACHINE_CPUFLAG_PMULL > > * RTE_MACHINE_CPUFLAG_SHA1 > > * RTE_MACHINE_CPUFLAG_SHA2 > > > > at run-time, the following flags can be used to detect these > > capabilities > > * RTE_CPUFLAG_AES > > * RTE_CPUFLAG_PMULL > > * RTE_CPUFLAG_SHA1 > > * RTE_CPUFLAG_SHA2 > > > > Signed-off-by: Ashwin Sekhar T K > > Reviewed-by: Jan Viktorin Do you agree that this series, and others bringing NEON optimizations, are not candidates for 17.05? If you see an urgent fix in all these NEON patches, please shout now. Thanks
[dpdk-dev] [PATCH v2] net: fix stripped VLAN flag for offload emulation
From: Michał Mirosław
Apply the new flag PKT_RX_VLAN_STRIPPED to the software emulation case
(currently only for virtio and af_packet).
Fixes: b37b528d957c ("mbuf: add new Rx flags for stripped VLAN")
Cc: sta...@dpdk.org
Signed-off-by: Michał Mirosław
Signed-off-by: Thomas Monjalon
---
v2: add explanations and update rte_vlan_insert()
---
lib/librte_net/rte_ether.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
index ff3d06540..5edf66c3f 100644
--- a/lib/librte_net/rte_ether.h
+++ b/lib/librte_net/rte_ether.h
@@ -357,7 +357,7 @@ static inline int rte_vlan_strip(struct rte_mbuf *m)
return -1;
struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 1);
- m->ol_flags |= PKT_RX_VLAN_PKT;
+ m->ol_flags |= PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED;
m->vlan_tci = rte_be_to_cpu_16(vh->vlan_tci);
/* Copy ether header over rather than moving whole packet */
@@ -407,6 +407,8 @@ static inline int rte_vlan_insert(struct rte_mbuf **m)
vh = (struct vlan_hdr *) (nh + 1);
vh->vlan_tci = rte_cpu_to_be_16((*m)->vlan_tci);
+ (*m)->ol_flags &= ~PKT_RX_VLAN_STRIPPED;
+
return 0;
}
--
2.12.2
Re: [dpdk-dev] [PATCH v6 1/3] ethdev: fix adding invalid MAC addr
> Subject: Re: [PATCH v6 1/3] ethdev: fix adding invalid MAC addr
>
> On Tue, May 02, 2017 at 08:44:23PM +0800, Wei Dai wrote:
> > Some customers find adding MAC addr to VF sometimes can fail, but it
> > is still stored in dev->data->mac_addrs[ ]. So this can lead to some
> > errors that assumes the non-zero entry in
> > dev->data->mac_addrs[ ] is valid.
> > Following acknowledgements are from specific NIC PMD maintainer for
> > their managing part.
> >
> > Fixes: af75078fece3 ("first public release")
>
>
> > Cc: sta...@dpdk.org
>
> Just a note, this patch changes API. It should not be backported to a
> stable/LTS
> release, even though it fixes something.
>
> --yliu
Thank you, Yuanhan. I will drop the "Cc: sta...@dpdk.org" in my v7 patch set.
Re: [dpdk-dev] [PATCH] drivers/net: add generic ethdev macro to get PCI device
Hi, > -Original Message- > From: Yigit, Ferruh > Sent: Thursday, May 4, 2017 9:08 PM > To: Thomas Monjalon; Shepard Siegel; Ed Czeck; John Miller; Legacy, Allain > (Wind River); Peters, Matt (Wind River); Lu, Wenzhuo; Zhang, Helin; Wu, > Jingjing; Ananyev, Konstantin; Andrew Rybchenko > Cc: dev@dpdk.org; Yigit, Ferruh > Subject: [PATCH] drivers/net: add generic ethdev macro to get PCI device > > 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: Wenzhuo Lu BTW, there're RTE_DEV_TO_PCI(dev->device) in many places, maybe we can replace them by the new macro RTE_ETH_DEV_TO_PCI.
Re: [dpdk-dev] [PATCH 04/10] net/ixgbe: fix gcc 7 warning for switch fallthrough
Hi,
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Thursday, May 4, 2017 11:38 PM
> To: dev@dpdk.org
> Cc: Richardson, Bruce
> Subject: [dpdk-dev] [PATCH 04/10] net/ixgbe: fix gcc 7 warning for switch
> fallthrough
>
> Add a comment documenting explicitly that we are falling through the case
> statements to the next one.
>
> Fixes: f9072f8b90bb ("ixgbe: migrate flow director filtering to new API")
>
> Signed-off-by: Bruce Richardson
Acked-by: Wenzhuo Lu
[dpdk-dev] [PATCH v7 1/3] ethdev: fix adding invalid MAC addr
Some customers find adding MAC addr to VF sometimes can fail,
but it is still stored in dev->data->mac_addrs[ ]. So this
can lead to some errors that assumes the non-zero entry in
dev->data->mac_addrs[ ] is valid.
Following acknowledgements are from specific NIC PMD
maintainer for their managing part.
This patch changes the ethdev API, it should not be
backported to a stable/LTS release so far.
Fixes: af75078fece3 ("first public release")
Signed-off-by: Wei Dai
Acked-by: Nelio Laranjeiro
Acked-by: Yuanhan Liu
Acked-by: Wenzhuo Lu
---
drivers/net/ark/ark_ethdev.c | 15 +--
drivers/net/bnx2x/bnx2x_ethdev.c | 7 +--
drivers/net/bnxt/bnxt_ethdev.c | 16
drivers/net/e1000/em_ethdev.c | 8
drivers/net/e1000/igb_ethdev.c | 9 +
drivers/net/enic/enic.h| 2 +-
drivers/net/enic/enic_ethdev.c | 4 ++--
drivers/net/enic/enic_main.c | 9 -
drivers/net/fm10k/fm10k_ethdev.c | 3 ++-
drivers/net/i40e/i40e_ethdev.c | 17 +
drivers/net/i40e/i40e_ethdev_vf.c | 14 +++---
drivers/net/ixgbe/ixgbe_ethdev.c | 33 +
drivers/net/mlx4/mlx4.c| 16 ++--
drivers/net/mlx5/mlx5.h| 4 ++--
drivers/net/mlx5/mlx5_mac.c| 16 ++--
drivers/net/qede/qede_ethdev.c | 6 --
drivers/net/ring/rte_eth_ring.c| 3 ++-
drivers/net/virtio/virtio_ethdev.c | 13 +++--
lib/librte_ether/rte_ethdev.c | 15 +--
lib/librte_ether/rte_ethdev.h | 2 +-
20 files changed, 122 insertions(+), 90 deletions(-)
diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index 83961f5..995c93d 100644
--- a/drivers/net/ark/ark_ethdev.c
+++ b/drivers/net/ark/ark_ethdev.c
@@ -71,10 +71,10 @@ static void eth_ark_dev_stats_get(struct rte_eth_dev *dev,
static void eth_ark_dev_stats_reset(struct rte_eth_dev *dev);
static void eth_ark_set_default_mac_addr(struct rte_eth_dev *dev,
struct ether_addr *mac_addr);
-static void eth_ark_macaddr_add(struct rte_eth_dev *dev,
- struct ether_addr *mac_addr,
- uint32_t index,
- uint32_t pool);
+static int eth_ark_macaddr_add(struct rte_eth_dev *dev,
+ struct ether_addr *mac_addr,
+ uint32_t index,
+ uint32_t pool);
static void eth_ark_macaddr_remove(struct rte_eth_dev *dev,
uint32_t index);
@@ -831,7 +831,7 @@ eth_ark_dev_stats_reset(struct rte_eth_dev *dev)
ark->user_ext.stats_reset(dev, ark->user_data);
}
-static void
+static int
eth_ark_macaddr_add(struct rte_eth_dev *dev,
struct ether_addr *mac_addr,
uint32_t index,
@@ -840,12 +840,15 @@ eth_ark_macaddr_add(struct rte_eth_dev *dev,
struct ark_adapter *ark =
(struct ark_adapter *)dev->data->dev_private;
- if (ark->user_ext.mac_addr_add)
+ if (ark->user_ext.mac_addr_add) {
ark->user_ext.mac_addr_add(dev,
mac_addr,
index,
pool,
ark->user_data);
+ return 0;
+ }
+ return -ENOTSUP;
}
static void
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 314e5ea..b79cfdb 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -451,14 +451,17 @@ bnx2x_dev_infos_get(struct rte_eth_dev *dev, __rte_unused
struct rte_eth_dev_inf
dev_info->speed_capa = ETH_LINK_SPEED_10G | ETH_LINK_SPEED_20G;
}
-static void
+static int
bnx2x_mac_addr_add(struct rte_eth_dev *dev, struct ether_addr *mac_addr,
uint32_t index, uint32_t pool)
{
struct bnx2x_softc *sc = dev->data->dev_private;
- if (sc->mac_ops.mac_addr_add)
+ if (sc->mac_ops.mac_addr_add) {
sc->mac_ops.mac_addr_add(dev, mac_addr, index, pool);
+ return 0;
+ }
+ return -ENOTSUP;
}
static void
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 7805221..bb87361 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -618,9 +618,9 @@ static void bnxt_mac_addr_remove_op(struct rte_eth_dev
*eth_dev,
}
}
-static void bnxt_mac_addr_add_op(struct rte_eth_dev *eth_dev,
-struct ether_addr *mac_addr,
-uint32_t index, uint32_t pool)
+static int bnxt_mac_addr_add_op(struct rte_eth_dev *eth_dev,
+ struct ether_addr *mac_addr,
+ uint32_t index, uint32_t pool)
{
[dpdk-dev] [PATCH v7 2/3] doc: change type of return value of adding MAC addr
Add following lines in section of API change in release note. If a MAC address fails to be added without this change, it is still stored and may be regarded as a valid one. This may lead to errors in application. The type of return value of eth_mac_addr_add_t in rte_ethdev.h is changed. Any specific NIC also follows this change. Signed-off-by: Wei Dai Acked-by: John McNamara --- doc/guides/rel_notes/release_17_05.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/guides/rel_notes/release_17_05.rst b/doc/guides/rel_notes/release_17_05.rst index 4b47ae1..0bd07f1 100644 --- a/doc/guides/rel_notes/release_17_05.rst +++ b/doc/guides/rel_notes/release_17_05.rst @@ -489,6 +489,13 @@ ABI Changes * The ``rte_cryptodev_info.sym`` structure has new field ``max_nb_sessions_per_qp`` to support drivers which may support limited number of sessions per queue_pair. +* **Return if the MAC address is added successfully or not.** + + If a MAC address fails to be added without this change, it is still stored + and may be regarded as a valid one. This may lead to errors in application. + The type of return value of eth_mac_addr_add_t in rte_ethdev.h is changed. + Any specific NIC also follows this change. + Removed Items - -- 2.7.4
[dpdk-dev] [PATCH v7 0/3] MAC address fail to be added shouldn't be stored
Current ethdev always stores the MAC address even it fails to be added. Other function may regard the failed MAC address valid and lead to some errors. So There is a need to check if the addr is added successfully or not and discard it if it fails. In 3rd patch, add a command "add_more_mac_addr port_id base_mac_addr count" to add more than one MAC address one time. This command can simplify the test for the first patch. Normally a MAC address may fails to be added only after many MAC addresses have been added. Without this command, a tester may only trigger failed MAC address by running many times of testpmd command 'mac_addr add' . This patch set has got acknowledgements from Nelio Laranjeiro for mlx changes Yuanhan Liu for virtio changes Wenzhuo Lu for igb, e1000 and ixgbe changes --- Changes v7: 1. remove "Cc: sta...@dpdk.org" in patch 1/3 2. add "Acked by: Wenzhuo.Lu " in patch 1/3 v6: 1. rebase master branch to v17.05-rc3 2. not touch e1000 base driver code 3. fix some minor defects v5: 1. rebase master branch 2. add support to drivers/net/ark 3. fix some minor defects v4: 1. rebase master branch 2. follow code style v3: 1. Change return value for some specific NIC according to feedbacks from the community; 2. Add ABI change in release note; 3. Add more detailed commit message. v2: fix warnings and erros from check-git-log.sh and checkpatch.pl Wei Dai (3): ethdev: fix adding invalid MAC addr doc: change type of return value of adding MAC addr app/testpmd: add a command to add many MAC addrs app/test-pmd/cmdline.c | 55 ++ doc/guides/rel_notes/release_17_05.rst | 7 + drivers/net/ark/ark_ethdev.c | 15 ++ drivers/net/bnx2x/bnx2x_ethdev.c | 7 +++-- drivers/net/bnxt/bnxt_ethdev.c | 16 +- drivers/net/e1000/em_ethdev.c | 8 ++--- drivers/net/e1000/igb_ethdev.c | 9 +++--- drivers/net/enic/enic.h| 2 +- drivers/net/enic/enic_ethdev.c | 4 +-- drivers/net/enic/enic_main.c | 9 +++--- drivers/net/fm10k/fm10k_ethdev.c | 3 +- drivers/net/i40e/i40e_ethdev.c | 17 ++- drivers/net/i40e/i40e_ethdev_vf.c | 14 - drivers/net/ixgbe/ixgbe_ethdev.c | 33 drivers/net/mlx4/mlx4.c| 16 ++ drivers/net/mlx5/mlx5.h| 4 +-- drivers/net/mlx5/mlx5_mac.c| 16 ++ drivers/net/qede/qede_ethdev.c | 6 ++-- drivers/net/ring/rte_eth_ring.c| 3 +- drivers/net/virtio/virtio_ethdev.c | 13 lib/librte_ether/rte_ethdev.c | 15 ++ lib/librte_ether/rte_ethdev.h | 2 +- 22 files changed, 184 insertions(+), 90 deletions(-) -- 2.7.4
[dpdk-dev] [PATCH v7 3/3] app/testpmd: add a command to add many MAC addrs
This patch is added to introduce a testpmd command which
is used to add more than one MAC addresses one time.
This command can simplify the test for the change where
the type of return value of adding MAC address.
Normally a MAC address may fails to be added only after
many MAC addresses have been added.
Without this command, a tester may only trigger failed
MAC address by running many times of testpmd command
'mac_addr add' .
Signed-off-by: Wei Dai
---
app/test-pmd/cmdline.c | 55 ++
1 file changed, 55 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 06c1ce2..f73bb83 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6436,6 +6436,60 @@ cmdline_parse_inst_t cmd_mac_addr = {
},
};
+/* *** ADD MORE THAN ONE MAC ADDRESS FROM A PORT *** */
+struct cmd_add_more_mac_addr_result {
+ cmdline_fixed_string_t mac_addr_cmd;
+ uint8_t port_num;
+ struct ether_addr address;
+ uint8_t cnt_addr;
+};
+
+static void cmd_add_more_mac_addr_parsed(void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_add_more_mac_addr_result *res = parsed_result;
+ int ret;
+ int k;
+
+ for (k = 0; k < res->cnt_addr; k++) {
+ ret = rte_eth_dev_mac_addr_add(res->port_num, &res->address, 0);
+ if (ret < 0) {
+ printf("Fail to add mac addr : (%s) after adding %u
addresses\n",
+ strerror(-ret), k);
+ return;
+ }
+ res->address.addr_bytes[5]++;
+ }
+ printf("Success to add %u mac addresses\n", k);
+}
+
+cmdline_parse_token_string_t cmd_add_more_mac_addr_cmd =
+ TOKEN_STRING_INITIALIZER(struct cmd_add_more_mac_addr_result,
+ mac_addr_cmd, "add_more_mac_addr");
+cmdline_parse_token_num_t cmd_add_more_mac_addr_portnum =
+ TOKEN_NUM_INITIALIZER(struct cmd_add_more_mac_addr_result,
+ port_num, UINT8);
+cmdline_parse_token_etheraddr_t cmd_add_more_mac_addr_addr =
+ TOKEN_ETHERADDR_INITIALIZER(struct cmd_add_more_mac_addr_result,
+ address);
+cmdline_parse_token_num_t cmd_add_more_mac_addr_cnt_addr =
+ TOKEN_NUM_INITIALIZER(struct cmd_add_more_mac_addr_result,
+ cnt_addr, UINT8);
+
+cmdline_parse_inst_t cmd_add_more_mac_addr = {
+ .f = cmd_add_more_mac_addr_parsed,
+ .data = (void *)0,
+ .help_str = "add_more_mac_addr : "
+ "Add cnt_addr MAC addresses on port_id",
+ .tokens = {
+ (void *)&cmd_add_more_mac_addr_cmd,
+ (void *)&cmd_add_more_mac_addr_portnum,
+ (void *)&cmd_add_more_mac_addr_addr,
+ (void *)&cmd_add_more_mac_addr_cnt_addr,
+ NULL,
+ },
+};
/* *** CONFIGURE QUEUE STATS COUNTER MAPPINGS *** */
struct cmd_set_qmap_result {
@@ -13647,6 +13701,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_read_rxd_txd,
(cmdline_parse_inst_t *)&cmd_stop,
(cmdline_parse_inst_t *)&cmd_mac_addr,
+ (cmdline_parse_inst_t *)&cmd_add_more_mac_addr,
(cmdline_parse_inst_t *)&cmd_set_qmap,
(cmdline_parse_inst_t *)&cmd_operate_port,
(cmdline_parse_inst_t *)&cmd_operate_specific_port,
--
2.7.4
Re: [dpdk-dev] [PATCH] net/ixgbe: do not touch mbuf initialized fields
Hi,
> -Original Message-
> From: Yigit, Ferruh
> Sent: Thursday, May 4, 2017 11:59 PM
> To: Lu, Wenzhuo; Ananyev, Konstantin
> Cc: dev@dpdk.org; Olivier Matz
> Subject: [PATCH] net/ixgbe: do not touch mbuf initialized fields
>
> See: 8f094a9ac5d7 ("mbuf: set mbuf fields while in pool")
>
> Signed-off-by: Ferruh Yigit
Acked-by: Wenzhuo Lu
Re: [dpdk-dev] [PATCH v2 0/3] add a macro to enable support of backtrace
Hi, Thomas I noticed that my following patch set has been superseded. It address the compile errors when DPDK is built with musl. I know some customer products like Yocto Linux and that from Roph are using DPDK with musl and they have to manually change something to build it. Roph also referenced to use DPDK with musl in his mail titled " [dpdk-dev] Compiling DPDK 17.02 using musl instead of glibc " sent on 2017-03-14 Thanks & Best Regards -Wei > -Original Message- > From: Dai, Wei > Sent: Monday, March 13, 2017 4:59 PM > To: dev@dpdk.org > Cc: thomas.monja...@6wind.com; Mcnamara, John > ; david.march...@6wind.com; Tan, Raymond > ; Dai, Wei > Subject: [PATCH v2 0/3] add a macro to enable support of backtrace > > Some LIBC implementation like musl doesn't support backtrace( ) and > backtrace_symbols declared in execinfo.h. > Currently some DPDK customers fail to build PDDK with musl. > In order to build DPDK with musl, there is a need to reomve references > toexecinfo.h. > > Add a configuration parameter in config/common_linuxapp which equals to y by > default. It also generate a macro named as RTE_EAL_ENABLE_BACKTRACE > when this configuration paramter equals to y or no above macro when it is n. > > --- > changes: > v2 -- change configuration parameter name > > > Wei Dai (3): > examples/performance-thread: remove reference to execinfo.h > config: add a marco to enable backtrace or not > eal: remove references to execinfo.h for musl > > config/common_linuxapp | 1 + > examples/performance-thread/common/lthread_tls.c | 1 - > lib/librte_eal/linuxapp/eal/eal_debug.c | 4 > 3 files changed, 5 insertions(+), 1 deletion(-) > > -- > 2.7.4
Re: [dpdk-dev] [PATCH v7 1/3] ethdev: fix adding invalid MAC addr
Hi, Dai wei
> static void
> diff --git a/drivers/net/e1000/igb_ethdev.c
> b/drivers/net/e1000/igb_ethdev.c index b6b81cb..e8c6282 100644
> --- a/drivers/net/e1000/igb_ethdev.c
> +++ b/drivers/net/e1000/igb_ethdev.c
> @@ -171,9 +171,9 @@ static int eth_igb_led_off(struct rte_eth_dev *dev);
>
> static void igb_intr_disable(struct e1000_hw *hw); static int
> igb_get_rx_buffer_size(struct e1000_hw *hw); -static void
> eth_igb_rar_set(struct rte_eth_dev *dev,
> - struct ether_addr *mac_addr,
> - uint32_t index, uint32_t pool);
> +static int eth_igb_rar_set(struct rte_eth_dev *dev,
> +struct ether_addr *mac_addr,
> +uint32_t index, uint32_t pool);
> static void eth_igb_rar_clear(struct rte_eth_dev *dev, uint32_t index);
> static void eth_igb_default_mac_addr_set(struct rte_eth_dev *dev,
> struct ether_addr *addr);
> @@ -3079,7 +3079,7 @@ eth_igb_flow_ctrl_set(struct rte_eth_dev *dev,
> struct rte_eth_fc_conf *fc_conf) }
>
> #define E1000_RAH_POOLSEL_SHIFT (18)
> -static void
> +static int
> eth_igb_rar_set(struct rte_eth_dev *dev, struct ether_addr *mac_addr,
> uint32_t index, __rte_unused uint32_t pool) { @@ -3090,6
> +3090,7 @@ eth_igb_rar_set(struct rte_eth_dev *dev, struct ether_addr
> *mac_addr,
> rah = E1000_READ_REG(hw, E1000_RAH(index));
> rah |= (0x1 << (E1000_RAH_POOLSEL_SHIFT + pool));
> E1000_WRITE_REG(hw, E1000_RAH(index), rah);
> + return 0;
> }
What's the meaning to add a return here? Return 0 can't represent adding an
invalid or valid address, it's meaningless.
Re: [dpdk-dev] [PATCH] net/ixgbe: fix VF Rx mode if allmulticast is disabled
Hi,
> -Original Message-
> From: Dai, Wei
> Sent: Thursday, May 4, 2017 5:55 PM
> To: Zhang, Helin; Ananyev, Konstantin; Lu, Wenzhuo
> Cc: dev@dpdk.org; Dai, Wei; sta...@dpdk.org
> Subject: [PATCH] net/ixgbe: fix VF Rx mode if allmulticast is disabled
>
> Some customers find that 82599 NIC DPDK VF PMD can't receive any
> broadcast packets when it is bound to igb_uio in the first time to run a DPDK
> application like testpmd. But when the application is quited and run again,
> the DPDK VF PMD can receive broadcast packets again. The associated PF is
> run by kernel driver when the VF is driven by DPDK PMD.
>
> When patch fixes this issue.
>
> Fixes: 260e2e22e26f ("net/ixgbe/base: move multicast mode update")
> Fixes: 72dec9e37a84 ("ixgbe: support multicast promiscuous mode on VF")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Dai
Acked-by: Wenzhuo Lu
[dpdk-dev] [PATCH v2] test: add delay time in test alarm
Because accuracy of timing to the microsecond is not guaranteed
in rte_eal_alarm_set, this function will not be called before
the requested time, but may be called a period of time
afterwards which can not be calculated. In order to ensure
test alarm running success, this patch added the delay time
before check the flag.
Signed-off-by: Qiming Yang
---
v2 changes:
* fixed coding style problems
---
---
test/test/test_alarm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/test/test/test_alarm.c b/test/test/test_alarm.c
index ecb2f6d..cbae1a0 100644
--- a/test/test/test_alarm.c
+++ b/test/test/test_alarm.c
@@ -96,6 +96,7 @@ static int
test_multi_alarms(void)
{
int rm_count = 0;
+ int count = 0;
cb_count.cnt = 0;
printf("Expect 6 callbacks in order...\n");
@@ -169,7 +170,10 @@ test_multi_alarms(void)
printf("Error, cancelling head-of-list leads to premature
callback\n");
return -1;
}
- rte_delay_ms(10);
+
+ while (flag != 2 && count++ < 6)
+ rte_delay_ms(10);
+
if (flag != 2) {
printf("Error - expected callback not called\n");
rte_eal_alarm_cancel(test_remove_in_callback, (void *)-1);
@@ -212,7 +216,7 @@ test_alarm(void)
printf("fail to set alarm callback\n");
return -1;
}
- while (flag == 0 && count ++ < 6)
+ while (flag == 0 && count++ < 20)
rte_delay_ms(RTE_TEST_CHECK_PERIOD);
if (flag == 0){
--
2.7.4
[dpdk-dev] How to using add/lookup hash table in multithread environment
Hi DPDK team, I am using DPDK to build a program in multithread environment. I use 1 thread (on 1 core) to add and delete hash table key ( by rte_hash_add_key() and rte_hash_del_key() function); And use 8 thread (on 8 others core) to lookup (by rte_hash_lookup() function ). As I know, rte_hash_lookup() function is /multi-thread safe,/ and te_hash_add_key() and rte_hash_del_key() function is not /multi-thread safe/. So: Do I need using /lock/ when I add or delete key by 1 thread while 8 others thread is looking-up? Many thanks, Vuong Le
[dpdk-dev] [PATCH] doc: add tested Intel platforms with Intel NICs
Add tested Intel platforms with Intel NICs to the release note. Signed-off-by: Yulong Pei --- doc/guides/rel_notes/release_17_05.rst | 68 ++ 1 file changed, 68 insertions(+) diff --git a/doc/guides/rel_notes/release_17_05.rst b/doc/guides/rel_notes/release_17_05.rst index 4b47ae1..b6d6cca 100644 --- a/doc/guides/rel_notes/release_17_05.rst +++ b/doc/guides/rel_notes/release_17_05.rst @@ -576,3 +576,71 @@ Tested Platforms This section is a comment. do not overwrite or remove it. Also, make sure to start the actual text at the margin. = + +* Intel(R) platforms with Intel(R) NICs combinations + + * CPU + + * Intel(R) Atom(TM) CPU C2758 @ 2.40GHz + * Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz + * Intel(R) Xeon(R) CPU E5-4667 v3 @ 2.00GHz + * Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz + * Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz + * Intel(R) Xeon(R) CPU E5-2695 v4 @ 2.10GHz + * Intel(R) Xeon(R) CPU E5-2658 v2 @ 2.40GHz + * Intel(R) Xeon(R) CPU E5-2658 v3 @ 2.20GHz + + * OS: + + * CentOS 7.2 + * Fedora 25 + * FreeBSD 11 + * Red Hat Enterprise Linux Server release 7.3 + * SUSE Enterprise Linux 12 + * Wind River Linux 8 + * Ubuntu 16.04 + * Ubuntu 16.10 + + * NICs: + + * Intel(R) 82599ES 10 Gigabit Ethernet Controller + + * Firmware version: 0x61bf0001 + * Device id (pf/vf): 8086:10fb / 8086:10ed + * Driver version: 4.0.1-k (ixgbe) + + * Intel(R) Corporation Ethernet Connection X552/X557-AT 10GBASE-T + + * Firmware version: 0x81cf + * Device id (pf/vf): 8086:15ad / 8086:15a8 + * Driver version: 4.2.5 (ixgbe) + + * Intel(R) Ethernet Converged Network Adapter X710-DA4 (4x10G) + + * Firmware version: 5.05 + * Device id (pf/vf): 8086:1572 / 8086:154c + * Driver version: 1.5.23 (i40e) + + * Intel(R) Ethernet Converged Network Adapter X710-DA2 (2x10G) + + * Firmware version: 5.05 + * Device id (pf/vf): 8086:1572 / 8086:154c + * Driver version: 1.5.23 (i40e) + + * Intel(R) Ethernet Converged Network Adapter XL710-QDA1 (1x40G) + + * Firmware version: 5.05 + * Device id (pf/vf): 8086:1584 / 8086:154c + * Driver version: 1.5.23 (i40e) + + * Intel(R) Ethernet Converged Network Adapter XL710-QDA2 (2X40G) + + * Firmware version: 5.05 + * Device id (pf/vf): 8086:1583 / 8086:154c + * Driver version: 1.5.23 (i40e) + + * Intel(R) Corporation I350 Gigabit Network Connection + + * Firmware version: 1.48, 0x86e7 + * Device id (pf/vf): 8086:1521 / 8086:1520 + * Driver version: 5.2.13-k (igb) -- 2.5.0
Re: [dpdk-dev] [PATCH 5/5] examples/l3fwd: add neon support for l3fwd
On Thu, 2017-05-04 at 16:42 +0800, Jianbo Liu wrote: > Hi Ashwin, > > On 3 May 2017 at 13:24, Jianbo Liu wrote: > > > > Hi Ashwin, > > > > On 2 May 2017 at 19:47, Sekhar, Ashwin > > wrote: > > > > > > Hi Jianbo, > > > > > > I tested your neon changes on thunderx. I am seeing a performance > > > regression of ~10% for LPM case and ~20% for EM case with your > > > changes. > > > Did you see improvement on any arm64 platform with these changes. > > > If > > > yes, how much was the improvement? > > Thanks for your reviewing and testing. > > For some reason, I have not done much with the performance testing. > > I'll send a new version later after tuning the performance. > > > Can you tell me how did you test? Built with following commands. make config T=arm64-thunderx-linuxapp-gcc make -j32 Tested LPM with sudo ./examples/l3fwd/build/l3fwd -l 9,10 --master-lcore 9 -- -p 0x1 --config="(0,0,10)" Tested EM with sudo ./examples/l3fwd/build/l3fwd -l 9,10 --master-lcore 9 -- -p 0x1 --config="(0,0,10)" -E > My testing shows that EM case is much better, while LPM is almost the > same as before. Could you please tell on which arm64 processor/platform you tested. Also how much was the percentage increase in performance for EM ? > Thanks! > Jianbo
[dpdk-dev] [PATCH] doc: add known issue about l3fwd-power
Because of UIO only support one interrupt, when insmod ``igb_uio`` and running l3fwd-power APP, link status getting doesn't work properly. Signed-off-by: Qiming Yang --- doc/guides/rel_notes/known_issues.rst | 21 + 1 file changed, 21 insertions(+) diff --git a/doc/guides/rel_notes/known_issues.rst b/doc/guides/rel_notes/known_issues.rst index 37464a0..3f6d8cb 100644 --- a/doc/guides/rel_notes/known_issues.rst +++ b/doc/guides/rel_notes/known_issues.rst @@ -721,3 +721,24 @@ igb uio legacy mode can not be used in X710/XL710/XXV710 **Driver/Module**: Poll Mode Driver (PMD). + + +igb_uio can not be used when running l3fwd-power + + +**Description**: + Link Status Change(LSC) interrupt and packet receiving interrupt are all enabled in l3fwd-power + APP. Because of UIO only support one interrupt, so these two kinds of interrupt need to share + one, and the receiving interrupt have the higher priority, so can't get the right link status. + +**Implication**: + When insmod ``igb_uio`` and running l3fwd-power APP, link status getting doesn't work properly. + +**Resolution/Workaround**: + Use vfio-pci when LSC and packet receiving interrupt enabled. + +**Affected Environment/Platform**: + ALL. + +**Driver/Module**: + ``igb_uio`` module. -- 2.7.4
Re: [dpdk-dev] [PATCH 5/5] examples/l3fwd: add neon support for l3fwd
On 5 May 2017 at 12:24, Sekhar, Ashwin wrote: > On Thu, 2017-05-04 at 16:42 +0800, Jianbo Liu wrote: >> Hi Ashwin, >> >> On 3 May 2017 at 13:24, Jianbo Liu wrote: >> > >> > Hi Ashwin, >> > >> > On 2 May 2017 at 19:47, Sekhar, Ashwin >> > wrote: >> > > >> > > Hi Jianbo, >> > > >> > > I tested your neon changes on thunderx. I am seeing a performance >> > > regression of ~10% for LPM case and ~20% for EM case with your >> > > changes. >> > > Did you see improvement on any arm64 platform with these changes. >> > > If >> > > yes, how much was the improvement? >> > Thanks for your reviewing and testing. >> > For some reason, I have not done much with the performance testing. >> > I'll send a new version later after tuning the performance. >> > >> Can you tell me how did you test? > Built with following commands. > make config T=arm64-thunderx-linuxapp-gcc > make -j32 > > Tested LPM with > sudo ./examples/l3fwd/build/l3fwd -l 9,10 --master-lcore 9 -- -p 0x1 > --config="(0,0,10)" > > Tested EM with > sudo ./examples/l3fwd/build/l3fwd -l 9,10 --master-lcore 9 -- -p 0x1 > --config="(0,0,10)" -E > Only one port? What's the network topology, and lpm/em rules? How did you stress traffic...? >> My testing shows that EM case is much better, while LPM is almost the >> same as before. > Could you please tell on which arm64 processor/platform you tested. > Also how much was the percentage increase in performance for EM ? > I'm sorry I can't tell you what's arm64 platform I tested on. But I can get a ThunderX, and replicate your testing environment if you can tell me more... Thanks! Jianbo
Re: [dpdk-dev] [PATCH v2] test: add delay time in test alarm
Hi,
> diff --git a/test/test/test_alarm.c b/test/test/test_alarm.c index
> ecb2f6d..cbae1a0 100644
> --- a/test/test/test_alarm.c
> +++ b/test/test/test_alarm.c
> @@ -96,6 +96,7 @@ static int
> test_multi_alarms(void)
> {
> int rm_count = 0;
> + int count = 0;
> cb_count.cnt = 0;
>
> printf("Expect 6 callbacks in order...\n"); @@ -169,7 +170,10 @@
> test_multi_alarms(void)
> printf("Error, cancelling head-of-list leads to premature
> callback\n");
> return -1;
> }
> - rte_delay_ms(10);
> +
> + while (flag != 2 && count++ < 6)
> + rte_delay_ms(10);
> +
> if (flag != 2) {
> printf("Error - expected callback not called\n");
> rte_eal_alarm_cancel(test_remove_in_callback, (void *)-1);
> @@ -212,7 +216,7 @@ test_alarm(void)
> printf("fail to set alarm callback\n");
> return -1;
> }
> - while (flag == 0 && count ++ < 6)
> + while (flag == 0 && count++ < 20)
> rte_delay_ms(RTE_TEST_CHECK_PERIOD);
>
What's the criteria to delay 20* RTE_TEST_CHECK_PERIOD ms? Add more comments?
> if (flag == 0){
> --
> 2.7.4
Overall comment is to replace numeric with macro.
