Add a new private API to support the untag drop enable/disable
for specific VF.
Add a flag "untag_drop" in i40e_vsi to help track the untag drop
status, so it prevent error from i40e_aq_remove_vlan when call
rte_pmd_i40e_set_vf_vlan_untag_drop twice.
Signed-off-by: Qi Zhang
---
V2:
- Add a flag "
Add a new API to enable untag drop for a specific VF.
This is an experimental API.
v2:
- Add a flag "untag_drop" in i40e_vsi to help track the untag drop
status, so it prevent error from i40e_aq_remove_vlan when call
rte_pmd_i40e_set_vf_vlan_untag_drop twice.
Due to hardware limitation, the
Add command line to support untag drop to specific VF in
testpmd.
Signed-off-by: Qi Zhang
---
v2:
- adjust compile option to align with others.
app/test-pmd/cmdline.c | 99 ++
1 file changed, 99 insertions(+)
diff --git a/app/test-pmd/cmdline.c b
Hi, Konstantin
I see your point.
I think your method can work.
But I think your method is a bit complex. As you method need to add more codes.
Anyway this is a simple bug.
How do you think now ?
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Friday, March 10, 2017 8:21 PM
> To: D
Hi,
> -Original Message-
> From: Billy McFall [mailto:bmcf...@redhat.com]
> Sent: Friday, March 10, 2017 4:51 AM
> To: thomas.monja...@6wind.com; Lu, Wenzhuo; olivier.m...@6wind.com
> Cc: dev@dpdk.org; Billy McFall
> Subject: [PATCH v6 2/3] net/e1000: e1000 igb support to free consumed buf
Hi,
> -Original Message-
> From: Allain Legacy [mailto:allain.leg...@windriver.com]
> Sent: Friday, March 10, 2017 10:38 PM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org
> Subject: [PATCH] net/e1000: advertise offload capabilities for the EM PMD
>
> The hardware offload capabilities are not being
Hi Jasvinder,
>
> APIs for selecting the architecure specific implementation and computing
> the crc (16-bit and 32-bit CRCs) are added. For CRCs calculation, scalar
> as well as x86 intrinsic(sse4.2) versions are implemented.
>
> The scalar version is based on generic Look-Up Table(LUT) algorit
Hi Adrien,
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com]
> Sent: Friday, March 10, 2017 7:46 PM
> To: Lu, Wenzhuo
> Cc: Le Scouarnec Nicolas; dev@dpdk.org
> Subject: Re: FW: Issues with ixgbe and rte_flow
>
> Hi,
>
> On Fri, Mar 10, 2017 at 07:12:24AM
This patch provides a set of tests for verifying the functional
correctness of 16-bit and 32-bit CRC APIs.
Signed-off-by: Jasvinder Singh
---
app/test/Makefile | 2 +
app/test/test_crc.c | 265
2 files changed, 267 insertions(+)
create mo
APIs for selecting the architecure specific implementation and computing
the crc (16-bit and 32-bit CRCs) are added. For CRCs calculation, scalar
as well as x86 intrinsic(sse4.2) versions are implemented.
The scalar version is based on generic Look-Up Table(LUT) algorithm,
while x86 intrinsic vers
In some applications, CRC (Cyclic Redundancy Check) needs to be computed
or updated during packet processing operations. This patchset adds
software implementation of some common standard CRCs (32-bit Ethernet
CRC as per Ethernet/[ISO/IEC 8802-3] and 16-bit CCITT-CRC [ITU-T X.25]).
Two versions of
This patch adds MTU display to "show port info" command.
Signed-off-by: Maxime Coquelin
---
app/test-pmd/config.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 80491fc..73d9603 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/co
Signed-off-by: Maxime Coquelin
---
doc/guides/rel_notes/release_17_05.rst | 8
1 file changed, 8 insertions(+)
diff --git a/doc/guides/rel_notes/release_17_05.rst
b/doc/guides/rel_notes/release_17_05.rst
index 4b90036..86a3363 100644
--- a/doc/guides/rel_notes/release_17_05.rst
+++ b/d
This patch implements support for the Virtio MTU feature.
When negotiated, the host shares its maximum supported MTU,
which is used as initial MTU and as maximum MTU the application
can set.
Signed-off-by: Maxime Coquelin
---
doc/guides/nics/features/virtio.ini | 1 +
drivers/net/virtio/virtio_
This patch adds a call to rte_vhost_mtu_get() at device creation
time to fill device's MTU property when available.
This makes the MTU value defined in QEMU cmdline accessible to the
application by calling rte_eth_dev_get_mtu().
Signed-off-by: Maxime Coquelin
---
drivers/net/vhost/rte_eth_vhost
Introduce a new API rte_vhost_get_mtu() to export the MTU value
of the interface to the application.
Signed-off-by: Maxime Coquelin
---
lib/librte_vhost/rte_vhost_version.map | 7 +++
1 file changed, 7 insertions(+)
diff --git a/lib/librte_vhost/rte_vhost_version.map
b/lib/librte_vhost/rte
This patch implements the function for the application to
get the MTU value.
rte_vhost_get_mtu() fills the mtu parameter with the MTU value
set in QEMU if VIRTIO_NET_F_MTU has been negotiated and returns 0,
-ENOTSUP otherwise.
The function returns -EAGAIN if Virtio feature negotiation
didn't happ
This patch adds a new status flag indicating the Virtio device
is ready to operate.
This is required to be able to call rte_vhost_mtu_get() in the
.new_device() callback, as rte_vhost_mtu_get needs that the
negotiation is done, but it is too early to rely on running status
flag, which is set just
This patch implements the vhost-user MTU protocol feature support.
When VIRTIO_NET_F_MTU is negotiated, QEMU notifies the vhost-user
backend with the configured MTU if dedicated protocol feature is
supported.
The value can be used by the application to ensure consistency with
value set by the user
This patch enables the new VIRTIO_NET_F_MTU feature,
which makes possible for the host to advise the guest
with its maximum supported MTU.
MTU value is set via QEMU parameters, either via Libvirt XML, or
directly in virtio-net device command line arguments.
Signed-off-by: Maxime Coquelin
---
li
This series adds support to new Virtio's MTU feature[1]. The MTU
value is set via QEMU parameters.
If the feature is negotiated (i.e supported by both host and guest,
and valid MTU value is set in QEMU via its host_mtu parameter), QEMU
shares the configured MTU value throught dedicated Vhost proto
If the hash table created with RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD extra
flags, and more one worker add same value and same key. the firt worker will
add value & key success, and second worker will execute lock and found a exist
value & key and return exist index without unlock. then it cour
Enable Thunderx nicvf PMD driver in the common
config as it does not have build dependency
with any external library and/or architecture.
Signed-off-by: Jerin Jacob
---
config/common_base | 2 +-
config/defconfig_arm64-thunderx-linuxapp-gcc | 10 --
doc/guides/
SIMPLEQ_* operations are not available in FreeBSD. Replacing
with equivalent STAILQ_* operations.
Fixes: f2546f8e51b8 ("net/thunderx/base: add functions to store qsets")
Signed-off-by: Jerin Jacob
---
v2:
Fix FreeBSD build issues reported by
http://dpdk.org/ml/archives/test-report/2017-March/013
Fixes: e438796617dc ("net/thunderx: add PMD skeleton")
Signed-off-by: Jerin Jacob
---
drivers/net/thunderx/nicvf_struct.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/thunderx/nicvf_struct.h
b/drivers/net/thunderx/nicvf_struct.h
index c900e12..0e4e1dd
Add below command line to configure ptype mapping.
ptype mapping get .
ptype mapping replace.
ptype mapping reset .
ptype mapping update .
Signed-off-by: Qi Zhang
---
app/test-pmd/cmdline.c | 372 +
1 file changed, 372 insertions(+)
diff --
The mapping from hardware defined packet type to software defined
packet type is static for i40e device, the patch let each ethdev to
to have their own copy of mapping table, this give the possibility
that different ethdev can be set different PTYPE mapping rule which
is the requirement to support
The patch set create new APIs that help to change the mapping from hardware
defined packet type to software defined packet type for i40e NICs.
Keep these APIs private is because currently they are only meaningful for
devices that support dynamic PTYPE configuration, which may not be a general
devi
The patch adds 4 APIs to support configurable
PTYPE mapping for i40e device.
rte_pmd_i40e_ptype_mapping_get.
rte_pmd_i40e_ptype_mapping_replace.
rte_pmd_i40e_ptype_mapping_reset.
rte_pmd_i40e_ptype_mapping_update.
The mapping from hardware defined packet type to software defined packet
type can be
On 03/08/2017 03:31 AM, Yuanhan Liu wrote:
On Mon, Mar 06, 2017 at 09:27:35AM +0100, Maxime Coquelin wrote:
+static int
+vhost_user_net_set_mtu(struct virtio_net *dev, struct VhostUserMsg *msg)
+{
+ if (msg->payload.u64 < VIRTIO_MIN_MTU ||
+ msg->payload.u64 > VIRTI
On 03/08/2017 03:45 AM, Yuanhan Liu wrote:
On Mon, Mar 06, 2017 at 09:27:37AM +0100, Maxime Coquelin wrote:
This patch implements the function for the application to
get the MTU value.
rte_vhost_mtu_get() fills the mtu parameter with the MTU value
set in QEMU if VIRTIO_NET_F_MTU has been nego
On 03/07/2017 10:57 PM, Thomas Monjalon wrote:
2017-03-06 09:27, Maxime Coquelin:
This series target v17.05 release.
I think you should add an entry in the release notes.
Sure. Will be in upcoming revision.
Thanks,
Maxime
Thursday, March 9, 2017 8:10 PM, Thomas Monjalon:
> 2017-02-08 15:57, Shahaf Shuler:
> > /**
> > + * It deletes registered eventfds.
> > + *
> > + * @param intr_handle
> > + * Pointer to the interrupt handle.
> > + */
> > +void
> > +rte_intr_free_epoll_fd(struct rte_intr_handle *intr_handle);
>
33 matches
Mail list logo
