[dpdk-dev] [RFC] ethdev: introduce GENEVE header extension item
The Geneve tunneling protocol is designed to allow
the user to specify some data context on the packet.
The header extension options is the mean intended
to present the user data. These ones are implemented
in TLV (Type-Length-Value) fashion, in order to
support these Geneve protocol feature we will
introduce the new item "rte_flow_item_geneve_option"
The support for new item will be added to testpmd
and include values and masks for the fields:
- class
- type
- data length
- data itself
The usage example:
"flow create 0 ingress pattern ipv4 / udp /
geneve / geneve_opt class is 102 type is 80
type mask ff data is 10002 data mask is
7fff / end actions drop / end "
New item will be added to testpmd to support
raw encap/decap action.
Signed-off-by: Shiri Kuzin
---
lib/librte_ethdev/rte_flow.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index da8bfa5..d04ee7c 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -347,6 +347,13 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_GENEVE,
/**
+* Matches a GENEVE Variable Length Option.
+*
+* See struct rte_flow_item_geneve_option.
+*/
+ RTE_FLOW_ITEM_TYPE_GENEVE_OPTION,
+
+ /**
* Matches a VXLAN-GPE header.
*
* See struct rte_flow_item_vxlan_gpe.
@@ -1097,6 +1104,24 @@ struct rte_flow_item_geneve {
#endif
/**
+ * RTE_FLOW_ITEM_TYPE_GENEVE_OPTION.
+ *
+ * Matches a GENEVE Variable Length Option
+ */
+struct rte_flow_item_geneve_option {
+ rte_be16_t option_class;
+ uint8_t option_type;
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint8_t length:5;
+ uint8_t rsvd0:3;
+#else
+ uint8_t rsvd0:3;
+ uint8_t length:5;
+#endif
+ uint8_t data[];
+};
+
+/**
* RTE_FLOW_ITEM_TYPE_VXLAN_GPE (draft-ietf-nvo3-vxlan-gpe-05).
*
* Matches a VXLAN-GPE header.
--
1.8.3.1
Re: [dpdk-dev] [RFC] ethdev: introduce GENEVE header extension item
On Sun, 16 Aug 2020 10:15:03 +
Shiri Kuzin wrote:
> The Geneve tunneling protocol is designed to allow
> the user to specify some data context on the packet.
> The header extension options is the mean intended
> to present the user data. These ones are implemented
> in TLV (Type-Length-Value) fashion, in order to
> support these Geneve protocol feature we will
> introduce the new item "rte_flow_item_geneve_option"
>
> The support for new item will be added to testpmd
> and include values and masks for the fields:
> - class
> - type
> - data length
> - data itself
>
> The usage example:
>
> "flow create 0 ingress pattern ipv4 / udp /
> geneve / geneve_opt class is 102 type is 80
> type mask ff data is 10002 data mask is
> 7fff / end actions drop / end "
>
> New item will be added to testpmd to support
> raw encap/decap action.
>
> Signed-off-by: Shiri Kuzin
> ---
> lib/librte_ethdev/rte_flow.h | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index da8bfa5..d04ee7c 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -347,6 +347,13 @@ enum rte_flow_item_type {
> RTE_FLOW_ITEM_TYPE_GENEVE,
>
> /**
> + * Matches a GENEVE Variable Length Option.
> + *
> + * See struct rte_flow_item_geneve_option.
> + */
> + RTE_FLOW_ITEM_TYPE_GENEVE_OPTION,
> +
> + /**
Please don't break ABI by putting items in middle of enum.
New items should go at the end.
enum changes the val
Re: [dpdk-dev] [PATCH 1/4] net/netvsc: move rxbuf_info from per-device to per-queue
On Mon, 10 Aug 2020 19:33:11 -0700
lon...@linuxonhyperv.com wrote:
> From: Long Li
>
> netvsc uses rxbuf_info buffer to track received packets attached via
> rte_pktmbuf_attach_extbuf() and ack the host based on usage count. It uses
> the transaction_id in the VMBus packet to locate where to use memory in the
> rxbuf_info.
>
> This is not correct in multiple channel setup, as different channels may
> return idential transaction_ids at a time, and may corrupt the rxbuf_info
> buffer.
>
> Fix this by defining rxbuf_info for each queue.
>
> Fixes: 4e9c73e96 ("net/netvsc: add Hyper-V network device")
> Cc: sta...@dpdk.org
> Signed-off-by: Long Li
Acked-by: Stephen Hemminger
Re: [dpdk-dev] [RFC v1 0/2] Add device emulation support in DPDK
Hi Stephen, > -Original Message- > From: Stephen Hemminger > Sent: Friday, August 14, 2020 11:00 PM > To: Xia, Chenbo > Cc: dev@dpdk.org; tho...@monjalon.net; Ding, Xuan ; > Lu, Xiuchun ; Liang, Cunming > ; Liu, Changpeng ; Wang, > Zhihong > Subject: Re: [dpdk-dev] [RFC v1 0/2] Add device emulation support in DPDK > > On Fri, 14 Aug 2020 19:16:04 + > Chenbo Xia wrote: > > > This series enables DPDK to be an alternative I/O device emulation > library of > > building virtualized devices in separate processes outside QEMU. It > introduces > > a new library (librte_vfio_user), a new device class (emudev) and one > pilot > > device provider (avf_emudev) with its backend of Ethdev PMD > (avfbe_ethdev). > > > > *librte_vfio_user* is a server implementation of VFIO-over-socket[1] > (also > > known as vfio-user) which is a protocol that allows a device to be > virtualized > > in a separate process outside of QEMU. > > > > *emudev* is a device type for emulated devices. It is up to device > provider to > > choose the transport. In avf_emudev case, it uses vfio-user as transport > > communicate with its client (e.g., QEMU). > > > > *avf_emudev* is the emudev provider of AVF which is a device > specification for > > Intel Virtual Function cross generation. It’s implemented by an AVF > emudev > > driver which offers a few APIs for avfbe_ethdev or app logic to operate. > > > > *avfbe_ethdev* is a normal ethdev PMD to supply the basic I/O as backend > data > > path of avf_emudev. One simple usage of avfbe_ethdev could be a para- > virtualized > > backend connected with network application logic. > > > > Background & Motivation > > --- > > In order to reduce the attack surface, QEMU community is disaggregating > QEMU by > > removing part of device emulation from it. The disaggregated/multi- > process QEMU > > is using VFIO-over-socket/vfio-user as the main transport mechanism to > disaggregate > > I/O services from QEMU[2]. Vfio-user essentially implements the VFIO > device model > > presented to the user process by a set of messages over a unix-domain > socket. The > > main difference between application using vfio-user and application > using vfio > > kernel module is that device manipulation is based on socket messages > for vfio-user > > but system calls for vfio kernel module. The vfio-user devices consist > of a generic > > VFIO device type, living in QEMU, which is called the client[3], and the > core device > > implementation (emulated device), living outside of QEMU, which is > called the server. > > > > With the introduction and support of vfio-user in QEMU, QEMU is > explicitly adding > > support for external emulated device and data path. We are trying to > leverage that > > and introducing vfio-user support in DPDK. By doing so, DPDK is enabled > to be an > > alternative I/O device emulation library of building virtualized devices > along with > > high-performance data path in separate processes outside QEMU. It will > be easy for > > hardware vendors to provide virtualized solutions of their hardware > devices by > > implementing emulated device in DPDK. > > > > Except for vfio-user introduced in DPDK, this series also introduces the > first > > emulated device implementation. That is emulated AVF device (avf_emudev) > implemented > > by AVF emulation driver (avf_emudev driver). Emulated AVF device demos > how emulated > > device could be implemented in DPDK. SPDK is also investigating to > implement use case > > for NVMe. > > > > Design overview > > --- > > > > +--- > ---+ > > | +---+ +---+ > | > > | | avf_emudev | | avfbe_ethdev | > | > > | |driver | | driver| > | > > | +---+ +---+ > | > > | | | > | > > | --- VDEV > BUS | > > | | | > | > > | +---+ +--+ > | > > +--+| | vdev: | | vdev:| > | > > | +--+ || | /path/to/vfio | | avf_emudev_# | > | > > | | Generic | || +---+ +--+ > | > > | | vfio-dev | || | > | > > | +--+ || | > | > > | +--+ || +--+ > | > > | | vfio-user| || | vfio-user| > | > > | | client | |<---|->| server | > | > > | +--+ || +--+ > | > > | QEMU || DPDK > | > > +--++--- > ---+ > > > > - vfio-user. Vfio-user in DPDK is referred to the vfio-user protocol > implementation > > playing server role. It provides transport between
Re: [dpdk-dev] [PATCH v2] common/iavf: mark internal symbols
> -Original Message-
> From: Wang, Haiyue
> Sent: Saturday, August 15, 2020 12:31 AM
> To: dev@dpdk.org
> Cc: Zhang, Qi Z ; Yang, Qiming
> ; Wang, Haiyue ; Wu,
> Jingjing ; Xing, Beilei ; Ray
> Kinsella ; Neil Horman
> Subject: [PATCH v2] common/iavf: mark internal symbols
>
> According to ABI policy, the internal functions should have the new tag
> __rte_internal and linked into INTERNAL sessions.
>
> Signed-off-by: Haiyue Wang
> ---
> v2: update the commit title
> ---
> drivers/common/iavf/iavf_prototype.h| 6 ++
> drivers/common/iavf/rte_common_iavf_version.map | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/common/iavf/iavf_prototype.h
> b/drivers/common/iavf/iavf_prototype.h
> index 31ce2af49..f34e77db0 100644
> --- a/drivers/common/iavf/iavf_prototype.h
> +++ b/drivers/common/iavf/iavf_prototype.h
> @@ -17,7 +17,9 @@
> */
>
> /* adminq functions */
> +__rte_internal
> enum iavf_status iavf_init_adminq(struct iavf_hw *hw);
> +__rte_internal
> enum iavf_status iavf_shutdown_adminq(struct iavf_hw *hw); enum
> iavf_status iavf_init_asq(struct iavf_hw *hw); enum iavf_status
> iavf_init_arq(struct iavf_hw *hw); @@ -30,6 +32,7 @@ void
> iavf_free_adminq_asq(struct iavf_hw *hw); void iavf_free_adminq_arq(struct
> iavf_hw *hw); enum iavf_status iavf_validate_mac_addr(u8 *mac_addr);
> void iavf_adminq_init_ring_data(struct iavf_hw *hw);
> +__rte_internal
> enum iavf_status iavf_clean_arq_element(struct iavf_hw *hw,
> struct iavf_arq_event_info *e,
> u16 *events_pending);
> @@ -61,6 +64,7 @@ enum iavf_status iavf_aq_set_rss_key(struct iavf_hw *hw,
> const char *iavf_aq_str(struct iavf_hw *hw, enum iavf_admin_queue_err
> aq_err); const char *iavf_stat_str(struct iavf_hw *hw, enum iavf_status
> stat_err);
>
> +__rte_internal
> enum iavf_status iavf_set_mac_type(struct iavf_hw *hw);
>
> extern struct iavf_rx_ptype_decoded iavf_ptype_lookup[]; @@ -76,9 +80,11
> @@ void iavf_acquire_spinlock(struct iavf_spinlock *sp); void
> iavf_release_spinlock(struct iavf_spinlock *sp); void
> iavf_destroy_spinlock(struct iavf_spinlock *sp);
>
> +__rte_internal
> void iavf_vf_parse_hw_config(struct iavf_hw *hw,
>struct virtchnl_vf_resource *msg); enum
> iavf_status
> iavf_vf_reset(struct iavf_hw *hw);
> +__rte_internal
> enum iavf_status iavf_aq_send_msg_to_pf(struct iavf_hw *hw,
> enum virtchnl_ops v_opcode,
> enum iavf_status v_retval,
> diff --git a/drivers/common/iavf/rte_common_iavf_version.map
> b/drivers/common/iavf/rte_common_iavf_version.map
> index 44142499e..e0f117197 100644
> --- a/drivers/common/iavf/rte_common_iavf_version.map
> +++ b/drivers/common/iavf/rte_common_iavf_version.map
> @@ -1,4 +1,4 @@
> -DPDK_21 {
> +INTERNAL {
> global:
>
> iavf_aq_send_msg_to_pf;
> --
> 2.28.0
Acked-by: Beilei Xing
Re: [dpdk-dev] [PATCH v2 1/7] rawdev: add private data length parameter to info fn
Hi,
> -Original Message-
> From: Richardson, Bruce
> Sent: Thursday, August 13, 2020 19:28
> To: Nipun Gupta ; Hemant Agrawal
>
> Cc: dev@dpdk.org; Richardson, Bruce ; Xu,
> Rosen ; Mcnamara, John
> ; Kovacevic, Marko
> ; Zhang, Tianfei ; Li,
> Xiaoyun ; Wu, Jingjing
> Subject: [PATCH v2 1/7] rawdev: add private data length parameter to info fn
>
> Currently with the rawdev API there is no way to check that the structure
> passed in via the dev_private pointer in the dev_info structure is of the
> correct type - it's just checked that it is non-NULL. Adding in the length of
> the
> expected structure provides a measure of typechecking, and can also be used
> for ABI compatibility in future, since ABI changes involving structs almost
> always involve a change in size.
>
> Signed-off-by: Bruce Richardson
> Reviewed-by: Rosen Xu
> ---
> app/test/test_rawdev.c | 2 +-
> doc/guides/rawdevs/ioat.rst | 2 +-
> doc/guides/sample_app_ug/ioat.rst | 2 +-
> drivers/bus/ifpga/ifpga_bus.c | 2 +-
> drivers/raw/ifpga/ifpga_rawdev.c| 5 +++--
> drivers/raw/ioat/ioat_rawdev.c | 5 +++--
> drivers/raw/ioat/ioat_rawdev_test.c | 4 ++--
> drivers/raw/ntb/ntb.c | 8 +++-
> drivers/raw/skeleton/skeleton_rawdev.c | 5 +++--
> drivers/raw/skeleton/skeleton_rawdev_test.c | 19 ---
> examples/ioat/ioatfwd.c | 2 +-
> examples/ntb/ntb_fwd.c | 2 +-
> lib/librte_rawdev/rte_rawdev.c | 6 --
> lib/librte_rawdev/rte_rawdev.h | 9 -
> lib/librte_rawdev/rte_rawdev_pmd.h | 5 -
> 15 files changed, 52 insertions(+), 26 deletions(-)
>
> diff --git a/app/test/test_rawdev.c b/app/test/test_rawdev.c index
> 524a9d5f3b..d8d9595be1 100644
> --- a/app/test/test_rawdev.c
> +++ b/app/test/test_rawdev.c
> @@ -34,7 +34,7 @@ test_rawdev_selftest_ioat(void)
>
> for (i = 0; i < count; i++) {
> struct rte_rawdev_info info = { .dev_private = NULL };
> - if (rte_rawdev_info_get(i, &info) == 0 &&
> + if (rte_rawdev_info_get(i, &info, 0) == 0 &&
> strstr(info.driver_name, "ioat") != NULL)
> return rte_rawdev_selftest(i) == 0 ?
> TEST_SUCCESS : TEST_FAILED;
> diff --git a/doc/guides/rawdevs/ioat.rst b/doc/guides/rawdevs/ioat.rst index
> d0eee5e237..dac52fabf1 100644
> --- a/doc/guides/rawdevs/ioat.rst
> +++ b/doc/guides/rawdevs/ioat.rst
> @@ -107,7 +107,7 @@ rawdev device for use by an application:
>
> for (i = 0; i < count && !found; i++) {
> struct rte_rawdev_info info = { .dev_private = NULL };
> -found = (rte_rawdev_info_get(i, &info) == 0 &&
> +found = (rte_rawdev_info_get(i, &info, 0) == 0 &&
> strcmp(info.driver_name,
> IOAT_PMD_RAWDEV_NAME_STR) ==
> 0);
> }
> diff --git a/doc/guides/sample_app_ug/ioat.rst
> b/doc/guides/sample_app_ug/ioat.rst
> index bab7654b8d..b5188220ba 100644
> --- a/doc/guides/sample_app_ug/ioat.rst
> +++ b/doc/guides/sample_app_ug/ioat.rst
> @@ -265,7 +265,7 @@ functions:
> do {
> if (rdev_id == rte_rawdev_count())
> goto end;
> -rte_rawdev_info_get(rdev_id++, &rdev_info);
> +rte_rawdev_info_get(rdev_id++, &rdev_info, 0);
> } while (strcmp(rdev_info.driver_name,
> IOAT_PMD_RAWDEV_NAME_STR) != 0);
>
> diff --git a/drivers/bus/ifpga/ifpga_bus.c b/drivers/bus/ifpga/ifpga_bus.c
> index 6b16a20bb6..bb8b3dcfb9 100644
> --- a/drivers/bus/ifpga/ifpga_bus.c
> +++ b/drivers/bus/ifpga/ifpga_bus.c
> @@ -162,7 +162,7 @@ ifpga_scan_one(struct rte_rawdev *rawdev,
> afu_dev->id.port = afu_pr_conf.afu_id.port;
>
> if (rawdev->dev_ops && rawdev->dev_ops->dev_info_get)
> - rawdev->dev_ops->dev_info_get(rawdev, afu_dev);
> + rawdev->dev_ops->dev_info_get(rawdev, afu_dev,
> sizeof(*afu_dev));
>
> if (rawdev->dev_ops &&
> rawdev->dev_ops->dev_start &&
> diff --git a/drivers/raw/ifpga/ifpga_rawdev.c
> b/drivers/raw/ifpga/ifpga_rawdev.c
> index cc25c662bc..47cfa38778 100644
> --- a/drivers/raw/ifpga/ifpga_rawdev.c
> +++ b/drivers/raw/ifpga/ifpga_rawdev.c
> @@ -605,7 +605,8 @@ ifpga_fill_afu_dev(struct opae_accelerator *acc,
>
> static void
> ifpga_rawdev_info_get(struct rte_rawdev *dev,
> - rte_rawdev_obj_t dev_info)
> + rte_rawdev_obj_t dev_info,
> + size_t dev_info_size)
> {
> struct opae_adapter *adapter;
> struct opae_accelerator *acc;
> @@ -617,7 +618,7 @@ ifpga_rawdev_info_get(struct rte_rawdev *dev,
>
> IFPGA_RAW
Re: [dpdk-dev] [RFC] ethdev: introduce GENEVE header extension item
Thanks, PSB.
> -Original Message-
> From: Stephen Hemminger
> Sent: Sunday, August 16, 2020 8:26 PM
> To: Shiri Kuzin
> Cc: dev@dpdk.org; Slava Ovsiienko ; NBU-
> Contact-Adrien Mazarguil ; Raslan
> Darawsheh
> Subject: Re: [dpdk-dev] [RFC] ethdev: introduce GENEVE header extension
> item
>
> On Sun, 16 Aug 2020 10:15:03 +
> Shiri Kuzin wrote:
>
> > The Geneve tunneling protocol is designed to allow the user to specify
> > some data context on the packet.
> > The header extension options is the mean intended to present the user
> > data. These ones are implemented in TLV (Type-Length-Value) fashion,
> > in order to support these Geneve protocol feature we will introduce
> > the new item "rte_flow_item_geneve_option"
> >
> > The support for new item will be added to testpmd and include values
> > and masks for the fields:
> > - class
> > - type
> > - data length
> > - data itself
> >
> > The usage example:
> >
> > "flow create 0 ingress pattern ipv4 / udp / geneve / geneve_opt class
> > is 102 type is 80 type mask ff data is 10002 data mask is 7fff /
> > end actions drop / end "
> >
> > New item will be added to testpmd to support raw encap/decap action.
> >
> > Signed-off-by: Shiri Kuzin
> > ---
> > lib/librte_ethdev/rte_flow.h | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_flow.h
> > b/lib/librte_ethdev/rte_flow.h index da8bfa5..d04ee7c 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -347,6 +347,13 @@ enum rte_flow_item_type {
> > RTE_FLOW_ITEM_TYPE_GENEVE,
> >
> > /**
> > +* Matches a GENEVE Variable Length Option.
> > +*
> > +* See struct rte_flow_item_geneve_option.
> > +*/
> > + RTE_FLOW_ITEM_TYPE_GENEVE_OPTION,
> > +
> > + /**
>
> Please don't break ABI by putting items in middle of enum.
> New items should go at the end.
> enum changes the val
Yes, thank you for the note.
I will move it to the end of the enum.
