* Re: [dpdk-dev] [PATCH v4] mk: fix compile error and ABI versioning for combined shared library
@ 2015-12-06 14:37 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-06 14:37 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
2015-12-03 13:51, Ferruh Yigit:
> Fixes following error (observed when versioning macros used):
> LD libdpdk.so
> /usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
> for symbol <function>@DPDK_x.y
>
> Also resulting combined library contains symbol version information:
> $ readelf -a build/lib/libdpdk.so | grep rte_eal_ | grep @ | head
> <...> GLOBAL DEFAULT 12 rte_eal_alarm_set@@DPDK_2.0
> <...> GLOBAL DEFAULT 12 rte_eal_pci_write_config@@DPDK_2.1
> <...> GLOBAL DEFAULT 12 rte_eal_remote_launch@@DPDK_2.0
> ...
>
> Versioning fixed by merging all version scripts into one automatically and
> feeding it to final library.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Applied, thanks
> +SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
I think SYMBOLS would be better named as VERSIONS.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
@ 2015-12-06 23:07 3% ` Thomas Monjalon
2015-12-07 2:00 0% ` Yuanhan Liu
2015-12-07 6:29 4% ` Panu Matilainen
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2015-12-06 23:07 UTC (permalink / raw)
To: Panu Matilainen, Yuanhan Liu; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
2015-12-02 15:53, Panu Matilainen:
> This (and other changes in patch 2 breaks the librte_vhost ABI again, so
> you'd need to at least add a deprecation note to 2.2 to be able to do it
> in 2.3 at all according to the ABI policy.
>
> Perhaps a better option would be adding some padding to the structs now
> for 2.2 since the vhost ABI is broken there anyway. That would at least
> give a chance to keep it compatible from 2.2 to 2.3.
Please could you point where the vhost ABI is broken in 2.2?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-06 23:07 3% ` Thomas Monjalon
@ 2015-12-07 2:00 0% ` Yuanhan Liu
2015-12-07 2:03 0% ` Thomas Monjalon
2015-12-07 6:29 4% ` Panu Matilainen
1 sibling, 1 reply; 200+ results
From: Yuanhan Liu @ 2015-12-07 2:00 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On Mon, Dec 07, 2015 at 12:07:28AM +0100, Thomas Monjalon wrote:
> 2015-12-02 15:53, Panu Matilainen:
> > This (and other changes in patch 2 breaks the librte_vhost ABI again, so
> > you'd need to at least add a deprecation note to 2.2 to be able to do it
> > in 2.3 at all according to the ABI policy.
> >
> > Perhaps a better option would be adding some padding to the structs now
> > for 2.2 since the vhost ABI is broken there anyway. That would at least
> > give a chance to keep it compatible from 2.2 to 2.3.
>
> Please could you point where the vhost ABI is broken in 2.2?
Thomas, here are the changes to rte_virtio_net.h:
$ git diff 381316f6a225139d22d39b5ab8d50c40607924ca..19d4d7ef2a216b5418d8edb5b004d1a58bba3cc1 \
-- lib/librte_vhost/rte_virtio_net.h >
diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
index e3a21e5..426a70d 100644
--- a/lib/librte_vhost/rte_virtio_net.h
+++ b/lib/librte_vhost/rte_virtio_net.h
@@ -89,6 +89,7 @@ struct vhost_virtqueue {
volatile uint16_t last_used_idx_res; /**< Used for multiple devices reserving buffers. */
int callfd; /**< Used to notify the guest (trigger interrupt). */
int kickfd; /**< Currently unused as polling mode is enabled. */
+ int enabled;
struct buf_vector buf_vec[BUF_VECTOR_MAX]; /**< for scatter RX. */
} __rte_cache_aligned;
@@ -96,7 +97,6 @@ struct vhost_virtqueue {
* Device structure contains all configuration information relating to the device.
*/
struct virtio_net {
- struct vhost_virtqueue *virtqueue[VIRTIO_QNUM]; /**< Contains all virtqueue information. */
struct virtio_memory *mem; /**< QEMU memory and memory region information. */
uint64_t features; /**< Negotiated feature set. */
uint64_t protocol_features; /**< Negotiated protocol feature set. */
@@ -104,7 +104,9 @@ struct virtio_net {
uint32_t flags; /**< Device flags. Only used to check if device is running on data core. */
#define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
char ifname[IF_NAME_SZ]; /**< Name of the tap device or socket path. */
+ uint32_t virt_qp_nb; /**< number of queue pair we have allocated */
void *priv; /**< private context */
+ struct vhost_virtqueue *virtqueue[VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MAX]; /**< Contains all virtqueue information. */
} __rte_cache_aligned;
/**
@@ -131,7 +133,7 @@ struct virtio_memory {
};
/**
- * Device operations to add/remove device.
+ * Device and vring operations.
*
* Make sure to set VIRTIO_DEV_RUNNING to the device flags in new_device and
* remove it in destroy_device.
@@ -140,12 +142,18 @@ struct virtio_memory {
struct virtio_net_device_ops {
int (*new_device)(struct virtio_net *); /**< Add device. */
void (*destroy_device)(volatile struct virtio_net *); /**< Remove device. */
+
+ int (*vring_state_changed)(struct virtio_net *dev, uint16_t queue_id, int enable); /**< triggered when a vring is enabled or disabled */
};
static inline uint16_t __attribute__((always_inline))
rte_vring_available_entries(struct virtio_net *dev, uint16_t queue_id)
{
struct vhost_virtqueue *vq = dev->virtqueue[queue_id];
+
+ if (!vq->enabled)
+ return 0;
+
return *(volatile uint16_t *)&vq->avail->idx - vq->last_used_idx_res;
}
--yliu
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-07 2:00 0% ` Yuanhan Liu
@ 2015-12-07 2:03 0% ` Thomas Monjalon
2015-12-07 2:18 3% ` Yuanhan Liu
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-07 2:03 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
2015-12-07 10:00, Yuanhan Liu:
> On Mon, Dec 07, 2015 at 12:07:28AM +0100, Thomas Monjalon wrote:
> > 2015-12-02 15:53, Panu Matilainen:
> > > This (and other changes in patch 2 breaks the librte_vhost ABI again, so
> > > you'd need to at least add a deprecation note to 2.2 to be able to do it
> > > in 2.3 at all according to the ABI policy.
> > >
> > > Perhaps a better option would be adding some padding to the structs now
> > > for 2.2 since the vhost ABI is broken there anyway. That would at least
> > > give a chance to keep it compatible from 2.2 to 2.3.
> >
> > Please could you point where the vhost ABI is broken in 2.2?
>
> Thomas, here are the changes to rte_virtio_net.h:
>
>
> $ git diff 381316f6a225139d22d39b5ab8d50c40607924ca..19d4d7ef2a216b5418d8edb5b004d1a58bba3cc1 \
> -- lib/librte_vhost/rte_virtio_net.h >
[...]
The problem is that the changes are not noticed in the release notes
and the LIBABIVER is still 1.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-07 2:03 0% ` Thomas Monjalon
@ 2015-12-07 2:18 3% ` Yuanhan Liu
2015-12-07 2:49 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Yuanhan Liu @ 2015-12-07 2:18 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On Mon, Dec 07, 2015 at 03:03:24AM +0100, Thomas Monjalon wrote:
> 2015-12-07 10:00, Yuanhan Liu:
> > On Mon, Dec 07, 2015 at 12:07:28AM +0100, Thomas Monjalon wrote:
> > > 2015-12-02 15:53, Panu Matilainen:
> > > > This (and other changes in patch 2 breaks the librte_vhost ABI again, so
> > > > you'd need to at least add a deprecation note to 2.2 to be able to do it
> > > > in 2.3 at all according to the ABI policy.
> > > >
> > > > Perhaps a better option would be adding some padding to the structs now
> > > > for 2.2 since the vhost ABI is broken there anyway. That would at least
> > > > give a chance to keep it compatible from 2.2 to 2.3.
> > >
> > > Please could you point where the vhost ABI is broken in 2.2?
> >
> > Thomas, here are the changes to rte_virtio_net.h:
> >
> >
> > $ git diff 381316f6a225139d22d39b5ab8d50c40607924ca..19d4d7ef2a216b5418d8edb5b004d1a58bba3cc1 \
> > -- lib/librte_vhost/rte_virtio_net.h >
> [...]
>
> The problem is that the changes are not noticed in the release notes
> and the LIBABIVER is still 1.
Yeah, my bad. Firstly, I was not aware of it's an ABI change. Secondly,
I was landed to this team in the middle of v2.2 release, so that I have
limited experience of how those works in DPDK community.
Anyway, it's my fault. I should have realized that in the first time.
Should I send a patch to update LIBABIVER to 2 and update release note
now?
--yliu
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-07 2:18 3% ` Yuanhan Liu
@ 2015-12-07 2:49 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-07 2:49 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
2015-12-07 10:18, Yuanhan Liu:
> On Mon, Dec 07, 2015 at 03:03:24AM +0100, Thomas Monjalon wrote:
> > 2015-12-07 10:00, Yuanhan Liu:
> > > On Mon, Dec 07, 2015 at 12:07:28AM +0100, Thomas Monjalon wrote:
> > > > 2015-12-02 15:53, Panu Matilainen:
> > > > > This (and other changes in patch 2 breaks the librte_vhost ABI again, so
> > > > > you'd need to at least add a deprecation note to 2.2 to be able to do it
> > > > > in 2.3 at all according to the ABI policy.
> > > > >
> > > > > Perhaps a better option would be adding some padding to the structs now
> > > > > for 2.2 since the vhost ABI is broken there anyway. That would at least
> > > > > give a chance to keep it compatible from 2.2 to 2.3.
> > > >
> > > > Please could you point where the vhost ABI is broken in 2.2?
> > >
> > > Thomas, here are the changes to rte_virtio_net.h:
> > >
> > >
> > > $ git diff 381316f6a225139d22d39b5ab8d50c40607924ca..19d4d7ef2a216b5418d8edb5b004d1a58bba3cc1 \
> > > -- lib/librte_vhost/rte_virtio_net.h >
> > [...]
> >
> > The problem is that the changes are not noticed in the release notes
> > and the LIBABIVER is still 1.
>
> Yeah, my bad. Firstly, I was not aware of it's an ABI change. Secondly,
> I was landed to this team in the middle of v2.2 release, so that I have
> limited experience of how those works in DPDK community.
>
> Anyway, it's my fault. I should have realized that in the first time.
No it's not your fault, and it does not matter who is responsible.
> Should I send a patch to update LIBABIVER to 2 and update release note
> now?
Yes today or tomorrow please.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
@ 2015-12-07 3:01 14% Jijiang Liu
2015-12-07 3:16 7% ` Thomas Monjalon
2015-12-07 10:42 4% ` Chilikin, Andrey
0 siblings, 2 replies; 200+ results
From: Jijiang Liu @ 2015-12-07 3:01 UTC (permalink / raw)
To: dev
Announce ABI change for struct rte_eth_conf.
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1c7ab01..f50f0c7 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -19,3 +19,7 @@ Deprecation Notices
and table action handlers will be updated:
the pipeline parameter will be added, the packets mask parameter will be
either removed (for input port action handler) or made input-only.
+
+* ABI changes are planned for struct rte_eth_conf in order to support
+ tunneling packet configuration in unified tunneling API. The release 2.2 does not contain these ABI
+ changes, but release 2.3 will, and no backwards compatibility is planned.
--
1.7.7.6
^ permalink raw reply [relevance 14%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
2015-12-07 3:01 14% [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf Jijiang Liu
@ 2015-12-07 3:16 7% ` Thomas Monjalon
2015-12-07 3:30 8% ` Liu, Jijiang
2015-12-07 10:42 4% ` Chilikin, Andrey
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-07 3:16 UTC (permalink / raw)
To: Jijiang Liu; +Cc: dev
2015-12-07 11:01, Jijiang Liu:
> +* ABI changes are planned for struct rte_eth_conf in order to support
> + tunneling packet configuration in unified tunneling API. The release 2.2 does not contain these ABI
> + changes, but release 2.3 will, and no backwards compatibility is planned.
Please, more details would be appreciated.
We need to decide whether an ABI deprecation is the right choice.
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [PATCH] vhost: note the ABI changes
@ 2015-12-07 3:25 14% Yuanhan Liu
2015-12-14 0:33 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Yuanhan Liu @ 2015-12-07 3:25 UTC (permalink / raw)
To: dev
Note the ABI changes and update the ABI version to 2.
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
---
This patch is assumed to be applied on top of following patch:
http://dpdk.org/dev/patchwork/patch/9262/
---
doc/guides/rel_notes/release_2_2.rst | 13 ++++++++++++-
lib/librte_vhost/Makefile | 2 +-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 34237b9..3e92854 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -331,6 +331,17 @@ ABI Changes
* librte_cfgfile: Allow longer names and values by increasing the constants
CFG_NAME_LEN and CFG_VALUE_LEN to 64 and 256 respectively.
+* vhost: a new field enabled is added to the vhost_virtqueue structure.
+
+* vhost: a new field virt_qp_nb is added to virtio_net structure, and the
+ virtqueue field is moved to the end of virtio_net structure.
+
+* vhost: a new operation vring_state_changed is added to virtio_net_device_ops
+ structure.
+
+* vhost: a few spaces are reserved both at vhost_virtqueue and virtio_net
+ structure for future extension.
+
Shared Library Versions
-----------------------
@@ -365,4 +376,4 @@ The libraries prepended with a plus sign were incremented in this version.
librte_sched.so.1
+ librte_table.so.2
librte_timer.so.1
- librte_vhost.so.1
+ + librte_vhost.so.2
diff --git a/lib/librte_vhost/Makefile b/lib/librte_vhost/Makefile
index 6681f22..035b569 100644
--- a/lib/librte_vhost/Makefile
+++ b/lib/librte_vhost/Makefile
@@ -36,7 +36,7 @@ LIB = librte_vhost.a
EXPORT_MAP := rte_vhost_version.map
-LIBABIVER := 1
+LIBABIVER := 2
CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -D_FILE_OFFSET_BITS=64
ifeq ($(CONFIG_RTE_LIBRTE_VHOST_USER),y)
--
1.9.0
^ permalink raw reply [relevance 14%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
2015-12-07 3:16 7% ` Thomas Monjalon
@ 2015-12-07 3:30 8% ` Liu, Jijiang
2015-12-07 3:40 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Liu, Jijiang @ 2015-12-07 3:30 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Monday, December 07, 2015 11:17 AM
> To: Liu, Jijiang
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct
> rte_eth_conf
>
> 2015-12-07 11:01, Jijiang Liu:
> > +* ABI changes are planned for struct rte_eth_conf in order to support
> > + tunneling packet configuration in unified tunneling API. The release 2.2
> does not contain these ABI
> > + changes, but release 2.3 will, and no backwards compatibility is planned.
>
> Please, more details would be appreciated.
> We need to decide whether an ABI deprecation is the right choice.
* ABI changes are planned for struct rte_eth_conf in order to support
tunneling packet configuration in unified tunneling APIs, which is the rte_eth_dev_tunnel_configure
(uint8_t port_id, uint16_t rx_q, uint16_t tx_q, rte_eth_tunnel_conf * tunnel_conf) API is planned to add.
and the 'tunnel_conf' shloud be stored in global 'rte_eth_conf'.
The release 2.2 does not contain these ABI change, but release 2.3 will, and no backwards compatibility is planned.
Is it enough clear?
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
2015-12-07 3:30 8% ` Liu, Jijiang
@ 2015-12-07 3:40 4% ` Thomas Monjalon
2015-12-07 7:47 4% ` Liu, Jijiang
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-07 3:40 UTC (permalink / raw)
To: Liu, Jijiang; +Cc: dev
2015-12-07 03:30, Liu, Jijiang:
> Hi Thomas,
>
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Monday, December 07, 2015 11:17 AM
> > To: Liu, Jijiang
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct
> > rte_eth_conf
> >
> > 2015-12-07 11:01, Jijiang Liu:
> > > +* ABI changes are planned for struct rte_eth_conf in order to support
> > > + tunneling packet configuration in unified tunneling API. The release 2.2
> > does not contain these ABI
> > > + changes, but release 2.3 will, and no backwards compatibility is planned.
> >
> > Please, more details would be appreciated.
> > We need to decide whether an ABI deprecation is the right choice.
>
> * ABI changes are planned for struct rte_eth_conf in order to support
> tunneling packet configuration in unified tunneling APIs, which is the rte_eth_dev_tunnel_configure
> (uint8_t port_id, uint16_t rx_q, uint16_t tx_q, rte_eth_tunnel_conf * tunnel_conf) API is planned to add.
> and the 'tunnel_conf' shloud be stored in global 'rte_eth_conf'.
> The release 2.2 does not contain these ABI change, but release 2.3 will, and no backwards compatibility is planned.
>
> Is it enough clear?
No, I think we need an explanation in the commit message of what is
the purpose of rte_eth_dev_tunnel_configure() and tunnel_conf.
Ideally, an RFC patch would help.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: Add missing new line before code block
@ 2015-12-07 3:43 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-07 3:43 UTC (permalink / raw)
To: Tetsuya Mukawa; +Cc: dev
> > The patch adds missing new line to "Managing ABI updates" section.
> >
> > Signed-off-by: Tetsuya Mukawa <mukawa@igel.co.jp>
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Applied, thanks
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-06 23:07 3% ` Thomas Monjalon
2015-12-07 2:00 0% ` Yuanhan Liu
@ 2015-12-07 6:29 4% ` Panu Matilainen
2015-12-07 11:28 3% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-07 6:29 UTC (permalink / raw)
To: Thomas Monjalon, Yuanhan Liu; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On 12/07/2015 01:07 AM, Thomas Monjalon wrote:
> 2015-12-02 15:53, Panu Matilainen:
>> This (and other changes in patch 2 breaks the librte_vhost ABI again, so
>> you'd need to at least add a deprecation note to 2.2 to be able to do it
>> in 2.3 at all according to the ABI policy.
>>
>> Perhaps a better option would be adding some padding to the structs now
>> for 2.2 since the vhost ABI is broken there anyway. That would at least
>> give a chance to keep it compatible from 2.2 to 2.3.
>
> Please could you point where the vhost ABI is broken in 2.2?
>
The vhost ABI break was announced for DPDK 2.2 in commit
3c848bd7b1c6f4f681b833322a748fdefbb5fb2d:
> commit 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d
> Author: Ouyang Changchun <changchun.ouyang@intel.com>
> Date: Tue Jun 16 09:38:43 2015 +0800
>
> doc: announce ABI changes for vhost-user multiple queues
>
> It announces the planned ABI changes for vhost-user multiple
> queues feature on v2.2.
>
> Signed-off-by: Changchun Ouyang <changchun.ouyang@intel.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
So the ABI process was properly followed, except for actually bumping
LIBABIVER. Bumping LIBABIVER is mentioned in
doc/guides/contributing/versioning.rst but it doesn't specify *when*
this should be done, eg should the first patch breaking the ABI bump it
or should it done be shortly before the next stable release, or
something else. As it is, it seems a bit too easy to simply forget.
- Panu -
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
2015-12-07 3:40 4% ` Thomas Monjalon
@ 2015-12-07 7:47 4% ` Liu, Jijiang
2015-12-07 11:43 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Liu, Jijiang @ 2015-12-07 7:47 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Monday, December 07, 2015 11:40 AM
> To: Liu, Jijiang
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct
> rte_eth_conf
>
> 2015-12-07 03:30, Liu, Jijiang:
> > Hi Thomas,
> >
> > > -----Original Message-----
> > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > Sent: Monday, December 07, 2015 11:17 AM
> > > To: Liu, Jijiang
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct
> > > rte_eth_conf
> > >
> > > 2015-12-07 11:01, Jijiang Liu:
> > > > +* ABI changes are planned for struct rte_eth_conf in order to
> > > > +support
> > > > + tunneling packet configuration in unified tunneling API. The
> > > > +release 2.2
> > > does not contain these ABI
> > > > + changes, but release 2.3 will, and no backwards compatibility is
> planned.
> > >
> > > Please, more details would be appreciated.
> > > We need to decide whether an ABI deprecation is the right choice.
> >
> > * ABI changes are planned for struct rte_eth_conf in order to support
> > tunneling packet configuration in unified tunneling APIs, which is the
> rte_eth_dev_tunnel_configure
> > (uint8_t port_id, uint16_t rx_q, uint16_t tx_q, rte_eth_tunnel_conf *
> tunnel_conf) API is planned to add.
> > and the 'tunnel_conf' shloud be stored in global 'rte_eth_conf'.
> > The release 2.2 does not contain these ABI change, but release 2.3 will,
> and no backwards compatibility is planned.
> >
> > Is it enough clear?
>
> No, I think we need an explanation in the commit message of what is the
> purpose of rte_eth_dev_tunnel_configure() and tunnel_conf.
Ok, will do.
> Ideally, an RFC patch would help.
I'm working on RFC patch, but it probably will miss merge timeslot of this release.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
2015-12-07 3:01 14% [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf Jijiang Liu
2015-12-07 3:16 7% ` Thomas Monjalon
@ 2015-12-07 10:42 4% ` Chilikin, Andrey
1 sibling, 0 replies; 200+ results
From: Chilikin, Andrey @ 2015-12-07 10:42 UTC (permalink / raw)
To: Liu, Jijiang, dev
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu
> Sent: Monday, December 7, 2015 3:02 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
>
> Announce ABI change for struct rte_eth_conf.
>
> Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
Acked-by: Andrey Chilikin <andrey.chilikin@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-07 6:29 4% ` Panu Matilainen
@ 2015-12-07 11:28 3% ` Thomas Monjalon
2015-12-07 11:41 4% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-07 11:28 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
2015-12-07 08:29, Panu Matilainen:
> On 12/07/2015 01:07 AM, Thomas Monjalon wrote:
> > 2015-12-02 15:53, Panu Matilainen:
> >> This (and other changes in patch 2 breaks the librte_vhost ABI again, so
> >> you'd need to at least add a deprecation note to 2.2 to be able to do it
> >> in 2.3 at all according to the ABI policy.
> >>
> >> Perhaps a better option would be adding some padding to the structs now
> >> for 2.2 since the vhost ABI is broken there anyway. That would at least
> >> give a chance to keep it compatible from 2.2 to 2.3.
> >
> > Please could you point where the vhost ABI is broken in 2.2?
> >
>
> The vhost ABI break was announced for DPDK 2.2 in commit
> 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d:
[...]
> So the ABI process was properly followed, except for actually bumping
> LIBABIVER. Bumping LIBABIVER is mentioned in
> doc/guides/contributing/versioning.rst but it doesn't specify *when*
> this should be done, eg should the first patch breaking the ABI bump it
> or should it done be shortly before the next stable release, or
> something else. As it is, it seems a bit too easy to simply forget.
I thought it was not needed to explicitly say that commits must be atomic
and we do not have to wait to do the required changes.
In this case, I've missed it when reviewing the vhost patches breaking the
ABI.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-07 11:28 3% ` Thomas Monjalon
@ 2015-12-07 11:41 4% ` Panu Matilainen
2015-12-07 13:55 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-07 11:41 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On 12/07/2015 01:28 PM, Thomas Monjalon wrote:
> 2015-12-07 08:29, Panu Matilainen:
>> On 12/07/2015 01:07 AM, Thomas Monjalon wrote:
>>> 2015-12-02 15:53, Panu Matilainen:
>>>> This (and other changes in patch 2 breaks the librte_vhost ABI again, so
>>>> you'd need to at least add a deprecation note to 2.2 to be able to do it
>>>> in 2.3 at all according to the ABI policy.
>>>>
>>>> Perhaps a better option would be adding some padding to the structs now
>>>> for 2.2 since the vhost ABI is broken there anyway. That would at least
>>>> give a chance to keep it compatible from 2.2 to 2.3.
>>>
>>> Please could you point where the vhost ABI is broken in 2.2?
>>>
>>
>> The vhost ABI break was announced for DPDK 2.2 in commit
>> 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d:
> [...]
>> So the ABI process was properly followed, except for actually bumping
>> LIBABIVER. Bumping LIBABIVER is mentioned in
>> doc/guides/contributing/versioning.rst but it doesn't specify *when*
>> this should be done, eg should the first patch breaking the ABI bump it
>> or should it done be shortly before the next stable release, or
>> something else. As it is, it seems a bit too easy to simply forget.
>
> I thought it was not needed to explicitly say that commits must be atomic
> and we do not have to wait to do the required changes.
The "problem" is that during a development cycle, an ABI could be broken
several times but LIBABIVER should only be bumped once. So ABI breaking
commits will often not be atomic wrt LIBABIVER, no matter which way its
done.
For example libtool recommendation is that library versions are updated
only just before public releases:
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info
- Panu -
> In this case, I've missed it when reviewing the vhost patches breaking the
> ABI.
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
2015-12-07 7:47 4% ` Liu, Jijiang
@ 2015-12-07 11:43 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-07 11:43 UTC (permalink / raw)
To: Liu, Jijiang; +Cc: dev
2015-12-07 07:47, Liu, Jijiang:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2015-12-07 03:30, Liu, Jijiang:
> > > Hi Thomas,
> > >
> > > > -----Original Message-----
> > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > > Sent: Monday, December 07, 2015 11:17 AM
> > > > To: Liu, Jijiang
> > > > Cc: dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct
> > > > rte_eth_conf
> > > >
> > > > 2015-12-07 11:01, Jijiang Liu:
> > > > > +* ABI changes are planned for struct rte_eth_conf in order to
> > > > > +support
> > > > > + tunneling packet configuration in unified tunneling API. The
> > > > > +release 2.2
> > > > does not contain these ABI
> > > > > + changes, but release 2.3 will, and no backwards compatibility is
> > planned.
> > > >
> > > > Please, more details would be appreciated.
> > > > We need to decide whether an ABI deprecation is the right choice.
> > >
> > > * ABI changes are planned for struct rte_eth_conf in order to support
> > > tunneling packet configuration in unified tunneling APIs, which is the
> > rte_eth_dev_tunnel_configure
> > > (uint8_t port_id, uint16_t rx_q, uint16_t tx_q, rte_eth_tunnel_conf *
> > tunnel_conf) API is planned to add.
> > > and the 'tunnel_conf' shloud be stored in global 'rte_eth_conf'.
> > > The release 2.2 does not contain these ABI change, but release 2.3 will,
> > and no backwards compatibility is planned.
> > >
> > > Is it enough clear?
> >
> > No, I think we need an explanation in the commit message of what is the
> > purpose of rte_eth_dev_tunnel_configure() and tunnel_conf.
> Ok, will do.
> > Ideally, an RFC patch would help.
> I'm working on RFC patch, but it probably will miss merge timeslot of this release.
A RFC patch may be incomplete. The API changes are enough.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v10 1/4] Remove ABI requirement for external library builds.
2015-12-07 13:48 3% ` [dpdk-dev] [PATCH v10 0/4] " Remy Horton
@ 2015-12-07 13:48 4% ` Remy Horton
0 siblings, 0 replies; 200+ results
From: Remy Horton @ 2015-12-07 13:48 UTC (permalink / raw)
To: dev
Signed-off-by: Andrew G. Harvey <agh@cisco.com>
---
mk/rte.extlib.mk | 2 ++
mk/rte.lib.mk | 6 ++++++
2 files changed, 8 insertions(+)
diff --git a/mk/rte.extlib.mk b/mk/rte.extlib.mk
index ba066bc..4d459e4 100644
--- a/mk/rte.extlib.mk
+++ b/mk/rte.extlib.mk
@@ -31,6 +31,8 @@
MAKEFLAGS += --no-print-directory
+EXTLIB_BUILD := 1
+
# we must create the output dir first and recall the same Makefile
# from this directory
ifeq ($(NOT_FIRST_CALL),)
diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index 1f1b6e1..02734e3 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -40,11 +40,13 @@ VPATH += $(SRCDIR)
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
LIB := $(patsubst %.a,%.so.$(LIBABIVER),$(LIB))
+ifndef EXTLIB_BUILD
ifeq ($(CONFIG_RTE_NEXT_ABI),y)
LIB := $(LIB).1
endif
CPU_LDFLAGS += --version-script=$(SRCDIR)/$(EXPORT_MAP)
endif
+endif
_BUILD = $(LIB)
@@ -175,12 +177,16 @@ $(RTE_OUTPUT)/lib/$(LIB): $(LIB)
@[ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib
$(Q)cp -f $(LIB) $(RTE_OUTPUT)/lib
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+ifdef EXTLIB_BUILD
+ $(Q)ln -s -f $< $(basename $@)
+else
ifeq ($(CONFIG_RTE_NEXT_ABI),y)
$(Q)ln -s -f $< $(basename $(basename $@))
else
$(Q)ln -s -f $< $(basename $@)
endif
endif
+endif
#
# Clean all generated files
--
1.9.3
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v10 0/4] User-space ethtool sample application
@ 2015-12-07 13:48 3% ` Remy Horton
2015-12-07 13:48 4% ` [dpdk-dev] [PATCH v10 1/4] Remove ABI requirement for external library builds Remy Horton
0 siblings, 1 reply; 200+ results
From: Remy Horton @ 2015-12-07 13:48 UTC (permalink / raw)
To: dev
Further enhancements to the userspace ethtool implementation that was
submitted in 2.1 and packaged as a self-contained sample application.
Implements an rte_ethtool shim layer based on rte_ethdev API, along
with a command prompt driven demonstration application.
This patchset depends on:
* http://dpdk.org/dev/patchwork/patch/8070/
v10:
* Fixed non-creation of sub-dirs needed for combined lib build
* Rebased to latest origin/master
v9:
* Merged in upstream external lib dependency
* Added sanity check to shim MTU set function
* Added example to example/Makefile
* Rebased to latest master
v8:
* Rebased to latest origin/master
v7:
* Ringparam printouts wrong way round
* Ringparam help message corrections
* Use __rte_unused instead of __attribute__((unused))
* Allow Jumbo-sized MTUs
* Documentation style and spelling changes
v6:
* Fixed hang when run with zero available ports
* Fixed incorrect sanity check preventing EEPROM dumps
* Documentation additions
* Fixed RxMode accepting untagged packets
* Fixed ringparam allocation being too small
v5:
* Documentation changes
v4:
* Fixed assumption that master core always has id zero
* Changed 1:1 core-to-port to 2 core (ethtool & ports) design
* Included the correct documentation..
v3:
* Made use of enums for core state.
* Fixed Makefile issue.
* Fixed incorrect assumption with core ids.
* Changed handling of more ports than cores.
v2:
* Replaced l2fwd base with simpler application.
* Added ringparam functions.
* Added documentation.
Remy Horton (4):
Remove ABI requirement for external library builds.
mk: Fix missing directory with combined extlib build
example: add user-space ethtool sample application
doc: add user-space ethtool sample app guide & release notes
MAINTAINERS | 4 +
doc/guides/rel_notes/release_2_2.rst | 1 +
doc/guides/sample_app_ug/ethtool.rst | 160 +++++++
doc/guides/sample_app_ug/index.rst | 1 +
examples/Makefile | 1 +
examples/ethtool/Makefile | 48 ++
examples/ethtool/ethtool-app/Makefile | 54 +++
examples/ethtool/ethtool-app/ethapp.c | 873 ++++++++++++++++++++++++++++++++++
examples/ethtool/ethtool-app/ethapp.h | 41 ++
examples/ethtool/ethtool-app/main.c | 305 ++++++++++++
examples/ethtool/lib/Makefile | 57 +++
examples/ethtool/lib/rte_ethtool.c | 423 ++++++++++++++++
examples/ethtool/lib/rte_ethtool.h | 410 ++++++++++++++++
mk/rte.extlib.mk | 8 +
mk/rte.lib.mk | 6 +
15 files changed, 2392 insertions(+)
create mode 100644 doc/guides/sample_app_ug/ethtool.rst
create mode 100644 examples/ethtool/Makefile
create mode 100644 examples/ethtool/ethtool-app/Makefile
create mode 100644 examples/ethtool/ethtool-app/ethapp.c
create mode 100644 examples/ethtool/ethtool-app/ethapp.h
create mode 100644 examples/ethtool/ethtool-app/main.c
create mode 100644 examples/ethtool/lib/Makefile
create mode 100644 examples/ethtool/lib/rte_ethtool.c
create mode 100644 examples/ethtool/lib/rte_ethtool.h
--
1.9.3
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-07 11:41 4% ` Panu Matilainen
@ 2015-12-07 13:55 4% ` Thomas Monjalon
2015-12-07 16:48 4% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-07 13:55 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
2015-12-07 13:41, Panu Matilainen:
> On 12/07/2015 01:28 PM, Thomas Monjalon wrote:
> > 2015-12-07 08:29, Panu Matilainen:
> >> On 12/07/2015 01:07 AM, Thomas Monjalon wrote:
> >>> 2015-12-02 15:53, Panu Matilainen:
> >> The vhost ABI break was announced for DPDK 2.2 in commit
> >> 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d:
> > [...]
> >> So the ABI process was properly followed, except for actually bumping
> >> LIBABIVER. Bumping LIBABIVER is mentioned in
> >> doc/guides/contributing/versioning.rst but it doesn't specify *when*
> >> this should be done, eg should the first patch breaking the ABI bump it
> >> or should it done be shortly before the next stable release, or
> >> something else. As it is, it seems a bit too easy to simply forget.
> >
> > I thought it was not needed to explicitly say that commits must be atomic
> > and we do not have to wait to do the required changes.
>
> The "problem" is that during a development cycle, an ABI could be broken
> several times but LIBABIVER should only be bumped once. So ABI breaking
> commits will often not be atomic wrt LIBABIVER, no matter which way its
> done.
If the ABI version has already been changed, there should be a merge conflict.
I think it's better to manage a conflict than forget to update the version.
> For example libtool recommendation is that library versions are updated
> only just before public releases:
> https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info
Interesting link. It makes me think that we do not manage ABI break when
downgrading the library (case of only new API keeping the ABI number).
> > In this case, I've missed it when reviewing the vhost patches breaking the
> > ABI.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] scripts: support any legal git revisions as abi validation range
@ 2015-12-07 14:09 7% ` Panu Matilainen
2015-12-07 14:32 4% ` Thomas Monjalon
2015-12-07 22:38 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-07 14:09 UTC (permalink / raw)
To: dev
On 12/03/2015 04:05 PM, Panu Matilainen wrote:
> In addition to git tags, support validating abi between any legal
> gitrevisions(7) syntaxes, such as "validate-abi.sh -1 . <target>"
> "validate-abi.sh master mybranch <target>" etc in addition to
> validating between tags. Makes it easier to run the validator
> for in-development work.
>
> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
> ---
>
> v2 changes:
> - update usage and error messages to match new behavior
> - update documentation too (as suggested by John McNamara)
>
I started wondering why this didn't get applied along with the other
abi-validator changes and noticed this is sitting in patchwork in
"changes requested" state, which doesn't seem right: v2 added the
requested documentation.
The discussion around this patch did spur another request (ability to
pass parallel build flags to make) but that's entirely unrelated, so it
shouldn't hold up this one.
I've no intention of sending a v3 of this patch because AFAIK there's
nothing to fix and the make-flags thing does not belong here, but
resetting the state to "new" by myself feels like cheating or something
:) So what's the correct action here? There's preciously little
documentation about expected patchwork workflow and such.
- Panu -
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v2] scripts: support any legal git revisions as abi validation range
2015-12-07 14:09 7% ` Panu Matilainen
@ 2015-12-07 14:32 4% ` Thomas Monjalon
2015-12-07 16:08 4% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-07 14:32 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
2015-12-07 16:09, Panu Matilainen:
> On 12/03/2015 04:05 PM, Panu Matilainen wrote:
> > In addition to git tags, support validating abi between any legal
> > gitrevisions(7) syntaxes, such as "validate-abi.sh -1 . <target>"
> > "validate-abi.sh master mybranch <target>" etc in addition to
> > validating between tags. Makes it easier to run the validator
> > for in-development work.
> >
> > Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
> > Acked-by: Neil Horman <nhorman@tuxdriver.com>
> > ---
> >
> > v2 changes:
> > - update usage and error messages to match new behavior
> > - update documentation too (as suggested by John McNamara)
> >
>
> I started wondering why this didn't get applied along with the other
> abi-validator changes and noticed this is sitting in patchwork in
> "changes requested" state, which doesn't seem right: v2 added the
> requested documentation.
It seems to be an error.
> The discussion around this patch did spur another request (ability to
> pass parallel build flags to make) but that's entirely unrelated, so it
> shouldn't hold up this one.
Yes
> I've no intention of sending a v3 of this patch because AFAIK there's
> nothing to fix and the make-flags thing does not belong here, but
> resetting the state to "new" by myself feels like cheating or something
> :) So what's the correct action here? There's preciously little
> documentation about expected patchwork workflow and such.
It's not cheating.
Changing patchwork status and send such an email looks to be the right thing
to do.
Yes maybe we can improve the contributing guide.
Thanks
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] scripts: support any legal git revisions as abi validation range
2015-12-07 14:32 4% ` Thomas Monjalon
@ 2015-12-07 16:08 4% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2015-12-07 16:08 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On 12/07/2015 04:32 PM, Thomas Monjalon wrote:
> 2015-12-07 16:09, Panu Matilainen:
>> On 12/03/2015 04:05 PM, Panu Matilainen wrote:
>>> In addition to git tags, support validating abi between any legal
>>> gitrevisions(7) syntaxes, such as "validate-abi.sh -1 . <target>"
>>> "validate-abi.sh master mybranch <target>" etc in addition to
>>> validating between tags. Makes it easier to run the validator
>>> for in-development work.
>>>
>>> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
>>> Acked-by: Neil Horman <nhorman@tuxdriver.com>
>>> ---
>>>
>>> v2 changes:
>>> - update usage and error messages to match new behavior
>>> - update documentation too (as suggested by John McNamara)
>>>
>>
>> I started wondering why this didn't get applied along with the other
>> abi-validator changes and noticed this is sitting in patchwork in
>> "changes requested" state, which doesn't seem right: v2 added the
>> requested documentation.
>
> It seems to be an error.
>
>> The discussion around this patch did spur another request (ability to
>> pass parallel build flags to make) but that's entirely unrelated, so it
>> shouldn't hold up this one.
>
> Yes
>
>> I've no intention of sending a v3 of this patch because AFAIK there's
>> nothing to fix and the make-flags thing does not belong here, but
>> resetting the state to "new" by myself feels like cheating or something
>> :) So what's the correct action here? There's preciously little
>> documentation about expected patchwork workflow and such.
>
> It's not cheating.
> Changing patchwork status and send such an email looks to be the right thing
> to do.
Ok, done. Thanks for clarifying.
>
> Yes maybe we can improve the contributing guide.
Perhaps this could be used as a base, or referred to (assuming of course
the info is rasonably applicaple to dpdk too)?
https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow
- Panu -
> Thanks
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-07 13:55 4% ` Thomas Monjalon
@ 2015-12-07 16:48 4% ` Panu Matilainen
2015-12-07 17:47 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-07 16:48 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On 12/07/2015 03:55 PM, Thomas Monjalon wrote:
> 2015-12-07 13:41, Panu Matilainen:
>> On 12/07/2015 01:28 PM, Thomas Monjalon wrote:
>>> 2015-12-07 08:29, Panu Matilainen:
>>>> On 12/07/2015 01:07 AM, Thomas Monjalon wrote:
>>>>> 2015-12-02 15:53, Panu Matilainen:
>>>> The vhost ABI break was announced for DPDK 2.2 in commit
>>>> 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d:
>>> [...]
>>>> So the ABI process was properly followed, except for actually bumping
>>>> LIBABIVER. Bumping LIBABIVER is mentioned in
>>>> doc/guides/contributing/versioning.rst but it doesn't specify *when*
>>>> this should be done, eg should the first patch breaking the ABI bump it
>>>> or should it done be shortly before the next stable release, or
>>>> something else. As it is, it seems a bit too easy to simply forget.
>>>
>>> I thought it was not needed to explicitly say that commits must be atomic
>>> and we do not have to wait to do the required changes.
Heh, now that I look more carefully... it IS documented, line 38 of
contributing/versioning.rst:
> ABI versions are set at the time of major release labeling, and the
> ABI may change multiple times, without warning, between the last
> release label and the HEAD label of the git tree.
>> The "problem" is that during a development cycle, an ABI could be broken
>> several times but LIBABIVER should only be bumped once. So ABI breaking
>> commits will often not be atomic wrt LIBABIVER, no matter which way its
>> done.
>
> If the ABI version has already been changed, there should be a merge conflict.
> I think it's better to manage a conflict than forget to update the version.
What I'm thinking of is something that would tie LIBABIVER to the
deprecation announcement in a way that could be easily checked
(programmatically and manually). As it is now, its quite non-trivial to
figure what LIBABIVER *should* be for a given library at a given point -
you need to dig up deprecation.rst history and Makefile history and
whatnot, and its all quite error-prone.
>> For example libtool recommendation is that library versions are updated
>> only just before public releases:
>> https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info
>
> Interesting link. It makes me think that we do not manage ABI break when
> downgrading the library (case of only new API keeping the ABI number).
Hmm, not quite sure what you mean here, but full libtool-style
versioning is not really needed with symbol versioning.
- Panu -
>
>>> In this case, I've missed it when reviewing the vhost patches breaking the
>>> ABI.
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-07 16:48 4% ` Panu Matilainen
@ 2015-12-07 17:47 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-07 17:47 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
2015-12-07 18:48, Panu Matilainen:
> On 12/07/2015 03:55 PM, Thomas Monjalon wrote:
> > 2015-12-07 13:41, Panu Matilainen:
> >> On 12/07/2015 01:28 PM, Thomas Monjalon wrote:
> >>> 2015-12-07 08:29, Panu Matilainen:
> >>>> On 12/07/2015 01:07 AM, Thomas Monjalon wrote:
> >>>>> 2015-12-02 15:53, Panu Matilainen:
> >>>> The vhost ABI break was announced for DPDK 2.2 in commit
> >>>> 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d:
> >>> [...]
> >>>> So the ABI process was properly followed, except for actually bumping
> >>>> LIBABIVER. Bumping LIBABIVER is mentioned in
> >>>> doc/guides/contributing/versioning.rst but it doesn't specify *when*
> >>>> this should be done, eg should the first patch breaking the ABI bump it
> >>>> or should it done be shortly before the next stable release, or
> >>>> something else. As it is, it seems a bit too easy to simply forget.
> >>>
> >>> I thought it was not needed to explicitly say that commits must be atomic
> >>> and we do not have to wait to do the required changes.
>
> Heh, now that I look more carefully... it IS documented, line 38 of
> contributing/versioning.rst:
>
> > ABI versions are set at the time of major release labeling, and the
> > ABI may change multiple times, without warning, between the last
> > release label and the HEAD label of the git tree.
Interesting :)
> >> The "problem" is that during a development cycle, an ABI could be broken
> >> several times but LIBABIVER should only be bumped once. So ABI breaking
> >> commits will often not be atomic wrt LIBABIVER, no matter which way its
> >> done.
> >
> > If the ABI version has already been changed, there should be a merge conflict.
> > I think it's better to manage a conflict than forget to update the version.
>
> What I'm thinking of is something that would tie LIBABIVER to the
> deprecation announcement in a way that could be easily checked
> (programmatically and manually). As it is now, its quite non-trivial to
> figure what LIBABIVER *should* be for a given library at a given point -
> you need to dig up deprecation.rst history and Makefile history and
> whatnot, and its all quite error-prone.
Yes clearly we need a safer process.
You are welcome to suggest one.
I like the idea of being based on some "parse-able" RST changes.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] scripts: support any legal git revisions as abi validation range
2015-12-07 14:09 7% ` Panu Matilainen
@ 2015-12-07 22:38 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-07 22:38 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
2015-12-03 16:05, Panu Matilainen:
> In addition to git tags, support validating abi between any legal
> gitrevisions(7) syntaxes, such as "validate-abi.sh -1 . <target>"
> "validate-abi.sh master mybranch <target>" etc in addition to
> validating between tags. Makes it easier to run the validator
> for in-development work.
>
> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] vhost: reserve some spaces for virtio_net and vhost_virtqueue struct
@ 2015-12-07 23:54 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-07 23:54 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
2015-12-03 10:27, Yuanhan Liu:
> So that we will not break ABI in future extension by adding few more
> fields.
>
> Struct vhost_virtqueue is reserved with 16 qwords (the later vhost-live
> migration support would at least consume 3 of them), and struct virtio_net
> is reserved with a bit more, 64 qwords, as there is only one instance for
> a virtio nic instance.
>
> Note that both reservation are not placed at the end of the struct, but
> instead before the last field, since both the last field at the two struct
> take a lot spaces. Putting the reservation after it would divide those
> reserved fields to another cacheline. (we might need fix them in future, btw)
>
> CC: Panu Matilainen <pmatilai@redhat.com>
> CC: Thomas Monjalon <thomas.monjalon@6wind.com>
> CC: Michael S. Tsirkin <mst@redhat.com>
> CC: Victor Kaplansky <vkaplans@redhat.com>
> Suggested-by: Panu Matilainen <pmatilai@redhat.com>
> Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> ---
>
> Is the reservation a bit too large? :)
You are maintainer in this area.
Applied, thanks
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 0/3] Add VHOST PMD
@ 2015-12-08 1:12 3% ` Tetsuya Mukawa
2015-12-08 2:03 0% ` Yuanhan Liu
0 siblings, 1 reply; 200+ results
From: Tetsuya Mukawa @ 2015-12-08 1:12 UTC (permalink / raw)
To: dev, yuanhan.liu, huawei.xie
Hi Xie and Yuanhan,
Please let me make sure whether this patch is differed.
If it is differed, I guess I may need to add ABI breakage notice before
releasing DPDK-2.2, because the patches changes virtio_net structure.
Tetsuya,
On 2015/11/24 18:00, Tetsuya Mukawa wrote:
> The patch introduces a new PMD. This PMD is implemented as thin wrapper
> of librte_vhost.
>
> PATCH v5 changes:
> - Rebase on latest master.
> - Fix RX/TX routine to count RX/TX bytes.
> - Fix RX/TX routine not to count as error packets if enqueue/dequeue
> cannot send all packets.
> - Fix if-condition checking for multiqueues.
> - Add "static" to pthread variable.
> - Fix format.
> - Change default behavior not to receive queueing event from driver.
> - Split the patch to separate rte_eth_vhost_portid2vdev().
>
> PATCH v4 changes:
> - Rebase on latest DPDK tree.
> - Fix cording style.
> - Fix code not to invoke multiple messaging handling threads.
> - Fix code to handle vdev parameters correctly.
> - Remove needless cast.
> - Remove needless if-condition before rt_free().
>
> PATCH v3 changes:
> - Rebase on latest matser
> - Specify correct queue_id in RX/TX function.
>
> PATCH v2 changes:
> - Remove a below patch that fixes vhost library.
> The patch was applied as a separate patch.
> - vhost: fix crash with multiqueue enabled
> - Fix typos.
> (Thanks to Thomas, Monjalon)
> - Rebase on latest tree with above bernard's patches.
>
> PATCH v1 changes:
> - Support vhost multiple queues.
> - Rebase on "remove pci driver from vdevs".
> - Optimize RX/TX functions.
> - Fix resource leaks.
> - Fix compile issue.
> - Add patch to fix vhost library.
>
> RFC PATCH v3 changes:
> - Optimize performance.
> In RX/TX functions, change code to access only per core data.
> - Add below API to allow user to use vhost library APIs for a port managed
> by vhost PMD. There are a few limitations. See "rte_eth_vhost.h".
> - rte_eth_vhost_portid2vdev()
> To support this functionality, vhost library is also changed.
> Anyway, if users doesn't use vhost PMD, can fully use vhost library APIs.
> - Add code to support vhost multiple queues.
> Actually, multiple queues functionality is not enabled so far.
>
> RFC PATCH v2 changes:
> - Fix issues reported by checkpatch.pl
> (Thanks to Stephen Hemminger)
>
>
> Tetsuya Mukawa (3):
> vhost: Add callback and private data for vhost PMD
> vhost: Add VHOST PMD
> vhost: Add helper function to convert port id to virtio device pointer
>
> config/common_linuxapp | 6 +
> doc/guides/nics/index.rst | 1 +
> doc/guides/rel_notes/release_2_2.rst | 2 +
> drivers/net/Makefile | 4 +
> drivers/net/vhost/Makefile | 62 ++
> drivers/net/vhost/rte_eth_vhost.c | 796 ++++++++++++++++++++++++++
> drivers/net/vhost/rte_eth_vhost.h | 65 +++
> drivers/net/vhost/rte_pmd_vhost_version.map | 8 +
> lib/librte_vhost/rte_vhost_version.map | 6 +
> lib/librte_vhost/rte_virtio_net.h | 3 +
> lib/librte_vhost/vhost_user/virtio-net-user.c | 13 +-
> lib/librte_vhost/virtio-net.c | 60 +-
> lib/librte_vhost/virtio-net.h | 4 +-
> mk/rte.app.mk | 8 +-
> 14 files changed, 1024 insertions(+), 14 deletions(-)
> create mode 100644 drivers/net/vhost/Makefile
> create mode 100644 drivers/net/vhost/rte_eth_vhost.c
> create mode 100644 drivers/net/vhost/rte_eth_vhost.h
> create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 0/3] Add VHOST PMD
2015-12-08 1:12 3% ` Tetsuya Mukawa
@ 2015-12-08 2:03 0% ` Yuanhan Liu
2015-12-08 2:10 0% ` Tetsuya Mukawa
0 siblings, 1 reply; 200+ results
From: Yuanhan Liu @ 2015-12-08 2:03 UTC (permalink / raw)
To: Tetsuya Mukawa, Xie, Huawei; +Cc: dev
On Tue, Dec 08, 2015 at 10:12:52AM +0900, Tetsuya Mukawa wrote:
> Hi Xie and Yuanhan,
>
> Please let me make sure whether this patch is differed.
> If it is differed, I guess I may need to add ABI breakage notice before
Tetsuya,
What do you mean by "differed"? Do you mean "delayed"?
Per my understanding, it's a bit late for v2.2 (even at few weeks
before). On the other hand, I'm still waiting for comments from
Huawei, for there are still one or two issues need more discussion.
> releasing DPDK-2.2, because the patches changes virtio_net structure.
I had sent a patch (which is just applied by Thomas) for reserving
some spaces for both virtio_net and vhost_virtqueue structure, so
it will not break anything if you simply add few more fields :)
--yliu
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 0/3] Add VHOST PMD
2015-12-08 2:03 0% ` Yuanhan Liu
@ 2015-12-08 2:10 0% ` Tetsuya Mukawa
0 siblings, 0 replies; 200+ results
From: Tetsuya Mukawa @ 2015-12-08 2:10 UTC (permalink / raw)
To: Yuanhan Liu, Xie, Huawei; +Cc: dev
On 2015/12/08 11:03, Yuanhan Liu wrote:
> On Tue, Dec 08, 2015 at 10:12:52AM +0900, Tetsuya Mukawa wrote:
>> Hi Xie and Yuanhan,
>>
>> Please let me make sure whether this patch is differed.
>> If it is differed, I guess I may need to add ABI breakage notice before
> Tetsuya,
>
> What do you mean by "differed"? Do you mean "delayed"?
Hi Yuanhan,
I just guess the patch will not be merged in DPDK-2.2.
> Per my understanding, it's a bit late for v2.2 (even at few weeks
> before). On the other hand, I'm still waiting for comments from
> Huawei, for there are still one or two issues need more discussion.
Yes, I agree with you.
>> releasing DPDK-2.2, because the patches changes virtio_net structure.
> I had sent a patch (which is just applied by Thomas) for reserving
> some spaces for both virtio_net and vhost_virtqueue structure, so
> it will not break anything if you simply add few more fields :)
Sounds great idea!
Thanks for handling virtio things.
Tetsuya,
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
@ 2015-12-08 17:03 5% ` Robie Basak
2015-12-09 14:16 5% ` Neil Horman
0 siblings, 1 reply; 200+ results
From: Robie Basak @ 2015-12-08 17:03 UTC (permalink / raw)
To: Neil Horman; +Cc: dev
On Wed, Dec 02, 2015 at 06:44:19AM -0500, Neil Horman wrote:
> Theres nothing "complex" about the simple fact that a project builds lots of
> libraries. Its extreemely common. Any graphic window manager has exactly the
> same situation, as do any number of tools that have multiple hardware backends
> impelmented in user space (v4l, sane, iptables, to name just a few).
>
> > Before I go into details, it would be nice if someone could please
> > explain why DPDK has to be "special" in needing to do this? I don't
> Its not special, see above. Not saying the build environment cant be improved,
> but the fact that there are multiple libraries is pretty straightforward.
It's fine in principle for an upstream to ship multiple shared
libraries, but it is extra and unnecessary work unless there's a
*reason* to have multiple shared libraries. What are the reasons for
DPDK?
> > In Debian and Ubuntu, we manage a library transition (an ABI bump in a
> > library together with all dependencies moving to use the new ABI) by
> > concurrently packaging both the old and new libraries at once. This
> > works well with the norm for libraries. We ship one binary package per
> > soname, with the major version as part of the package name. This allows
> > a system to have two (or more) ABIs installed simultaneously. For a
> > library transition, we just package the new version and then that can
> > land and work concurrently as we then individually update every
> > dependent (library-consuming) package.
> So thats, a distribution choice, not an upstream problem.
No, that's how shared libraries work. By design, multiple ABI versions
can be co-installed. That's why sonames have the ABI major version
inside them and the filenames reflect the sonames.
It is a distribution choice to exploit this capability. But it is an
upstream problem if this capability is broken.
By shipping multiple shared libraries, DPDK isn't breaking this
capability per se. But if the upstream expectation is that it's no
additional work for distributions because the multiple libraries can
just be bundled together into a single distribution package, then _this_
is what breaks the capability.
Instead DPDK needs to acknowledge that splitting libraries _does_ cause
additional packaging work for any distribution that wants to use the
multiple co-installed ABI feature of shared libraries as they are
designed.
Then, it becomes for upstream a question of the trade-off: does the
benefit of split libraries outweigh the extra work this creates on
packagers? To understand this, first I need to understand the rationale
for shipping multiple shared libaries specifically in DPDK, and I feel
that you (well, Red Hat) have yet to present a case.
> And it seems like a
> problem you should have already solved (note the examples above). If you feel
> like you need to package multiple ABI versions in the same library, you can,
> just update the LIBABIVER of all the libraries, instead of the ones that truly
> change, so that each library is guaranteed a newer so version, to make the
> library file name unique. Yes you have to make a small change from upstream,
> but thats part of the work that distribution maintainers do.
If it makes sense for upstream, it would be better for all if the code
was maintained in once place rather than fragmented across distribution
patches. My argument here is that _does_ make sense for upstream, which
is why I took the question to this list before we uploaded our first
patched version to Ubuntu.
> You must already have a solution to this, I can't imagine you package all the
> libraries for kde or gnome (or even pam) separately)
PAM modules are unversioned, since they are dynamically loaded plugins
and nothing actually links to them (in the sense that there are
no executables that link to them at exec time). The ABI is defined by
the version of PAM installed, not the version of the plugin. So I don't
think we can really compare to PAM.
I'm less familiar with KDE and GNOME packaging since I specialise on
server. But taking GNOME, for example, I am unable to find any binary
packages where multiple versioned shared objects have been bundled.
Their shared library packaging matches my expectations. For
example (source -> binary -> filename):
gdk-pixbuf -> libgdk-pixbuf2.0-0 -> /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
gconf -> libgconf-2-4 -> /usr/lib/x86_64-linux-gnu/libgconf-2.so.4
gtk+3.0 -> libgtk-3-0 -> /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
pango1.0 -> libpango-1.0-0 -> /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0
Each binary package supplies no more than one soname. (Again I've ignored
unversioned pluggable modules for the same reason as PAM). If this isn't
what you mean, please can you find me a counter-example? Given a soname
you can find the binary package that provides it at
https://www.debian.org/distrib/packages under "Search the contents of
packages". I suggest you set the distribution to "testing" to find more
current sonames.
Christian points out to me that libc6 does ship multiple sonames in a
single package, but I think it's acceptable to consider this to be a
special case that DPDK cannot really look to as an example. We don't
normally co-install multiple ABI versions of libc because a major ABI
bump in libc is extremely rare, and when we do it's a very special case
that is handled as a major distribution-wide project.
In answer to "You must already have a solution to this", we do. Our
solution is to produce one binary package per soname. My point is that
in the case of DPDK, this creates extra unnecessary work. Alternatively,
we could treat DPDK packaging as the same sort of gargantuan task that
packaging GNOME and KDE are, but without a good reason to split
libraries this would be an artifical and unnecessary burden placed on
packagers by DPDK upstream, which is why I am against upstream doing
this.
> > Packaging a library is usually virtually a no-op in Debian and Ubuntu
> > nowadays. Our tooling does it all for us. But packaging DPDK is far from
> > this currently because of all this added complexity. From my perspective
> > this is unnecessary and makes no sense. We could do all kinds of things
> > to work around it (that's what packaging is about) but then we'd have to
> > maintain that specialness and I don't see why it must be awkward like
> > this instead of just doing it the same way as every other library.
> >
> > > The combined library as it is simply is no longer a viable option.
> > > Besides just being broken (witness the strange hacks people are coming
> > > up with to work around issues in it) its ugly because it basically gives
> > > the middle finger to all the effort going into version compatibility,
> > > and its also big. Few projects will use every library in DPDK, but with
> > > the combined library they're forced to lug the 800 pound gorilla along
> > > needlessly.
> >
> > It's broken because it's broken upstream, and that's what we should fix.
> > Why is it not viable? How does it give the middle finger to effort going
> > into version compatibility?
> Because each individual library has a version script that gets applied during
> link to version symbols properly. Those scripts dont get applied when building
> the combined library.
So this is just an upstream bug that needs resolving in the combined
library case? Then I appreciate Ferruh Yigit's efforts in fixing this
bug upstream. Thank you Ferruh Yigit.
> > Doing it the right way like every other
> > userspace library is what *gives us* version compatibility because then
> > distributions can straightforwardly install multiple ABI versions at
> > once.
> Again, Not at all uncommon. You're packaging methodology is the issue here,
> not the fact that there are multiple libraries.
No, our packaging methdology is sound as I hope I've explained well
enough above. The real issue is the yet-to-be-justified decision to
split libraries creating unnecessary packaging work given that we wish
to shared libraries properly rather than bundling all the sonames
together (which defeats the point of split libraries in the first
place).
> > Finally, I fail to see any "lug the 800 pound gorilla along" saving. We
> > (Ubuntu and Fedora) are both shipping all the libraries in one package,
> > whether split or combined, so they are all being lugged onto disk
> > anyway. Whether split or combined, there is no saving there. And memory
> > is hardly saved either because the kernel will just page in and out what
> > is needed in both cases. So how does this proposed change give us any
> > saving at all?
> >
> Not true, initalization constructors for PMD's at the very least mean that every
> pmd will get paged in weather you want it or not using the combined library.
> Individual libraries let you dynamically load them (via dlopen). I think the
> same is true of several other facets of dpdk.
What's the objective impact of this? Can you quantify your claimed
saving? How does it compare to, say, the extra IOPS required in loading
multiple shared libraries and the extra pages that they could consume?
Are these things at all significant in an issue someone will face in the
real world?
On Tue, Dec 01, 2015 at 08:30:43AM -0500, Neil Horman wrote:
> On Tue, Dec 01, 2015 at 12:36:15PM +0000, Robie Basak wrote:
> > Why is limited symbol visibility a benefit in this case?
> >
> Because it prevents an application from inadvertently using symbols that would
> otherwise appear in another library (i.e. if not using the combined library, you
> know you've used a symbol in another library because you are then forced to add
> that library to the build.
Does Ferruh Yigit's patch address this?
On Thu, Dec 03, 2015 at 09:59:24AM -0500, Neil Horman wrote:
> I've seen the patch, and I appreciate the effort, but it really seems to me like
> more of the same. That is to say, its a good effort but it really creates
> additional ifrastructure to allow a single library to be built, but the fact of
> the matter is, a single library isn't needed. The build system is setup to
> crate multiple libraries, and a linker scripts allows for the combined library
> functionality, without adding additional clutter to the Makefiles. The argument
> that its more work to support multiple libraries in some distributions simply
> doesn't ring true with me, because that must be a problem which is already
> solved for other popular projects which are architected in a simmilar fashion.
I think I've rebutted all of this above. If you think there's any part
left here that I've failed to address, please let me know and I can go
into it.
Thanks,
Robie
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_flow
@ 2015-12-09 5:37 11% Jijiang Liu
2015-12-09 5:42 4% ` Lu, Wenzhuo
2015-12-14 15:03 4% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Jijiang Liu @ 2015-12-09 5:37 UTC (permalink / raw)
To: dev
The struct 'rte_eth_tunnel_flow' is only used by struct 'rte_eth_fdir_flow' now, but its name is generic,
and I plan to extend new fileds like below to support generic configuration for tunneling packet.
struct rte_eth_tunnel_flow {
enum rte_eth_fdir_tunnel_type tunnel_type; /**< Tunnel type to match. */
uint32_t tunnel_id; /**< Tunnel ID to match. TNI, VNI... */
uint16_t flags;
struct ether_addr outer_mac_src;
struct ether_addr outer_mac_dst;
union {
struct rte_eth_ipv4_flow outer_ipv4;
struct rte_eth_ipv6_flow outer_ipv6;
};
uint16_t dst_port;
uint16_t src_port;
struct ether_addr mac_addr; /**< Mac address to match. */
union {
struct rte_eth_ipv4_flow ipv4;
struct rte_eth_ipv6_flow ipv6;
};
};
Note: It have not finalized yet.
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1c7ab01..5c458f2 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -19,3 +19,7 @@ Deprecation Notices
and table action handlers will be updated:
the pipeline parameter will be added, the packets mask parameter will be
either removed (for input port action handler) or made input-only.
+
+* ABI changes are planned for struct rte_eth_tunnel_flow in order to extend new fileds to support
+ tunneling packet configuration in unified tunneling APIs. The release 2.2 does not contain these ABI
+ changes, but release 2.3 will, and no backwards compatibility is planned.
--
1.7.7.6
^ permalink raw reply [relevance 11%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_flow
2015-12-09 5:37 11% [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_flow Jijiang Liu
@ 2015-12-09 5:42 4% ` Lu, Wenzhuo
2015-12-14 15:03 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Lu, Wenzhuo @ 2015-12-09 5:42 UTC (permalink / raw)
To: Liu, Jijiang, dev
Hi,
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] dev Digest, Vol 68, Issue 68
[not found] <mailman.9342.1448631305.2486.dev@dpdk.org>
@ 2015-12-09 10:40 0% ` Betts, Ian
0 siblings, 0 replies; 200+ results
From: Betts, Ian @ 2015-12-09 10:40 UTC (permalink / raw)
To: dev
Date: Fri, 27 Nov 2015 15:09:24 +0200
From: Panu Matilainen <pmatilai@redhat.com>
To: "Doherty, Declan" <declan.doherty@intel.com>, Thomas Monjalon
<thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
Message-ID: <56585604.9030909@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 11/26/2015 03:51 PM, Doherty, Declan wrote:
>> -----Original Message-----
>> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
>> Sent: Thursday, November 26, 2015 10:09 AM
>> To: Panu Matilainen; Doherty, Declan
>> Cc: dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
>>
>> 2015-11-26 10:00, Panu Matilainen:
>>> On 11/26/2015 09:39 AM, Panu Matilainen wrote:
>>>> On 11/25/2015 07:38 PM, Thomas Monjalon wrote:
>>>>> --- a/config/common_linuxapp
>>>>> +++ b/config/common_linuxapp
>>>>> @@ -319,6 +319,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
>>>>>
>>>>> #
>>>>> # Compile generic crypto device library
>>>>> +# EXPERIMENTAL: API may change without prior notice
>>>>> #
>>>>> CONFIG_RTE_LIBRTE_CRYPTODEV=y
>>>>> CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
>>>> [...]
>>>>
>>>> I think an experimental library which declares itself exempt from the
>>>> ABI policy should not be compiled by default. That way anybody wanting
>>>> to try it out will be forced to notice the experimental status.
>>>>
>>>> More generally / longer term, perhaps there should be a
>>>> CONFIG_RTE_EXPERIMENTAL which wraps all experimental features and
>>>> defaults to off.
>>>
>>> On a related note, librte_mbuf_offload cannot be built if
>>> CONFIG_RTE_LIBRTE_CRYPTODEV is disabled. Which seems to suggest its (at
>>> least currently) so tightly couple to cryptodev that perhaps it too
>>> should be marked experimental and default to off.
>>
>> I think you are right.
>> Declan, what is your opinion?
>
>
> Hey Thomas, yes librte_mbuf_offload should also be set as experimental, it's
> probably one of the areas which will most likely change in the future.
>
> On the issue of turning off experimental libraries in the build by default, my
> preference would be not to turn them off unless the library has external
> dependencies, otherwise the possibility of patches being submitted which
> could break an experimental library will be much higher. In my opinion the
> fewer build configurations developers have to test against the better.
>>What I'm more worried about is users and developers starting to rely on
>>it while still in experimental state, a single comment in the header is
>>really easy to miss.
>>So I'd like to see *some* mechanism which forces users and developers to
>>acknowledge the fact that they're dealing with experimental work.
>>Defaulting to off is one possibility, another one would be wrapping
>>experimental APIs behind a define which you have to set to be able to
>>use the API, eg:
>>#if defined(I_KNOW_THIS_IS_EXPERIMENTAL_AND_MAY_EAT_BABIES)
>>[...]
>>#endif
>> - Panu -
I can see alternative/complementary that is to introduce a new "experimental" patch state in patchwork.
This approach might be useful to get wider exposure and feedback on experimental work earlier in its lifecycle.
Experimental patches may be constrained to a limited subset of target and host environments.
Experimental patches should be based off of a stable dpdk release, but would not be applied in the release.
Whilst the objective would be that any such patch would mature to become the kind of "experimental component"
as proposed above in this thread, and/or eventually be adopted as a mainstream component,
there would be no guarantee of that.
For the user it should very clearly be "Buyer beware" on such patches, and for the
developer community the support burden should be solely the responsibility of the
patch maintainer.
The only reason to have a new patchwork state is to make it easier to filter them in patchwork.
Some way of publishing the list of experimental patches available for a release would be
helpful, maybe as an addendum to the release note ?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
2015-12-08 17:03 5% ` Robie Basak
@ 2015-12-09 14:16 5% ` Neil Horman
0 siblings, 0 replies; 200+ results
From: Neil Horman @ 2015-12-09 14:16 UTC (permalink / raw)
To: Robie Basak; +Cc: dev
On Tue, Dec 08, 2015 at 05:03:26PM +0000, Robie Basak wrote:
> On Wed, Dec 02, 2015 at 06:44:19AM -0500, Neil Horman wrote:
> > Theres nothing "complex" about the simple fact that a project builds lots of
> > libraries. Its extreemely common. Any graphic window manager has exactly the
> > same situation, as do any number of tools that have multiple hardware backends
> > impelmented in user space (v4l, sane, iptables, to name just a few).
> >
> > > Before I go into details, it would be nice if someone could please
> > > explain why DPDK has to be "special" in needing to do this? I don't
> > Its not special, see above. Not saying the build environment cant be improved,
> > but the fact that there are multiple libraries is pretty straightforward.
>
> It's fine in principle for an upstream to ship multiple shared
> libraries, but it is extra and unnecessary work unless there's a
> *reason* to have multiple shared libraries. What are the reasons for
> DPDK?
>
Separation of functionality. There is no need to build a library that supports
10 different NICS when a given application is only using one. Likewise with
other discrete functionality, e.g. you don't link against the ACL library if you
dont' want to use ACL's.
> > > In Debian and Ubuntu, we manage a library transition (an ABI bump in a
> > > library together with all dependencies moving to use the new ABI) by
> > > concurrently packaging both the old and new libraries at once. This
> > > works well with the norm for libraries. We ship one binary package per
> > > soname, with the major version as part of the package name. This allows
> > > a system to have two (or more) ABIs installed simultaneously. For a
> > > library transition, we just package the new version and then that can
> > > land and work concurrently as we then individually update every
> > > dependent (library-consuming) package.
>
> > So thats, a distribution choice, not an upstream problem.
>
> No, that's how shared libraries work. By design, multiple ABI versions
> can be co-installed. That's why sonames have the ABI major version
> inside them and the filenames reflect the sonames.
>
We're talking about different things. The DPDK support ABI versioning in their
sonames, if you would look at the makefiles and output, you would clearly see
that. Theres no reason that multiple versions of DPDK can't be co-installed,
thats easy, the question here is weather it should support multiple discrete
libraries or only a single large library. It seems from your comments that a
single monolithic library should be the only option, and thats clearly the less
flexible one.
> It is a distribution choice to exploit this capability. But it is an
> upstream problem if this capability is broken.
>
Its not broken. In what way do you think soname versioning is broken in DPDK?
And in what way is it broken that the only solution is to merge all the
libraries into a single monolithic one?
> By shipping multiple shared libraries, DPDK isn't breaking this
> capability per se. But if the upstream expectation is that it's no
> additional work for distributions because the multiple libraries can
> just be bundled together into a single distribution package, then _this_
> is what breaks the capability.
>
> Instead DPDK needs to acknowledge that splitting libraries _does_ cause
> additional packaging work for any distribution that wants to use the
> multiple co-installed ABI feature of shared libraries as they are
> designed.
>
Very well, allowing multiple separate libraries causes some extra work for
packaging. Specifically it requires that distributions carry a patch that
instantiate a specific library ABI major version number that is incremented ni
lock step for every library in a given build (which is admittedly not what
upstream currently does). I don't see that as overly hard to do, but to each
their own.
However, the solution there is to propose a patch that defines a single ABI
variable in the makefile structure that is applied to every library on a symbol
version bump. The answer is _not_ to somehow entangle that with the idea that
we have to have a single monolithic library. Their separate issues, and you
can solve the problem that you are complaining about without throwing the
proverbial baby out with the bathwater.
> Then, it becomes for upstream a question of the trade-off: does the
> benefit of split libraries outweigh the extra work this creates on
> packagers? To understand this, first I need to understand the rationale
> for shipping multiple shared libaries specifically in DPDK, and I feel
> that you (well, Red Hat) have yet to present a case.
>
Some of the reasons I've mentioned above. Regardless however, the solution
your advocating to the problem you describe is orthogonal to the complaints
you're making there. If your goal is to allow multiple ABI versions in a given
package, then propose that ABI versions be incremented monolithically in the
upstream build. Even if a given library hasn't changed, it doesn't hurt to bump
the version number - that is to say, as a distribution, if an application links
against library A version 2, it will also link against library B version 2
(assuming it uses library B), even if library B has no ABI changes in it (thats
simply an artifact of how packaging works, you dont' typically mix and match
libraries from separate builds). So...just bump the soname version number, and
while you're at it, make it a global build setting, not a per library build
setting. Then you can use it to append a version number to the combined library
(script) as well
What you shouldn't do is assume that each library _has_ to have an independent
ABI version number, and use that to bootstrap an argument that the only solution
is a single combined library.
> > And it seems like a
> > problem you should have already solved (note the examples above). If you feel
> > like you need to package multiple ABI versions in the same library, you can,
> > just update the LIBABIVER of all the libraries, instead of the ones that truly
> > change, so that each library is guaranteed a newer so version, to make the
> > library file name unique. Yes you have to make a small change from upstream,
> > but thats part of the work that distribution maintainers do.
>
Yes, this makes good sense.
> If it makes sense for upstream, it would be better for all if the code
> was maintained in once place rather than fragmented across distribution
> patches. My argument here is that _does_ make sense for upstream, which
> is why I took the question to this list before we uploaded our first
> patched version to Ubuntu.
>
yes, thats fine. So, it seems like perhaps we're talking about the same
solution here. If we have a single LIBABIVER variable that is applied to each
DSO, why do we then further need to only allow a single combined library?
Neil
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH] doc: add patch submit cheatsheet
@ 2015-12-09 16:23 1% Harry van Haaren
2015-12-09 17:27 1% ` [dpdk-dev] [PATCH v2] " Harry van Haaren
0 siblings, 1 reply; 200+ results
From: Harry van Haaren @ 2015-12-09 16:23 UTC (permalink / raw)
To: dev
This patch adds the patch submission cheatsheet to
the contributers guide. Both HTML and PDF docs show
the cheatsheet on its own page.
Right clicking the SVG image in the HTML doc allows
for viewing the image on its own, useful for printing
in high quality.
The exact appearance of of the cheatsheet will depend
on the default monospace font installed.
Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
---
doc/guides/contributing/img/patch_cheatsheet.svg | 1404 ++++++++++++++++++++++
doc/guides/contributing/index.rst | 1 +
2 files changed, 1405 insertions(+)
create mode 100644 doc/guides/contributing/img/patch_cheatsheet.svg
diff --git a/doc/guides/contributing/img/patch_cheatsheet.svg b/doc/guides/contributing/img/patch_cheatsheet.svg
new file mode 100644
index 0000000..716df89
--- /dev/null
+++ b/doc/guides/contributing/img/patch_cheatsheet.svg
@@ -0,0 +1,1404 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ version="1.1"
+ width="210mm"
+ height="297mm"
+ id="svg2985"
+ inkscape:version="0.48.4 r9939"
+ sodipodi:docname="patch_cheatsheet.svg">
+ <sodipodi:namedview
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1"
+ objecttolerance="10"
+ gridtolerance="10"
+ guidetolerance="10"
+ inkscape:pageopacity="0"
+ inkscape:pageshadow="2"
+ inkscape:window-width="1184"
+ inkscape:window-height="1822"
+ id="namedview274"
+ showgrid="false"
+ inkscape:zoom="0.89702958"
+ inkscape:cx="346.69147"
+ inkscape:cy="480.70693"
+ inkscape:window-x="0"
+ inkscape:window-y="19"
+ inkscape:window-maximized="0"
+ inkscape:current-layer="g4115" />
+ <defs
+ id="defs3">
+ <linearGradient
+ x1="748.62079"
+ y1="-220.1862"
+ x2="849.99768"
+ y2="-220.1862"
+ id="SVGID_1_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop16"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop18"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop20"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop22"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="749.70099"
+ y1="-220.1864"
+ x2="848.91772"
+ y2="-220.1864"
+ id="SVGID_2_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop27"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop29"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop31"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop33"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="760.65948"
+ y1="-220.1864"
+ x2="899.29993"
+ y2="-220.1864"
+ id="SVGID_3_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop40"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop42"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop44"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop46"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="761.73969"
+ y1="-220.1864"
+ x2="898.21973"
+ y2="-220.1864"
+ id="SVGID_4_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop51"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop53"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop55"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop57"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="716.09821"
+ y1="-220.18649"
+ x2="874.64807"
+ y2="-220.18649"
+ id="SVGID_5_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop64"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop66"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop68"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop70"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="717.1781"
+ y1="-220.1864"
+ x2="873.56799"
+ y2="-220.1864"
+ id="SVGID_6_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop75"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop77"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop79"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop81"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ </defs>
+ <metadata
+ id="metadata4">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ <dc:title />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ id="layer1">
+ <switch
+ transform="matrix(0.49350192,0,0,0.49350192,2.6389834,-86.268333)"
+ id="switch3">
+ <g
+ id="g7">
+ <g
+ id="g9">
+ <g
+ id="g11">
+ <g
+ id="g13">
+ <linearGradient
+ x1="748.62079"
+ y1="-220.1862"
+ x2="849.99768"
+ y2="-220.1862"
+ id="linearGradient3172"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3174"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3176"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3178"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3180"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 137.8,342.7 c -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 l 43.3,-17.7 c 5,-1.9 8.9,-5.6 11.1,-10.4 2.2,-4.8 2.4,-10.2 0.5,-15.2 -2.9,-7.7 -10.4,-12.9 -18.6,-12.9 -2.4,0 -4.7,0.4 -7,1.3 l -63.2,22.3 c -0.8,0.3 -1.8,0.6 -2.7,0.6 -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 L 164,271.5 c 3.4,-1.3 6.8,-1.9 10.4,-1.9 12.3,0 23.4,7.7 27.7,19.2 2.8,7.4 2.5,15.4 -0.8,22.6 -3.3,7.2 -9.1,12.7 -16.5,15.5 L 140.5,342 c -0.7,0.3 -1.7,0.7 -2.7,0.7 z"
+ id="path24"
+ style="fill:url(#SVGID_1_)" />
+ <linearGradient
+ x1="749.70099"
+ y1="-220.1864"
+ x2="848.91772"
+ y2="-220.1864"
+ id="linearGradient3183"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3185"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3187"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3189"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3191"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="M 184.5,325.9 140.2,341 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 l 43.3,-17.7 c 10.8,-4.1 16.3,-16.2 12.3,-27 -4.1,-10.8 -16.2,-16.3 -27,-12.3 l -63.2,22.2 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 l 62.2,-24.8 c 14.7,-5.5 31.2,2 36.7,16.7 5.5,14.8 -1.9,31.2 -16.6,36.8 z"
+ id="path35"
+ style="fill:url(#SVGID_2_)" />
+ </g>
+ <g
+ id="g37">
+ <linearGradient
+ x1="760.65948"
+ y1="-220.1864"
+ x2="899.29993"
+ y2="-220.1864"
+ id="linearGradient3195"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3197"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3199"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3201"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3203"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 147.5,391.7 c -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 l 50.9,-20.6 c 35.7,-13.4 53.9,-53.4 40.5,-89.1 C 229.1,248 203.1,230 174.4,230 c -8.3,0 -16.4,1.5 -24.2,4.4 l -51.9,18 c -0.8,0.3 -1.8,0.6 -2.7,0.6 -1.4,0 -2.5,-0.8 -3,-2.2 -0.6,-1.6 0,-2.7 0.6,-3.4 0.7,-0.8 1.8,-1.2 2.8,-1.6 l 50.9,-20.6 c 8.9,-3.3 18.2,-5 27.7,-5 32.7,0 62.4,20.6 73.9,51.2 15.3,40.7 -5.4,86.3 -46.1,101.6 l -51.9,18 c -1,0.3 -2,0.7 -3,0.7 z"
+ id="path48"
+ style="fill:url(#SVGID_3_)" />
+ <linearGradient
+ x1="761.73969"
+ y1="-220.1864"
+ x2="898.21973"
+ y2="-220.1864"
+ id="linearGradient3206"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3208"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3210"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3212"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3214"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 201.8,372 -51.9,18 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 l 50.9,-20.6 c 36.3,-13.6 54.7,-54.2 41.1,-90.5 -13.6,-36.3 -54.2,-54.7 -90.5,-41.1 l -51.9,18 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 L 147,226.2 c 40.2,-15.1 85.1,5.3 100.2,45.5 15.1,40.3 -5.3,85.3 -45.4,100.3 z"
+ id="path59"
+ style="fill:url(#SVGID_4_)" />
+ </g>
+ <g
+ id="g61">
+ <linearGradient
+ x1="716.09821"
+ y1="-220.18649"
+ x2="874.64807"
+ y2="-220.18649"
+ id="linearGradient3218"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3220"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3222"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3224"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3226"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 97.1,384.3 c -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 L 190,340.9 c 23,-8.6 34.7,-34.4 26.1,-57.3 -6.5,-17.3 -23.3,-28.9 -41.7,-28.9 -5.3,0 -10.6,1 -15.6,2.8 l -83.9,30 c -0.8,0.3 -1.8,0.6 -2.7,0.6 -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 l 82.9,-32.6 c 6.1,-2.3 12.5,-3.5 19,-3.5 22.5,0 42.9,14.1 50.8,35.2 5.1,13.5 4.6,28.3 -1.4,41.5 -6,13.2 -16.8,23.3 -30.3,28.4 l -93.6,33.7 c -0.8,0.3 -1.8,0.7 -2.8,0.7 z"
+ id="path72"
+ style="fill:url(#SVGID_5_)" />
+ <linearGradient
+ x1="717.1781"
+ y1="-220.1864"
+ x2="873.56799"
+ y2="-220.1864"
+ id="linearGradient3229"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3231"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3233"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3235"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3237"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 193.1,348.9 -93.6,33.7 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 l 92.7,-36.2 C 214,333.1 226,306.7 217.2,283.2 208.4,259.7 182,247.7 158.5,256.5 l -83.8,30 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.8,-1.9 0.7,-2.8 2.7,-3.6 l 82.9,-32.6 c 27.4,-10.3 58.1,3.6 68.4,31.1 10.2,27.5 -3.7,58.2 -31.2,68.4 z"
+ id="path83"
+ style="fill:url(#SVGID_6_)" />
+ </g>
+ </g>
+ <g
+ id="g85">
+ <g
+ id="g87">
+ <path
+ d="m 300.7,235.7 h 33.5 c 30.7,0 51.8,19.4 51.8,47.5 0,28.1 -21.2,47.5 -51.8,47.5 h -33.5 v -95 z m 32.2,81.3 c 23.7,0 37.9,-13 37.9,-33.8 0,-20.8 -14.1,-33.8 -37.9,-33.8 H 315.7 V 317 h 17.2 z"
+ id="path89"
+ style="fill:#00233b" />
+ <path
+ d="m 419.8,235.7 h 40.8 c 20.1,0 31.8,11.5 31.8,27.5 0,16.3 -11.7,28.2 -31.8,28.2 h -25.9 v 39.2 h -14.9 v -94.9 z m 39.7,42 c 11.1,0 17.9,-5.2 17.9,-14.2 0,-9.2 -6.8,-14.1 -17.9,-14.1 h -24.7 v 28.4 h 24.7 z"
+ id="path91"
+ style="fill:#00233b" />
+ <path
+ d="m 523.2,235.7 h 33.5 c 30.7,0 51.8,19.4 51.8,47.5 0,28.1 -21.2,47.5 -51.8,47.5 h -33.5 v -95 z m 32.2,81.3 c 23.7,0 37.9,-13 37.9,-33.8 0,-20.8 -14.1,-33.8 -37.9,-33.8 H 538.2 V 317 h 17.2 z"
+ id="path93"
+ style="fill:#00233b" />
+ <path
+ d="m 642.4,235.7 h 14.9 v 38.8 l 38.9,-38.8 h 19.1 l -44,43.4 51,51.6 h -20.4 l -44.8,-45.6 v 45.6 h -14.9 v -95 z"
+ id="path95"
+ style="fill:#00233b" />
+ </g>
+ </g>
+ <g
+ id="g97">
+ <path
+ d="m 300.3,360 h 6.3 c 5.7,0 9.7,3.6 9.7,8.9 0,5.3 -4,8.9 -9.7,8.9 h -6.3 V 360 z m 6,15.2 c 4.4,0 7.1,-2.4 7.1,-6.3 0,-3.9 -2.6,-6.3 -7.1,-6.3 H 303 v 12.7 h 3.3 z"
+ id="path99"
+ style="fill:#f04e23" />
+ <path
+ d="m 324.6,359.9 h 2.7 l 7.8,17.9 h -3 l -1.9,-4.4 h -8.4 l -1.9,4.4 h -3 l 7.7,-17.9 z m 4.6,11 -3.3,-7.5 -3.3,7.5 h 6.6 z"
+ id="path101"
+ style="fill:#f04e23" />
+ <path
+ d="m 348.3,360 v 2.6 h -5.9 v 15.2 h -2.8 v -15.2 h -5.9 V 360 h 14.6 z"
+ id="path103"
+ style="fill:#f04e23" />
+ <path
+ d="m 354.7,359.9 h 2.7 l 7.8,17.9 h -3 l -1.9,-4.4 h -8.4 l -1.9,4.4 h -3 l 7.7,-17.9 z m 4.6,11 -3.3,-7.5 -3.3,7.5 h 6.6 z"
+ id="path105"
+ style="fill:#f04e23" />
+ <path
+ d="m 380.4,360 h 7.7 c 3.8,0 5.9,2.2 5.9,5.2 0,3.1 -2.2,5.3 -5.9,5.3 h -4.9 v 7.3 h -2.8 V 360 z m 7.4,7.8 c 2.1,0 3.4,-1 3.4,-2.7 0,-1.7 -1.3,-2.6 -3.4,-2.6 h -4.6 v 5.3 h 4.6 z"
+ id="path107"
+ style="fill:#f04e23" />
+ <path
+ d="m 397,360 h 2.8 v 15.2 h 9.5 v 2.6 H 397 V 360 z"
+ id="path109"
+ style="fill:#f04e23" />
+ <path
+ d="m 418.1,359.9 h 2.7 l 7.8,17.9 h -3 l -1.9,-4.4 h -8.4 l -1.9,4.4 h -3 l 7.7,-17.9 z m 4.6,11 -3.3,-7.5 -3.3,7.5 h 6.6 z"
+ id="path111"
+ style="fill:#f04e23" />
+ <path
+ d="m 431.1,360 h 2.4 l 10,12.9 V 360 h 2.7 v 17.8 H 444 l -10.1,-12.9 v 12.9 h -2.7 V 360 z"
+ id="path113"
+ style="fill:#f04e23" />
+ <path
+ d="m 450.5,360 h 12.7 v 2.6 h -9.9 v 4.4 h 8 v 2.6 h -8 v 5.6 h 10.2 v 2.6 h -13 V 360 z"
+ id="path115"
+ style="fill:#f04e23" />
+ <path
+ d="m 479.3,360 h 6.3 c 5.7,0 9.7,3.6 9.7,8.9 0,5.3 -4,8.9 -9.7,8.9 h -6.3 V 360 z m 6,15.2 c 4.4,0 7.1,-2.4 7.1,-6.3 0,-3.9 -2.6,-6.3 -7.1,-6.3 h -3.2 v 12.7 h 3.2 z"
+ id="path117"
+ style="fill:#f04e23" />
+ <path
+ d="m 498.8,360 h 12.7 v 2.6 h -9.9 v 4.4 h 8 v 2.6 h -8 v 5.6 h 10.2 v 2.6 h -13 V 360 z"
+ id="path119"
+ style="fill:#f04e23" />
+ <path
+ d="m 513.3,360 h 3.1 l 5.9,14 5.9,-14 h 3 l -7.6,17.9 H 521 L 513.3,360 z"
+ id="path121"
+ style="fill:#f04e23" />
+ <path
+ d="m 533.9,360 h 12.7 v 2.6 h -9.9 v 4.4 h 8 v 2.6 h -8 v 5.6 h 10.2 v 2.6 h -13 V 360 z"
+ id="path123"
+ style="fill:#f04e23" />
+ <path
+ d="m 549.9,360 h 2.8 v 15.2 h 9.5 v 2.6 H 549.9 V 360 z"
+ id="path125"
+ style="fill:#f04e23" />
+ <path
+ d="m 563,368.9 c 0,-5.2 3.8,-9.2 9.1,-9.2 5.3,0 9.1,4 9.1,9.2 0,5.2 -3.9,9.2 -9.1,9.2 -5.2,0 -9.1,-4.1 -9.1,-9.2 z m 15.3,0 c 0,-3.8 -2.7,-6.6 -6.2,-6.6 -3.5,0 -6.2,2.8 -6.2,6.6 0,3.8 2.7,6.6 6.2,6.6 3.5,0 6.2,-2.9 6.2,-6.6 z"
+ id="path127"
+ style="fill:#f04e23" />
+ <path
+ d="m 584.7,360 h 7.7 c 3.8,0 5.9,2.2 5.9,5.2 0,3.1 -2.2,5.3 -5.9,5.3 h -4.9 v 7.3 h -2.8 V 360 z m 7.5,7.8 c 2.1,0 3.4,-1 3.4,-2.7 0,-1.7 -1.3,-2.6 -3.4,-2.6 h -4.6 v 5.3 h 4.6 z"
+ id="path129"
+ style="fill:#f04e23" />
+ <path
+ d="m 601.3,360 h 2.8 l 5.8,8 5.7,-8 h 2.8 v 17.8 h -2.8 v -13.5 l -5,6.7 H 609 l -5,-6.7 v 13.5 h -2.8 V 360 z"
+ id="path131"
+ style="fill:#f04e23" />
+ <path
+ d="m 622.6,360 h 12.7 v 2.6 h -9.9 v 4.4 h 8 v 2.6 h -8 v 5.6 h 10.2 v 2.6 h -13 V 360 z"
+ id="path133"
+ style="fill:#f04e23" />
+ <path
+ d="m 638.7,360 h 2.4 l 10,12.9 V 360 h 2.7 v 17.8 h -2.4 l -10.1,-12.9 v 12.9 h -2.7 V 360 z"
+ id="path135"
+ style="fill:#f04e23" />
+ <path
+ d="m 671.3,360 v 2.6 h -5.9 v 15.2 h -2.8 v -15.2 h -5.9 V 360 h 14.6 z"
+ id="path137"
+ style="fill:#f04e23" />
+ <path
+ d="m 685.5,360 h 2.8 v 7.3 l 7.3,-7.3 h 3.6 l -8.2,8.1 9.6,9.7 h -3.8 l -8.4,-8.5 v 8.5 h -2.8 V 360 z"
+ id="path139"
+ style="fill:#f04e23" />
+ <path
+ d="m 702.8,360 h 2.8 v 17.8 h -2.8 V 360 z"
+ id="path141"
+ style="fill:#f04e23" />
+ <path
+ d="m 723.1,360 v 2.6 h -5.9 v 15.2 h -2.8 v -15.2 h -5.9 V 360 h 14.6 z"
+ id="path143"
+ style="fill:#f04e23" />
+ </g>
+ </g>
+ </g>
+ </switch>
+ <g
+ transform="translate(5.1368436,-0.8324168)"
+ id="g4009">
+ <text
+ x="388.02374"
+ y="96.855705"
+ id="text3212"
+ xml:space="preserve"
+ style="font-size:51.17281342px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="388.02374"
+ y="96.855705"
+ id="tspan3214">CHEATSHEET</tspan></text>
+ <text
+ x="386.51117"
+ y="58.178116"
+ transform="scale(1.0054999,0.99453018)"
+ id="text3212-1"
+ xml:space="preserve"
+ style="font-size:42.11373901px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="386.51117"
+ y="58.178116"
+ id="tspan3214-7">PATCH SUBMIT</tspan></text>
+ </g>
+ <rect
+ width="714.82172"
+ height="115.29619"
+ rx="20.776531"
+ ry="20.776531"
+ x="14.636383"
+ y="7.066123"
+ id="rect3239"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="713.29785"
+ height="858.14209"
+ rx="17.657345"
+ ry="16.712879"
+ x="15.398333"
+ y="132.72679"
+ id="rect3239-0"
+ style="fill:none;stroke:#00233b;stroke-width:0.99301994;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="694.99042"
+ height="351.07037"
+ rx="9.4767275"
+ ry="8.3695688"
+ x="24.315323"
+ y="629.73773"
+ id="rect3239-0-9-4"
+ style="fill:none;stroke:#00233b;stroke-width:0.98184335;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <path
+ d="m 386.3921,355.23442 323.14298,0"
+ id="path4088"
+ style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+ <text
+ x="396.18015"
+ y="342.45731"
+ id="text4090"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"><tspan
+ x="396.18015"
+ y="342.45731"
+ id="tspan4092"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Patch Pre-Checks</tspan></text>
+ <text
+ x="43.44949"
+ y="175.32129"
+ id="text4090-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"><tspan
+ x="43.44949"
+ y="175.32129"
+ id="tspan4092-3"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Commit Pre-Checks</tspan></text>
+ <text
+ x="397.1235"
+ y="172.8549"
+ id="text4090-4-3"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="397.1235"
+ y="172.8549"
+ id="tspan4092-3-3"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Bugfix?</tspan></text>
+ <text
+ x="41.215897"
+ y="662.38617"
+ id="text4090-1"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"><tspan
+ x="41.215897"
+ y="662.38617"
+ id="tspan4092-38"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Git send-email </tspan></text>
+ <path
+ d="m 31.232443,670.80575 376.113467,0"
+ id="path4088-7"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="342.13785"
+ height="230.74609"
+ rx="10.411126"
+ ry="10.411126"
+ x="25.418407"
+ y="142.92036"
+ id="rect3239-0-9-4-2"
+ style="fill:none;stroke:#00233b;stroke-width:0.93674862;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <text
+ x="43.44949"
+ y="413.8045"
+ id="text4090-86"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"><tspan
+ x="43.44949"
+ y="413.8045"
+ id="tspan4092-5"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Compile Pre-Checks</tspan></text>
+ <g
+ transform="translate(352.00486,-320.25973)"
+ id="g3295">
+ <text
+ x="43.87738"
+ y="568.03088"
+ id="text4090-8-14"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="43.87738"
+ y="568.03088"
+ id="tspan4289"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Include warning/error</tspan></text>
+ <text
+ x="43.87738"
+ y="537.71906"
+ id="text4090-8-14-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"><tspan
+ x="43.87738"
+ y="537.71906"
+ id="tspan4289-1"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Fixes line</tspan></text>
+ <text
+ x="43.87738"
+ y="598.9939"
+ id="text4090-8-14-0"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="43.87738"
+ y="598.9939"
+ id="tspan4289-2"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ How to reproduce</tspan></text>
+ </g>
+ <text
+ x="41.658669"
+ y="732.07019"
+ id="text4090-8-1-8"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="41.658669"
+ y="732.07019"
+ id="tspan4092-8-7-6"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Patch version ( eg: -v2 ) </tspan></text>
+ <text
+ x="41.658669"
+ y="764.29175"
+ id="text4090-8-1-8-0"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="41.658669"
+ y="764.29175"
+ id="tspan4092-8-7-6-2"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Patch version annotations</tspan></text>
+ <text
+ x="41.911205"
+ y="794.70355"
+ id="text4090-8-1-8-6"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="41.911205"
+ y="794.70355"
+ id="tspan4092-8-7-6-1"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Send --to maintainer </tspan></text>
+ <text
+ x="41.658669"
+ y="823.30548"
+ id="text4090-8-1-8-6-3"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="41.658669"
+ y="823.30548"
+ id="tspan4092-8-7-6-1-8"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Send --cc dev@dpdk.org </tspan></text>
+ <g
+ transform="translate(-2.6258125,1.2913854)"
+ id="g4115">
+ <g
+ id="g3272">
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1"
+ y="448.36987"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7"
+ y="448.36987"
+ x="49.093246">+ build gcc icc clang </tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2"
+ y="503.90326"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79"
+ y="503.90326"
+ x="49.093246">+ make test </tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2-0"
+ y="557.38586"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79-9"
+ y="557.38586"
+ x="49.093246">+ make doc</tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2-0-0"
+ y="528.66553"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79-9-0"
+ y="528.66553"
+ x="49.093246">+ make examples</tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2-0-07"
+ y="584.18359"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79-9-3"
+ y="584.18359"
+ x="49.093246">+ make shared-lib</tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2-0-07-4"
+ y="608.88947"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79-9-3-9"
+ y="608.88947"
+ x="49.093246">+ library ABI version</tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2-9"
+ y="477.21838"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79-3"
+ y="477.21838"
+ x="49.093246">+ build 32 and 64 bits</tspan></text>
+ </g>
+ </g>
+ <text
+ x="41.658669"
+ y="703.25287"
+ id="text4090-8-1-8-9"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="41.658669"
+ y="703.25287"
+ id="tspan4092-8-7-6-9"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Cover letter</tspan></text>
+ <text
+ x="49.163925"
+ y="905.1391"
+ id="text4090-8-1-8-65-9"
+ xml:space="preserve"
+ style="font-size:19px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace"
+ sodipodi:linespacing="125%"><tspan
+ sodipodi:role="line"
+ id="tspan3268"
+ x="49.163925"
+ y="905.1391">git send-email -N --to <maintainer> --cc dev@dpdk.org</tspan><tspan
+ sodipodi:role="line"
+ id="tspan3270"
+ x="49.163925"
+ y="928.8891"> --annotate [ --cover-letter --cc other@participants.com</tspan><tspan
+ sodipodi:role="line"
+ id="tspan3272"
+ x="49.163925"
+ y="952.6391"> -v[N] --in-reply-to <message ID> ]</tspan></text>
+ <text
+ x="543.47675"
+ y="1032.3459"
+ id="text4090-8-7-8-7-6-3-8-2-5"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="543.47675"
+ y="1032.3459"
+ id="tspan4092-8-6-3-1-8-4-4-5-3"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">harry.van.haaren@intel.com</tspan></text>
+ <rect
+ width="678.10907"
+ height="93.625999"
+ rx="6.5885701"
+ ry="5.7919135"
+ x="31.881868"
+ y="877.36865"
+ id="rect3239-0-9-4-3"
+ style="fill:none;stroke:#00233b;stroke-width:0.93965852;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <text
+ x="543.29498"
+ y="1018.1843"
+ id="text4090-8-7-8-7-6-3-8-2-5-3"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="543.29498"
+ y="1018.1843"
+ id="tspan4092-8-6-3-1-8-4-4-5-3-7"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Suggestions / Updates?</tspan></text>
+ <g
+ transform="translate(1.0962334,-12.034939)"
+ id="g3303">
+ <text
+ x="41.572586"
+ y="868.70337"
+ id="text4090-8-1-8-65"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"><tspan
+ x="41.572586"
+ y="868.70337"
+ id="tspan4092-8-7-6-10"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Send --in-reply-to <message ID><tspan
+ id="tspan3184"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold" /></tspan></text>
+ <text
+ x="402.63992"
+ y="856.58643"
+ id="text4090-8-1-8-9-1"
+ xml:space="preserve"
+ style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="402.63992"
+ y="856.58643"
+ id="tspan4092-8-7-6-9-7"
+ style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">****</tspan></text>
+ </g>
+ <text
+ x="684.10175"
+ y="115.17608"
+ id="text4090-8-1-8-9-1-9"
+ xml:space="preserve"
+ style="font-size:20.20989037px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"><tspan
+ x="684.10175"
+ y="115.17608"
+ id="tspan4092-8-7-6-9-7-4"
+ style="font-size:9.09445095px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">v1.0</tspan></text>
+ <rect
+ width="342.3053"
+ height="155.54948"
+ rx="9.2344503"
+ ry="9.2344503"
+ x="377.58942"
+ y="142.55766"
+ id="rect3239-0-9-4-2-1"
+ style="fill:none;stroke:#00233b;stroke-width:0.76930124;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="342.12564"
+ height="236.79482"
+ rx="10.647112"
+ ry="9.584527"
+ x="25.642178"
+ y="384.86249"
+ id="rect3239-0-9-4-2-0"
+ style="fill:none;stroke:#00233b;stroke-width:0.9489302;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="341.98428"
+ height="312.73181"
+ rx="8.5358429"
+ ry="8.5358429"
+ x="377.96762"
+ y="308.45331"
+ id="rect3239-0-9-4-2-1-9"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <path
+ d="m 387.02742,185.3408 323.14298,0"
+ id="path4088-8"
+ style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+ <path
+ d="m 36.504486,425.33869 323.142974,0"
+ id="path4088-82"
+ style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+ <path
+ d="m 35.494337,184.92238 323.142983,0"
+ id="path4088-4"
+ style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+ <g
+ transform="translate(1.0962334,-2.7492248)"
+ id="g3363">
+ <text
+ x="45.371201"
+ y="214.1572"
+ id="text4090-8-11"
+ xml:space="preserve"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="214.1572"
+ id="tspan4092-8-52"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Signed-off-by: </tspan></text>
+ <text
+ x="45.371201"
+ y="243.81795"
+ id="text4090-8-7-8"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="243.81795"
+ id="tspan4092-8-6-3"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Suggested-by:</tspan></text>
+ <text
+ x="45.371201"
+ y="273.90939"
+ id="text4090-8-7-8-7"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="273.90939"
+ id="tspan4092-8-6-3-1"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Reported-by:</tspan></text>
+ <text
+ x="45.371201"
+ y="304.00082"
+ id="text4090-8-7-8-7-6"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="304.00082"
+ id="tspan4092-8-6-3-1-8"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Tested-by:</tspan></text>
+ <g
+ id="g3297"
+ transform="translate(1.1147904,-7.2461378)">
+ <text
+ x="45.371201"
+ y="368.8187"
+ id="text4090-8-7-8-7-6-3"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="368.8187"
+ id="tspan4092-8-6-3-1-8-4"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Previous Acks</tspan></text>
+ <text
+ x="205.28914"
+ y="359.51453"
+ id="text4090-8-1-8-9-1-4"
+ xml:space="preserve"
+ style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="205.28914"
+ y="359.51453"
+ id="tspan4092-8-7-6-9-7-0"
+ style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ </g>
+ <text
+ x="45.371201"
+ y="334.52298"
+ id="text4090-8-7-8-7-6-3-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="334.52298"
+ id="tspan4092-8-6-3-1-8-4-0"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Commit message</tspan></text>
+ </g>
+ <rect
+ width="295.87207"
+ height="164.50136"
+ rx="7.3848925"
+ ry="4.489974"
+ x="414.80502"
+ y="639.47064"
+ id="rect3239-0-9-4-2-1-9-9"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <text
+ x="439.4429"
+ y="666.35608"
+ id="text4090-1-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"><tspan
+ x="439.4429"
+ y="666.35608"
+ id="tspan4092-38-8"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Mailing List</tspan></text>
+ <text
+ x="431.55353"
+ y="703.59857"
+ id="text4090-8-5-6-9-4-6-6-8"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"><tspan
+ x="431.55353"
+ y="703.59857"
+ id="tspan4092-8-5-5-3-4-0-6-2"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Acked-by:</tspan></text>
+ <text
+ x="431.39734"
+ y="762.18231"
+ id="text4090-8-5-6-9-4-6-6-8-5"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"><tspan
+ x="431.39734"
+ y="762.18231"
+ id="tspan4092-8-5-5-3-4-0-6-2-1"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Reviewed-by:</tspan></text>
+ <text
+ x="450.8428"
+ y="794.5578"
+ id="text4090-8-5-6-9-4-6-6-8-7"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"><tspan
+ x="450.8428"
+ y="794.5578"
+ id="tspan4092-8-5-5-3-4-0-6-2-11"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Nack (refuse patch)</tspan></text>
+ <path
+ d="m 426.99385,675.80575 272.72607,0"
+ id="path4088-7-5"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <path
+ d="m 424.7332,770.35699 272.72607,0"
+ id="path4088-7-5-2"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <text
+ x="431.39734"
+ y="732.78278"
+ id="text4090-8-5-6-9-4-6-6-8-5-1"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="431.39734"
+ y="732.78278"
+ id="tspan4092-8-5-5-3-4-0-6-2-1-7"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Tested-by:</tspan></text>
+ <g
+ transform="translate(1.0962334,-2.7492248)"
+ id="g3613">
+ <text
+ x="43.146141"
+ y="1007.5879"
+ id="text4090-8-7-8-7-6-3-8"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="43.146141"
+ y="1007.5879"
+ id="tspan4092-8-6-3-1-8-4-4"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">Previous Acks only when fixing typos, rebased, or checkpatch issues.</tspan></text>
+ <text
+ x="30.942892"
+ y="1011.3757"
+ id="text4090-8-7-8-7-6-3-8-4-1"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="30.942892"
+ y="1011.3757"
+ id="tspan4092-8-6-3-1-8-4-4-55-7"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ </g>
+ <g
+ transform="translate(1.0962334,-2.7492248)"
+ id="g3605">
+ <text
+ x="42.176418"
+ y="1020.4383"
+ id="text4090-8-7-8-7-6-3-8-4"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="42.176418"
+ y="1020.4383"
+ id="tspan4092-8-6-3-1-8-4-4-55"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">The version.map function names must be in alphabetical order.</tspan></text>
+ <text
+ x="30.942892"
+ y="1024.2014"
+ id="text4090-8-7-8-7-6-3-8-4-1-5"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="30.942892"
+ y="1024.2014"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-2"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="25.247679"
+ y="1024.2014"
+ id="text4090-8-7-8-7-6-3-8-4-1-5-6"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="25.247679"
+ y="1024.2014"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-2-8"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ </g>
+ <g
+ transform="translate(1.0962334,-2.7492248)"
+ id="g3275">
+ <g
+ id="g3341">
+ <text
+ x="394.78601"
+ y="390.17807"
+ id="text4090-8"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"><tspan
+ x="394.78601"
+ y="390.17807"
+ id="tspan4092-8"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Rebase to git </tspan></text>
+ <text
+ x="394.78601"
+ y="420.24835"
+ id="text4090-8-5"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="420.24835"
+ id="tspan4092-8-5"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Checkpatch </tspan></text>
+ <text
+ x="394.78601"
+ y="450.53394"
+ id="text4090-8-5-6"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="450.53394"
+ id="tspan4092-8-5-5"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ ABI breakage </tspan></text>
+ <text
+ x="394.78601"
+ y="513.13031"
+ id="text4090-8-5-6-9-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="513.13031"
+ id="tspan4092-8-5-5-3-4"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Maintainers file</tspan></text>
+ <text
+ x="394.78601"
+ y="573.48621"
+ id="text4090-8-5-6-9-4-6"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="573.48621"
+ id="tspan4092-8-5-5-3-4-0"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Release notes</tspan></text>
+ <text
+ x="395.79617"
+ y="603.98718"
+ id="text4090-8-5-6-9-4-6-6"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"><tspan
+ x="395.79617"
+ y="603.98718"
+ id="tspan4092-8-5-5-3-4-0-6"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Documentation</tspan></text>
+ <g
+ transform="translate(0,-0.83470152)"
+ id="g3334">
+ <g
+ id="g3267"
+ transform="translate(-11.153104,0.78827589)">
+ <text
+ x="628.93628"
+ y="473.13675"
+ id="text4090-8-1-8-9-1-4-1"
+ xml:space="preserve"
+ style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="628.93628"
+ y="473.13675"
+ id="tspan4092-8-7-6-9-7-0-7"
+ style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">**</tspan></text>
+ </g>
+ <text
+ x="394.78601"
+ y="483.59955"
+ id="text4090-8-5-6-9"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="483.59955"
+ id="tspan4092-8-5-5-3"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Update version.map</tspan></text>
+ </g>
+ <g
+ id="g3428"
+ transform="translate(0,0.88137813)">
+ <text
+ x="394.78601"
+ y="541.38928"
+ id="text4090-8-5-6-9-4-6-1"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="541.38928"
+ id="tspan4092-8-5-5-3-4-0-7"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Doxygen</tspan></text>
+ <g
+ transform="translate(-122.68876,60.70881)"
+ id="g3267-9">
+ <text
+ x="628.93628"
+ y="473.13675"
+ id="text4090-8-1-8-9-1-4-1-4"
+ xml:space="preserve"
+ style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="628.93628"
+ y="473.13675"
+ id="tspan4092-8-7-6-9-7-0-7-8"
+ style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">***</tspan></text>
+ </g>
+ </g>
+ </g>
+ </g>
+ <text
+ x="859.98138"
+ y="254.14594"
+ transform="matrix(0.70710678,0.70710678,-0.70710678,0.70710678,0,0)"
+ id="text4090-8-5-6-9-4-6-6-8-7-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"><tspan
+ x="859.98138"
+ y="254.14594"
+ id="tspan4092-8-5-5-3-4-0-6-2-11-0"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+</tspan></text>
+ <g
+ transform="translate(1.0962334,-2.7492248)"
+ id="g3595">
+ <text
+ x="30.942892"
+ y="1037.0271"
+ id="text4090-8-7-8-7-6-3-8-4-1-2"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="30.942892"
+ y="1037.0271"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="25.247679"
+ y="1037.0271"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-5"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="25.247679"
+ y="1037.0271"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-7"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="19.552465"
+ y="1037.0271"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-7"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="19.552465"
+ y="1037.0271"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-9"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="42.830166"
+ y="1033.2393"
+ id="text4090-8-7-8-7-6-3-8-4-8"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="42.830166"
+ y="1033.2393"
+ id="tspan4092-8-6-3-1-8-4-4-55-2"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">New header files must get a new page in the API docs.</tspan></text>
+ </g>
+ <g
+ transform="translate(1.0962334,-2.7492248)"
+ id="g3619">
+ <text
+ x="42.212418"
+ y="1046.0962"
+ id="text4090-8-7-8-7-6-3-8-2"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="42.212418"
+ y="1046.0962"
+ id="tspan4092-8-6-3-1-8-4-4-5"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">Available from patchwork, or email header. Reply to Cover letters.</tspan></text>
+ <text
+ x="31.140535"
+ y="1049.8527"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-2"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="31.140535"
+ y="1049.8527"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-3"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="25.445322"
+ y="1049.8527"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-5-2"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="25.445322"
+ y="1049.8527"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-7-2"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="19.750109"
+ y="1049.8527"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-7-1"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="19.750109"
+ y="1049.8527"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-9-6"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="14.016749"
+ y="1049.8527"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-7-1-8"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="14.016749"
+ y="1049.8527"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-9-6-5"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ </g>
+ <rect
+ width="196.44218"
+ height="45.785767"
+ rx="10.771052"
+ ry="10.771052"
+ x="531.44666"
+ y="998.50568"
+ id="rect3239-0-9-4-2-1-9-9-7"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ </g>
+</svg>
diff --git a/doc/guides/contributing/index.rst b/doc/guides/contributing/index.rst
index 561427b..8dadb20 100644
--- a/doc/guides/contributing/index.rst
+++ b/doc/guides/contributing/index.rst
@@ -9,3 +9,4 @@ Contributor's Guidelines
design
versioning
documentation
+ cheatsheet
--
1.9.1
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v2] doc: add patch submit cheatsheet
2015-12-09 16:23 1% [dpdk-dev] [PATCH] doc: add patch submit cheatsheet Harry van Haaren
@ 2015-12-09 17:27 1% ` Harry van Haaren
2015-12-14 10:03 1% ` [dpdk-dev] [PATCH v3] " Harry van Haaren
0 siblings, 1 reply; 200+ results
From: Harry van Haaren @ 2015-12-09 17:27 UTC (permalink / raw)
To: dev
This patch adds the patch submission cheatsheet to
the contributers guide. Both HTML and PDF docs show
the cheatsheet on its own page.
Right clicking the SVG image in the HTML doc allows
for viewing the image on its own, useful for printing
in high quality.
The exact appearance of of the cheatsheet will depend
on the default monospace font installed.
Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
---
v2: Fixed Fixes: line, added format-patch workflow instead
of using -N for setting the number of patches during send-email.
doc/guides/contributing/img/patch_cheatsheet.svg | 1484 ++++++++++++++++++++++
doc/guides/contributing/index.rst | 1 +
2 files changed, 1485 insertions(+)
create mode 100644 doc/guides/contributing/img/patch_cheatsheet.svg
diff --git a/doc/guides/contributing/img/patch_cheatsheet.svg b/doc/guides/contributing/img/patch_cheatsheet.svg
new file mode 100644
index 0000000..8522592
--- /dev/null
+++ b/doc/guides/contributing/img/patch_cheatsheet.svg
@@ -0,0 +1,1484 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ version="1.1"
+ width="210mm"
+ height="297mm"
+ id="svg2985"
+ inkscape:version="0.48.4 r9939"
+ sodipodi:docname="patch_cheatsheet.svg">
+ <sodipodi:namedview
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1"
+ objecttolerance="10"
+ gridtolerance="10"
+ guidetolerance="10"
+ inkscape:pageopacity="0"
+ inkscape:pageshadow="2"
+ inkscape:window-width="1184"
+ inkscape:window-height="1822"
+ id="namedview274"
+ showgrid="false"
+ inkscape:zoom="1.2685914"
+ inkscape:cx="289.93958"
+ inkscape:cy="509.84194"
+ inkscape:window-x="0"
+ inkscape:window-y="19"
+ inkscape:window-maximized="0"
+ inkscape:current-layer="g3272" />
+ <defs
+ id="defs3">
+ <linearGradient
+ x1="748.62079"
+ y1="-220.1862"
+ x2="849.99768"
+ y2="-220.1862"
+ id="SVGID_1_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop16"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop18"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop20"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop22"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="749.70099"
+ y1="-220.1864"
+ x2="848.91772"
+ y2="-220.1864"
+ id="SVGID_2_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop27"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop29"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop31"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop33"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="760.65948"
+ y1="-220.1864"
+ x2="899.29993"
+ y2="-220.1864"
+ id="SVGID_3_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop40"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop42"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop44"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop46"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="761.73969"
+ y1="-220.1864"
+ x2="898.21973"
+ y2="-220.1864"
+ id="SVGID_4_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop51"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop53"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop55"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop57"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="716.09821"
+ y1="-220.18649"
+ x2="874.64807"
+ y2="-220.18649"
+ id="SVGID_5_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop64"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop66"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop68"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop70"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="717.1781"
+ y1="-220.1864"
+ x2="873.56799"
+ y2="-220.1864"
+ id="SVGID_6_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop75"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop77"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop79"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop81"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ </defs>
+ <metadata
+ id="metadata4">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ <dc:title />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ id="layer1">
+ <switch
+ transform="matrix(0.46699142,0,0,0.41996015,9.9845875,-77.168919)"
+ id="switch3">
+ <g
+ id="g7">
+ <g
+ id="g9">
+ <g
+ id="g11">
+ <g
+ id="g13">
+ <linearGradient
+ x1="748.62079"
+ y1="-220.1862"
+ x2="849.99768"
+ y2="-220.1862"
+ id="linearGradient3172"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3174"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3176"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3178"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3180"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 137.8,342.7 c -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 l 43.3,-17.7 c 5,-1.9 8.9,-5.6 11.1,-10.4 2.2,-4.8 2.4,-10.2 0.5,-15.2 -2.9,-7.7 -10.4,-12.9 -18.6,-12.9 -2.4,0 -4.7,0.4 -7,1.3 l -63.2,22.3 c -0.8,0.3 -1.8,0.6 -2.7,0.6 -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 L 164,271.5 c 3.4,-1.3 6.8,-1.9 10.4,-1.9 12.3,0 23.4,7.7 27.7,19.2 2.8,7.4 2.5,15.4 -0.8,22.6 -3.3,7.2 -9.1,12.7 -16.5,15.5 L 140.5,342 c -0.7,0.3 -1.7,0.7 -2.7,0.7 z"
+ id="path24"
+ style="fill:url(#SVGID_1_)"
+ inkscape:connector-curvature="0" />
+ <linearGradient
+ x1="749.70099"
+ y1="-220.1864"
+ x2="848.91772"
+ y2="-220.1864"
+ id="linearGradient3183"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3185"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3187"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3189"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3191"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="M 184.5,325.9 140.2,341 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 l 43.3,-17.7 c 10.8,-4.1 16.3,-16.2 12.3,-27 -4.1,-10.8 -16.2,-16.3 -27,-12.3 l -63.2,22.2 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 l 62.2,-24.8 c 14.7,-5.5 31.2,2 36.7,16.7 5.5,14.8 -1.9,31.2 -16.6,36.8 z"
+ id="path35"
+ style="fill:url(#SVGID_2_)"
+ inkscape:connector-curvature="0" />
+ </g>
+ <g
+ id="g37">
+ <linearGradient
+ x1="760.65948"
+ y1="-220.1864"
+ x2="899.29993"
+ y2="-220.1864"
+ id="linearGradient3195"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3197"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3199"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3201"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3203"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 147.5,391.7 c -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 l 50.9,-20.6 c 35.7,-13.4 53.9,-53.4 40.5,-89.1 C 229.1,248 203.1,230 174.4,230 c -8.3,0 -16.4,1.5 -24.2,4.4 l -51.9,18 c -0.8,0.3 -1.8,0.6 -2.7,0.6 -1.4,0 -2.5,-0.8 -3,-2.2 -0.6,-1.6 0,-2.7 0.6,-3.4 0.7,-0.8 1.8,-1.2 2.8,-1.6 l 50.9,-20.6 c 8.9,-3.3 18.2,-5 27.7,-5 32.7,0 62.4,20.6 73.9,51.2 15.3,40.7 -5.4,86.3 -46.1,101.6 l -51.9,18 c -1,0.3 -2,0.7 -3,0.7 z"
+ id="path48"
+ style="fill:url(#SVGID_3_)"
+ inkscape:connector-curvature="0" />
+ <linearGradient
+ x1="761.73969"
+ y1="-220.1864"
+ x2="898.21973"
+ y2="-220.1864"
+ id="linearGradient3206"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3208"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3210"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3212"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3214"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 201.8,372 -51.9,18 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 l 50.9,-20.6 c 36.3,-13.6 54.7,-54.2 41.1,-90.5 -13.6,-36.3 -54.2,-54.7 -90.5,-41.1 l -51.9,18 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 L 147,226.2 c 40.2,-15.1 85.1,5.3 100.2,45.5 15.1,40.3 -5.3,85.3 -45.4,100.3 z"
+ id="path59"
+ style="fill:url(#SVGID_4_)"
+ inkscape:connector-curvature="0" />
+ </g>
+ <g
+ id="g61">
+ <linearGradient
+ x1="716.09821"
+ y1="-220.18649"
+ x2="874.64807"
+ y2="-220.18649"
+ id="linearGradient3218"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3220"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3222"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3224"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3226"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 97.1,384.3 c -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 L 190,340.9 c 23,-8.6 34.7,-34.4 26.1,-57.3 -6.5,-17.3 -23.3,-28.9 -41.7,-28.9 -5.3,0 -10.6,1 -15.6,2.8 l -83.9,30 c -0.8,0.3 -1.8,0.6 -2.7,0.6 -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 l 82.9,-32.6 c 6.1,-2.3 12.5,-3.5 19,-3.5 22.5,0 42.9,14.1 50.8,35.2 5.1,13.5 4.6,28.3 -1.4,41.5 -6,13.2 -16.8,23.3 -30.3,28.4 l -93.6,33.7 c -0.8,0.3 -1.8,0.7 -2.8,0.7 z"
+ id="path72"
+ style="fill:url(#SVGID_5_)"
+ inkscape:connector-curvature="0" />
+ <linearGradient
+ x1="717.1781"
+ y1="-220.1864"
+ x2="873.56799"
+ y2="-220.1864"
+ id="linearGradient3229"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3231"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3233"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3235"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3237"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 193.1,348.9 -93.6,33.7 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 l 92.7,-36.2 C 214,333.1 226,306.7 217.2,283.2 208.4,259.7 182,247.7 158.5,256.5 l -83.8,30 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.8,-1.9 0.7,-2.8 2.7,-3.6 l 82.9,-32.6 c 27.4,-10.3 58.1,3.6 68.4,31.1 10.2,27.5 -3.7,58.2 -31.2,68.4 z"
+ id="path83"
+ style="fill:url(#SVGID_6_)"
+ inkscape:connector-curvature="0" />
+ </g>
+ </g>
+ <g
+ id="g85">
+ <g
+ id="g87">
+ <path
+ d="m 300.7,235.7 h 33.5 c 30.7,0 51.8,19.4 51.8,47.5 0,28.1 -21.2,47.5 -51.8,47.5 h -33.5 v -95 z m 32.2,81.3 c 23.7,0 37.9,-13 37.9,-33.8 0,-20.8 -14.1,-33.8 -37.9,-33.8 H 315.7 V 317 h 17.2 z"
+ id="path89"
+ style="fill:#00233b"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 419.8,235.7 h 40.8 c 20.1,0 31.8,11.5 31.8,27.5 0,16.3 -11.7,28.2 -31.8,28.2 h -25.9 v 39.2 h -14.9 v -94.9 z m 39.7,42 c 11.1,0 17.9,-5.2 17.9,-14.2 0,-9.2 -6.8,-14.1 -17.9,-14.1 h -24.7 v 28.4 h 24.7 z"
+ id="path91"
+ style="fill:#00233b"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 523.2,235.7 h 33.5 c 30.7,0 51.8,19.4 51.8,47.5 0,28.1 -21.2,47.5 -51.8,47.5 h -33.5 v -95 z m 32.2,81.3 c 23.7,0 37.9,-13 37.9,-33.8 0,-20.8 -14.1,-33.8 -37.9,-33.8 H 538.2 V 317 h 17.2 z"
+ id="path93"
+ style="fill:#00233b"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 642.4,235.7 h 14.9 v 38.8 l 38.9,-38.8 h 19.1 l -44,43.4 51,51.6 h -20.4 l -44.8,-45.6 v 45.6 h -14.9 v -95 z"
+ id="path95"
+ style="fill:#00233b"
+ inkscape:connector-curvature="0" />
+ </g>
+ </g>
+ <g
+ id="g97">
+ <path
+ d="m 300.3,360 h 6.3 c 5.7,0 9.7,3.6 9.7,8.9 0,5.3 -4,8.9 -9.7,8.9 h -6.3 V 360 z m 6,15.2 c 4.4,0 7.1,-2.4 7.1,-6.3 0,-3.9 -2.6,-6.3 -7.1,-6.3 H 303 v 12.7 h 3.3 z"
+ id="path99"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 324.6,359.9 h 2.7 l 7.8,17.9 h -3 l -1.9,-4.4 h -8.4 l -1.9,4.4 h -3 l 7.7,-17.9 z m 4.6,11 -3.3,-7.5 -3.3,7.5 h 6.6 z"
+ id="path101"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 348.3,360 v 2.6 h -5.9 v 15.2 h -2.8 v -15.2 h -5.9 V 360 h 14.6 z"
+ id="path103"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 354.7,359.9 h 2.7 l 7.8,17.9 h -3 l -1.9,-4.4 h -8.4 l -1.9,4.4 h -3 l 7.7,-17.9 z m 4.6,11 -3.3,-7.5 -3.3,7.5 h 6.6 z"
+ id="path105"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 380.4,360 h 7.7 c 3.8,0 5.9,2.2 5.9,5.2 0,3.1 -2.2,5.3 -5.9,5.3 h -4.9 v 7.3 h -2.8 V 360 z m 7.4,7.8 c 2.1,0 3.4,-1 3.4,-2.7 0,-1.7 -1.3,-2.6 -3.4,-2.6 h -4.6 v 5.3 h 4.6 z"
+ id="path107"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 397,360 h 2.8 v 15.2 h 9.5 v 2.6 H 397 V 360 z"
+ id="path109"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 418.1,359.9 h 2.7 l 7.8,17.9 h -3 l -1.9,-4.4 h -8.4 l -1.9,4.4 h -3 l 7.7,-17.9 z m 4.6,11 -3.3,-7.5 -3.3,7.5 h 6.6 z"
+ id="path111"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 431.1,360 h 2.4 l 10,12.9 V 360 h 2.7 v 17.8 H 444 l -10.1,-12.9 v 12.9 h -2.7 V 360 z"
+ id="path113"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 450.5,360 h 12.7 v 2.6 h -9.9 v 4.4 h 8 v 2.6 h -8 v 5.6 h 10.2 v 2.6 h -13 V 360 z"
+ id="path115"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 479.3,360 h 6.3 c 5.7,0 9.7,3.6 9.7,8.9 0,5.3 -4,8.9 -9.7,8.9 h -6.3 V 360 z m 6,15.2 c 4.4,0 7.1,-2.4 7.1,-6.3 0,-3.9 -2.6,-6.3 -7.1,-6.3 h -3.2 v 12.7 h 3.2 z"
+ id="path117"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 498.8,360 h 12.7 v 2.6 h -9.9 v 4.4 h 8 v 2.6 h -8 v 5.6 h 10.2 v 2.6 h -13 V 360 z"
+ id="path119"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 513.3,360 h 3.1 l 5.9,14 5.9,-14 h 3 l -7.6,17.9 H 521 L 513.3,360 z"
+ id="path121"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 533.9,360 h 12.7 v 2.6 h -9.9 v 4.4 h 8 v 2.6 h -8 v 5.6 h 10.2 v 2.6 h -13 V 360 z"
+ id="path123"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 549.9,360 h 2.8 v 15.2 h 9.5 v 2.6 H 549.9 V 360 z"
+ id="path125"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 563,368.9 c 0,-5.2 3.8,-9.2 9.1,-9.2 5.3,0 9.1,4 9.1,9.2 0,5.2 -3.9,9.2 -9.1,9.2 -5.2,0 -9.1,-4.1 -9.1,-9.2 z m 15.3,0 c 0,-3.8 -2.7,-6.6 -6.2,-6.6 -3.5,0 -6.2,2.8 -6.2,6.6 0,3.8 2.7,6.6 6.2,6.6 3.5,0 6.2,-2.9 6.2,-6.6 z"
+ id="path127"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 584.7,360 h 7.7 c 3.8,0 5.9,2.2 5.9,5.2 0,3.1 -2.2,5.3 -5.9,5.3 h -4.9 v 7.3 h -2.8 V 360 z m 7.5,7.8 c 2.1,0 3.4,-1 3.4,-2.7 0,-1.7 -1.3,-2.6 -3.4,-2.6 h -4.6 v 5.3 h 4.6 z"
+ id="path129"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 601.3,360 h 2.8 l 5.8,8 5.7,-8 h 2.8 v 17.8 h -2.8 v -13.5 l -5,6.7 H 609 l -5,-6.7 v 13.5 h -2.8 V 360 z"
+ id="path131"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 622.6,360 h 12.7 v 2.6 h -9.9 v 4.4 h 8 v 2.6 h -8 v 5.6 h 10.2 v 2.6 h -13 V 360 z"
+ id="path133"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 638.7,360 h 2.4 l 10,12.9 V 360 h 2.7 v 17.8 h -2.4 l -10.1,-12.9 v 12.9 h -2.7 V 360 z"
+ id="path135"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 671.3,360 v 2.6 h -5.9 v 15.2 h -2.8 v -15.2 h -5.9 V 360 h 14.6 z"
+ id="path137"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 685.5,360 h 2.8 v 7.3 l 7.3,-7.3 h 3.6 l -8.2,8.1 9.6,9.7 h -3.8 l -8.4,-8.5 v 8.5 h -2.8 V 360 z"
+ id="path139"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 702.8,360 h 2.8 v 17.8 h -2.8 V 360 z"
+ id="path141"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 723.1,360 v 2.6 h -5.9 v 15.2 h -2.8 v -15.2 h -5.9 V 360 h 14.6 z"
+ id="path143"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ </g>
+ </g>
+ </g>
+ </switch>
+ <g
+ transform="matrix(0.89980358,0,0,0.89980358,45.57817,-2.8793563)"
+ id="g4009">
+ <text
+ x="325.02054"
+ y="107.5126"
+ id="text3212"
+ xml:space="preserve"
+ style="font-size:43.11383057px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"
+ transform="scale(1.193782,0.83767389)"><tspan
+ x="325.02054"
+ y="107.5126"
+ id="tspan3214">CHEATSHEET</tspan></text>
+ <text
+ x="386.51117"
+ y="58.178116"
+ transform="scale(1.0054999,0.99453018)"
+ id="text3212-1"
+ xml:space="preserve"
+ style="font-size:42.11373901px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="386.51117"
+ y="58.178116"
+ id="tspan3214-7">PATCH SUBMIT</tspan></text>
+ </g>
+ <rect
+ width="714.94495"
+ height="88.618027"
+ rx="20.780111"
+ ry="15.96909"
+ x="14.574773"
+ y="7.0045133"
+ id="rect3239"
+ style="fill:none;stroke:#00233b;stroke-width:0.87678075;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="713.28113"
+ height="887.29156"
+ rx="17.656931"
+ ry="17.280584"
+ x="15.406689"
+ y="104.73515"
+ id="rect3239-0"
+ style="fill:none;stroke:#00233b;stroke-width:1.00973284;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="694.94904"
+ height="381.31"
+ rx="9.4761629"
+ ry="9.0904856"
+ x="24.336016"
+ y="601.75836"
+ id="rect3239-0-9-4"
+ style="fill:none;stroke:#00233b;stroke-width:1.02322531;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <path
+ d="m 386.3921,327.23442 323.14298,0"
+ id="path4088"
+ style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ inkscape:connector-curvature="0" />
+ <text
+ x="396.18015"
+ y="314.45731"
+ id="text4090"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="396.18015"
+ y="314.45731"
+ id="tspan4092"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Patch Pre-Checks</tspan></text>
+ <text
+ x="43.44949"
+ y="147.32129"
+ id="text4090-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="43.44949"
+ y="147.32129"
+ id="tspan4092-3"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Commit Pre-Checks</tspan></text>
+ <text
+ x="397.1235"
+ y="144.8549"
+ id="text4090-4-3"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="397.1235"
+ y="144.8549"
+ id="tspan4092-3-3"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Bugfix?</tspan></text>
+ <text
+ x="41.215897"
+ y="634.38617"
+ id="text4090-1"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="41.215897"
+ y="634.38617"
+ id="tspan4092-38"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Git send-email </tspan></text>
+ <path
+ d="m 31.232443,642.80575 376.113467,0"
+ id="path4088-7"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ inkscape:connector-curvature="0" />
+ <rect
+ width="342.13785"
+ height="230.74609"
+ rx="10.411126"
+ ry="10.411126"
+ x="25.418407"
+ y="114.92036"
+ id="rect3239-0-9-4-2"
+ style="fill:none;stroke:#00233b;stroke-width:0.93674862;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <text
+ x="43.44949"
+ y="385.8045"
+ id="text4090-86"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="43.44949"
+ y="385.8045"
+ id="tspan4092-5"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Compile Pre-Checks</tspan></text>
+ <g
+ transform="translate(352.00486,-348.25973)"
+ id="g3295">
+ <text
+ x="43.87738"
+ y="568.03088"
+ id="text4090-8-14"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="43.87738"
+ y="568.03088"
+ id="tspan4289"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Include warning/error</tspan></text>
+ <text
+ x="43.87738"
+ y="537.71906"
+ id="text4090-8-14-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="43.87738"
+ y="537.71906"
+ id="tspan4289-1"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Fixes: line</tspan></text>
+ <text
+ x="43.87738"
+ y="598.9939"
+ id="text4090-8-14-0"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="43.87738"
+ y="598.9939"
+ id="tspan4289-2"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ How to reproduce</tspan></text>
+ </g>
+ <g
+ transform="translate(-2.6258125,-26.708615)"
+ id="g4115">
+ <g
+ id="g3272">
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1"
+ y="454.36987"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7"
+ y="454.36987"
+ x="49.093246">+ build gcc icc clang </tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2"
+ y="516.59979"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79"
+ y="516.59979"
+ x="49.093246">+ make test doc </tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2-0-0"
+ y="544.71033"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79-9-0"
+ y="544.71033"
+ x="49.093246">+ make examples</tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2-0-07"
+ y="576.83533"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79-9-3"
+ y="576.83533"
+ x="49.093246">+ make shared-lib</tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2-0-07-4"
+ y="604.88947"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79-9-3-9"
+ y="604.88947"
+ x="49.093246">+ library ABI version</tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2-9"
+ y="486.56659"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79-3"
+ y="486.56659"
+ x="49.093246">+ build 32 and 64 bits</tspan></text>
+ </g>
+ </g>
+ <text
+ x="74.388756"
+ y="914.65686"
+ id="text4090-8-1-8-65-9"
+ xml:space="preserve"
+ style="font-size:19px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace"
+ sodipodi:linespacing="125%"><tspan
+ sodipodi:role="line"
+ id="tspan3268"
+ x="74.388756"
+ y="914.65686">git send-email *.patch --annotate --to <maintainer></tspan><tspan
+ sodipodi:role="line"
+ id="tspan3272"
+ x="74.388756"
+ y="938.40686"> --cc dev@dpdk.org [ --cc other@participants.com</tspan><tspan
+ sodipodi:role="line"
+ x="74.388756"
+ y="962.15686"
+ id="tspan3266"> --cover-letter -v[N] --in-reply-to <message ID> ]</tspan></text>
+ <text
+ x="543.47675"
+ y="1032.3459"
+ id="text4090-8-7-8-7-6-3-8-2-5"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="543.47675"
+ y="1032.3459"
+ id="tspan4092-8-6-3-1-8-4-4-5-3"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">harry.van.haaren@intel.com</tspan></text>
+ <rect
+ width="678.14105"
+ height="87.351799"
+ rx="6.7972355"
+ ry="6.7972355"
+ x="31.865864"
+ y="888.44696"
+ id="rect3239-0-9-4-3"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <text
+ x="543.29498"
+ y="1018.1843"
+ id="text4090-8-7-8-7-6-3-8-2-5-3"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="543.29498"
+ y="1018.1843"
+ id="tspan4092-8-6-3-1-8-4-4-5-3-7"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Suggestions / Updates?</tspan></text>
+ <g
+ id="g3268"
+ transform="translate(0,-6)">
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1-8"
+ y="704.07019"
+ x="41.658669"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7-6"
+ y="704.07019"
+ x="41.658669">+ Patch version ( eg: -v2 ) </tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1-8-0"
+ y="736.29175"
+ x="41.658669"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7-6-2"
+ y="736.29175"
+ x="41.658669">+ Patch version annotations</tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1-8-6"
+ y="766.70355"
+ x="41.911205"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7-6-1"
+ y="766.70355"
+ x="41.911205">+ Send --to maintainer </tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1-8-6-3"
+ y="795.30548"
+ x="41.658669"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7-6-1-8"
+ y="795.30548"
+ x="41.658669">+ Send --cc dev@dpdk.org </tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1-8-9"
+ y="675.25287"
+ x="41.658669"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7-6-9"
+ y="675.25287"
+ x="41.658669">+ Cover letter</tspan></text>
+ <g
+ id="g3303"
+ transform="translate(1.0962334,-40.034939)">
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1-8-65"
+ y="868.70337"
+ x="41.572586"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7-6-10"
+ y="868.70337"
+ x="41.572586">+ Send --in-reply-to <message ID><tspan
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan3184" /></tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1-8-9-1"
+ y="855.79816"
+ x="460.18405"><tspan
+ style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7-6-9-7"
+ y="855.79816"
+ x="460.18405">****</tspan></text>
+ </g>
+ </g>
+ <text
+ x="685.67828"
+ y="76.55056"
+ id="text4090-8-1-8-9-1-9"
+ xml:space="preserve"
+ style="font-size:20.20989037px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="685.67828"
+ y="76.55056"
+ id="tspan4092-8-7-6-9-7-4"
+ style="font-size:9.09445095px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">v1.0</tspan></text>
+ <rect
+ width="342.3053"
+ height="155.54948"
+ rx="9.2344503"
+ ry="9.2344503"
+ x="377.58942"
+ y="114.55766"
+ id="rect3239-0-9-4-2-1"
+ style="fill:none;stroke:#00233b;stroke-width:0.76930124;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="342.12564"
+ height="236.79482"
+ rx="10.647112"
+ ry="9.584527"
+ x="25.642178"
+ y="356.86249"
+ id="rect3239-0-9-4-2-0"
+ style="fill:none;stroke:#00233b;stroke-width:0.9489302;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="341.98428"
+ height="312.73181"
+ rx="8.5358429"
+ ry="8.5358429"
+ x="377.96762"
+ y="280.45331"
+ id="rect3239-0-9-4-2-1-9"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <path
+ d="m 387.02742,157.3408 323.14298,0"
+ id="path4088-8"
+ style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 36.504486,397.33869 323.142974,0"
+ id="path4088-82"
+ style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 35.494337,156.92238 323.142983,0"
+ id="path4088-4"
+ style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ inkscape:connector-curvature="0" />
+ <g
+ transform="translate(1.0962334,-30.749225)"
+ id="g3363">
+ <text
+ x="45.371201"
+ y="214.1572"
+ id="text4090-8-11"
+ xml:space="preserve"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="214.1572"
+ id="tspan4092-8-52"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Signed-off-by: </tspan></text>
+ <text
+ x="45.371201"
+ y="243.81795"
+ id="text4090-8-7-8"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="243.81795"
+ id="tspan4092-8-6-3"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Suggested-by:</tspan></text>
+ <text
+ x="45.371201"
+ y="273.90939"
+ id="text4090-8-7-8-7"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="273.90939"
+ id="tspan4092-8-6-3-1"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Reported-by:</tspan></text>
+ <text
+ x="45.371201"
+ y="304.00082"
+ id="text4090-8-7-8-7-6"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="304.00082"
+ id="tspan4092-8-6-3-1-8"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Tested-by:</tspan></text>
+ <g
+ id="g3297"
+ transform="translate(1.1147904,-7.2461378)">
+ <text
+ x="45.371201"
+ y="368.8187"
+ id="text4090-8-7-8-7-6-3"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="368.8187"
+ id="tspan4092-8-6-3-1-8-4"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Previous Acks</tspan></text>
+ <text
+ x="235.24362"
+ y="360.3028"
+ id="text4090-8-1-8-9-1-4"
+ xml:space="preserve"
+ style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="235.24362"
+ y="360.3028"
+ id="tspan4092-8-7-6-9-7-0"
+ style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ </g>
+ <text
+ x="45.371201"
+ y="334.52298"
+ id="text4090-8-7-8-7-6-3-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="334.52298"
+ id="tspan4092-8-6-3-1-8-4-0"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Commit message</tspan></text>
+ </g>
+ <rect
+ width="295.87207"
+ height="164.50136"
+ rx="7.3848925"
+ ry="4.489974"
+ x="414.80502"
+ y="611.47064"
+ id="rect3239-0-9-4-2-1-9-9"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <text
+ x="439.4429"
+ y="638.35608"
+ id="text4090-1-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="439.4429"
+ y="638.35608"
+ id="tspan4092-38-8"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Mailing List</tspan></text>
+ <text
+ x="431.55353"
+ y="675.59857"
+ id="text4090-8-5-6-9-4-6-6-8"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="431.55353"
+ y="675.59857"
+ id="tspan4092-8-5-5-3-4-0-6-2"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Acked-by:</tspan></text>
+ <text
+ x="431.39734"
+ y="734.18231"
+ id="text4090-8-5-6-9-4-6-6-8-5"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="431.39734"
+ y="734.18231"
+ id="tspan4092-8-5-5-3-4-0-6-2-1"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Reviewed-by:</tspan></text>
+ <text
+ x="450.8428"
+ y="766.5578"
+ id="text4090-8-5-6-9-4-6-6-8-7"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="450.8428"
+ y="766.5578"
+ id="tspan4092-8-5-5-3-4-0-6-2-11"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Nack (refuse patch)</tspan></text>
+ <path
+ d="m 426.99385,647.80575 272.72607,0"
+ id="path4088-7-5"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 424.7332,742.35699 272.72607,0"
+ id="path4088-7-5-2"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ inkscape:connector-curvature="0" />
+ <text
+ x="431.39734"
+ y="704.78278"
+ id="text4090-8-5-6-9-4-6-6-8-5-1"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="431.39734"
+ y="704.78278"
+ id="tspan4092-8-5-5-3-4-0-6-2-1-7"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Tested-by:</tspan></text>
+ <g
+ transform="translate(1.0962334,-2.7492248)"
+ id="g3613">
+ <text
+ x="43.146141"
+ y="1007.5879"
+ id="text4090-8-7-8-7-6-3-8"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="43.146141"
+ y="1007.5879"
+ id="tspan4092-8-6-3-1-8-4-4"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">Previous Acks only when fixing typos, rebased, or checkpatch issues.</tspan></text>
+ <text
+ x="30.942892"
+ y="1011.3757"
+ id="text4090-8-7-8-7-6-3-8-4-1"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="30.942892"
+ y="1011.3757"
+ id="tspan4092-8-6-3-1-8-4-4-55-7"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ </g>
+ <g
+ transform="translate(1.0962334,-2.7492248)"
+ id="g3605">
+ <text
+ x="42.176418"
+ y="1020.4383"
+ id="text4090-8-7-8-7-6-3-8-4"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="42.176418"
+ y="1020.4383"
+ id="tspan4092-8-6-3-1-8-4-4-55"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">The version.map function names must be in alphabetical order.</tspan></text>
+ <text
+ x="30.942892"
+ y="1024.2014"
+ id="text4090-8-7-8-7-6-3-8-4-1-5"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="30.942892"
+ y="1024.2014"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-2"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="25.247679"
+ y="1024.2014"
+ id="text4090-8-7-8-7-6-3-8-4-1-5-6"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="25.247679"
+ y="1024.2014"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-2-8"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ </g>
+ <g
+ transform="translate(1.0962334,-30.749225)"
+ id="g3275">
+ <g
+ id="g3341">
+ <text
+ x="394.78601"
+ y="390.17807"
+ id="text4090-8"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="390.17807"
+ id="tspan4092-8"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Rebase to git </tspan></text>
+ <text
+ x="394.78601"
+ y="420.24835"
+ id="text4090-8-5"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="420.24835"
+ id="tspan4092-8-5"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Checkpatch </tspan></text>
+ <text
+ x="394.78601"
+ y="450.53394"
+ id="text4090-8-5-6"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="450.53394"
+ id="tspan4092-8-5-5"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ ABI breakage </tspan></text>
+ <text
+ x="394.78601"
+ y="513.13031"
+ id="text4090-8-5-6-9-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="513.13031"
+ id="tspan4092-8-5-5-3-4"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Maintainers file</tspan></text>
+ <text
+ x="394.78601"
+ y="573.48621"
+ id="text4090-8-5-6-9-4-6"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="573.48621"
+ id="tspan4092-8-5-5-3-4-0"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Release notes</tspan></text>
+ <text
+ x="395.79617"
+ y="603.98718"
+ id="text4090-8-5-6-9-4-6-6"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="395.79617"
+ y="603.98718"
+ id="tspan4092-8-5-5-3-4-0-6"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Documentation</tspan></text>
+ <g
+ transform="translate(0,-0.83470152)"
+ id="g3334">
+ <g
+ id="g3267"
+ transform="translate(-13.517932,3.1531035)">
+ <text
+ x="660.46729"
+ y="468.01297"
+ id="text4090-8-1-8-9-1-4-1"
+ xml:space="preserve"
+ style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="660.46729"
+ y="468.01297"
+ id="tspan4092-8-7-6-9-7-0-7"
+ style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">**</tspan></text>
+ </g>
+ <text
+ x="394.78601"
+ y="483.59955"
+ id="text4090-8-5-6-9"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="483.59955"
+ id="tspan4092-8-5-5-3"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Update version.map</tspan></text>
+ </g>
+ <g
+ id="g3428"
+ transform="translate(0,0.88137813)">
+ <text
+ x="394.78601"
+ y="541.38928"
+ id="text4090-8-5-6-9-4-6-1"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="541.38928"
+ id="tspan4092-8-5-5-3-4-0-7"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Doxygen</tspan></text>
+ <g
+ transform="translate(-119.92979,57.949844)"
+ id="g3267-9">
+ <text
+ x="628.93628"
+ y="473.13675"
+ id="text4090-8-1-8-9-1-4-1-4"
+ xml:space="preserve"
+ style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="628.93628"
+ y="473.13675"
+ id="tspan4092-8-7-6-9-7-0-7-8"
+ style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">***</tspan></text>
+ </g>
+ </g>
+ </g>
+ </g>
+ <text
+ x="840.1828"
+ y="234.34692"
+ transform="matrix(0.70710678,0.70710678,-0.70710678,0.70710678,0,0)"
+ id="text4090-8-5-6-9-4-6-6-8-7-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="840.1828"
+ y="234.34692"
+ id="tspan4092-8-5-5-3-4-0-6-2-11-0"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+</tspan></text>
+ <g
+ transform="translate(1.0962334,-2.7492248)"
+ id="g3595">
+ <text
+ x="30.942892"
+ y="1037.0271"
+ id="text4090-8-7-8-7-6-3-8-4-1-2"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="30.942892"
+ y="1037.0271"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="25.247679"
+ y="1037.0271"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-5"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="25.247679"
+ y="1037.0271"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-7"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="19.552465"
+ y="1037.0271"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-7"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="19.552465"
+ y="1037.0271"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-9"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="42.830166"
+ y="1033.2393"
+ id="text4090-8-7-8-7-6-3-8-4-8"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="42.830166"
+ y="1033.2393"
+ id="tspan4092-8-6-3-1-8-4-4-55-2"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">New header files must get a new page in the API docs.</tspan></text>
+ </g>
+ <g
+ transform="translate(1.0962334,-2.7492248)"
+ id="g3619">
+ <text
+ x="42.212418"
+ y="1046.0962"
+ id="text4090-8-7-8-7-6-3-8-2"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="42.212418"
+ y="1046.0962"
+ id="tspan4092-8-6-3-1-8-4-4-5"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">Available from patchwork, or email header. Reply to Cover letters.</tspan></text>
+ <text
+ x="31.140535"
+ y="1049.8527"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-2"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="31.140535"
+ y="1049.8527"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-3"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="25.445322"
+ y="1049.8527"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-5-2"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="25.445322"
+ y="1049.8527"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-7-2"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="19.750109"
+ y="1049.8527"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-7-1"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="19.750109"
+ y="1049.8527"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-9-6"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="14.016749"
+ y="1049.8527"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-7-1-8"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="14.016749"
+ y="1049.8527"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-9-6-5"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ </g>
+ <rect
+ width="196.44218"
+ height="45.785767"
+ rx="10.771052"
+ ry="10.771052"
+ x="531.44666"
+ y="998.50568"
+ id="rect3239-0-9-4-2-1-9-9-7"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="678.43036"
+ height="43.497677"
+ rx="7.8557949"
+ ry="6.7630997"
+ x="31.274473"
+ y="836.69745"
+ id="rect3239-0-9-4-3-6"
+ style="fill:none;stroke:#00233b;stroke-width:0.92794865;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <text
+ x="73.804535"
+ y="864.28137"
+ id="text4090-8-1-8-65-9-1"
+ xml:space="preserve"
+ style="font-size:19px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace"
+ sodipodi:linespacing="125%"><tspan
+ sodipodi:role="line"
+ x="73.804535"
+ y="864.28137"
+ id="tspan3266-8">git format-patch -[N]</tspan></text>
+ <text
+ x="342.70221"
+ y="862.83478"
+ id="text4090-8-1-8-65-9-1-7"
+ xml:space="preserve"
+ style="font-size:19px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace"
+ sodipodi:linespacing="125%"><tspan
+ sodipodi:role="line"
+ x="342.70221"
+ y="862.83478"
+ id="tspan3266-8-2"
+ style="font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">// creates .patch files for final review</tspan></text>
+ </g>
+</svg>
diff --git a/doc/guides/contributing/index.rst b/doc/guides/contributing/index.rst
index 561427b..8dadb20 100644
--- a/doc/guides/contributing/index.rst
+++ b/doc/guides/contributing/index.rst
@@ -9,3 +9,4 @@ Contributor's Guidelines
design
versioning
documentation
+ cheatsheet
--
1.9.1
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [RFC 0/3] ethdev: Enhancements to flow director filter
@ 2015-12-10 14:01 4% Rahul Lakkireddy
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Rahul Lakkireddy @ 2015-12-10 14:01 UTC (permalink / raw)
To: dev; +Cc: Felix Marti, Kumar Sanghvi, Nirranjan Kirubaharan
This RFC series of patches attempt to extend the flow director filter to
add support for Chelsio T5 hardware filtering capabilities.
Chelsio T5 supports carrying out filtering in hardware which supports 3
actions to carry out on a packet which hit a filter viz.
1. Action Pass - Packets hitting a filter rule can be directed to a
particular RXQ.
2. Action Drop - Packets hitting a filter rule are dropped in h/w.
3. Action Switch - Packets hitting a filter rule can be switched in h/w
from one port to another, without involvement of host. Also, the
action Switch also supports rewrite of src-mac/dst-mac headers as
well as rewrite of vlan headers. It also supports rewrite of IP
headers and thereby, supports NAT (Network Address Translation)
in h/w.
Also, each filter rule can optionally support specifying a mask value
i.e. it's possible to create a filter rule for an entire subnet of IP
addresses or a range of tcp/udp ports, etc.
Patch 1 does the following:
- Adds an additional flow rte_eth_pkt_filter_flow which encapsulates
ingress ports, l2 payload, vlan and ntuples.
- Adds an additional mask for the flow to allow range of values to be
matched.
- Adds a new behavior 'switch'.
- Adds behavior arguments that can be passed when a particular behavior
is taken. For ex: in case of action 'switch', pass additional 4-tuple
to allow rewriting src/dst ip and port addresses to support NAT'ing.
Patch 2 shows testpmd command line example to support packet filter
flow.
Patch 3 announces ABI change for filtering support.
The patch series has been compile tested on all x86 gcc targets and the
current fdir filter supported drivers seem to return appropriate error
codes when this new flow type and the new action are not supported and
hence are not affected.
Posting this series mainly for discussion on API change. Once this is
agreeable then, I will post the cxgbe PMD changes to use the new API.
Rahul Lakkireddy (3):
ethdev: add packet filter flow and new behavior switch to fdir
testpmd: add an example to show packet filter flow
doc: announce ABI change for filtering support
app/test-pmd/cmdline.c | 435 ++++++++++++++++++++++++++++++++++-
doc/guides/rel_notes/deprecation.rst | 6 +
lib/librte_ether/rte_eth_ctrl.h | 112 ++++++++-
3 files changed, 544 insertions(+), 9 deletions(-)
--
2.5.3
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support
2015-12-10 14:01 4% [dpdk-dev] [RFC 0/3] ethdev: Enhancements to flow director filter Rahul Lakkireddy
@ 2015-12-10 14:01 4% ` Rahul Lakkireddy
2015-12-15 8:40 7% ` Rahul Lakkireddy
2015-12-23 12:41 3% ` [dpdk-dev] [RFC v2 0/2] ethdev: Enhancements to flow director filter Rahul Lakkireddy
2 siblings, 1 reply; 200+ results
From: Rahul Lakkireddy @ 2015-12-10 14:01 UTC (permalink / raw)
To: dev; +Cc: Felix Marti, Kumar Sanghvi, Nirranjan Kirubaharan
Current filtering support will be enhanced to accommodate support
for Chelsio T5 hardware filtering support.
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
---
doc/guides/rel_notes/deprecation.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1c7ab01..ca43b16 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -19,3 +19,9 @@ Deprecation Notices
and table action handlers will be updated:
the pipeline parameter will be added, the packets mask parameter will be
either removed (for input port action handler) or made input-only.
+
+* The filtering support will be changed to add a new packet filter
+ flow, add a new behavior 'switch', add an ability to add mask
+ for fields in each filter rule, and add an ability to pass extra
+ arguments for the behavior taken to allow rewriting matched fields
+ in filter rule.
--
2.5.3
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [RFC 1/3] ethdev: add packet filter flow and new behavior switch to fdir
@ 2015-12-10 15:46 3% ` Chilikin, Andrey
2015-12-11 7:08 0% ` Rahul Lakkireddy
0 siblings, 1 reply; 200+ results
From: Chilikin, Andrey @ 2015-12-10 15:46 UTC (permalink / raw)
To: Rahul Lakkireddy, dev; +Cc: Kumar Sanghvi, Felix Marti, Nirranjan Kirubaharan
Hi Rahul,
If ABI for fdir is going to be changed should we then take more general approach to accommodate other NICs as well? For example, for "rte_eth_ipv4_flow" you have "tos" and "proto" fields added, but "ttl" was left out of scope. I believe that "rte_eth_udpv6_flow" should be compatible with new IPv4 structure, so "flow label", "tc", "next header" and "hop limit" to be added as well as other NICs might have support for fdir rules for all these fields.
Regards,
Andrey
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Rahul Lakkireddy
> Sent: Thursday, December 10, 2015 2:01 PM
> To: dev@dpdk.org
> Cc: Felix Marti; Kumar Sanghvi; Nirranjan Kirubaharan
> Subject: [dpdk-dev] [RFC 1/3] ethdev: add packet filter flow and new behavior
> switch to fdir
>
> Add a new packet filter flow that allows filtering a packet based on matching
> ingress port, ethertype, vlan, ip, and tcp/udp fields, i.e.
> matching based on any or all fields at the same time.
>
> Add the ability to provide masks for fields in flow to allow range of values.
>
> Add a new vlan flow containing inner and outer vlan to match. Add tos and
> proto fields that can be matched for ipv4_flow.
>
> Add a new behavior switch.
>
> Add the ability to provide behavior arguments to allow insert/deletion of
> matched fields in the flow. Useful when rewriting matched fields with new
> values. Adds arguments for port, mac, vlan, and nat.
> Ex: allows to provide new ip and port addresses to rewrite the fields of packets
> matching a filter rule before NAT'ing.
>
> Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
> Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
> ---
> lib/librte_ether/rte_eth_ctrl.h | 112
> +++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 111 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
> index ce224ad..a2e770c 100644
> --- a/lib/librte_ether/rte_eth_ctrl.h
> +++ b/lib/librte_ether/rte_eth_ctrl.h
> @@ -74,7 +74,11 @@ extern "C" {
> #define RTE_ETH_FLOW_IPV6_EX 15
> #define RTE_ETH_FLOW_IPV6_TCP_EX 16
> #define RTE_ETH_FLOW_IPV6_UDP_EX 17
> -#define RTE_ETH_FLOW_MAX 18
> +#define RTE_ETH_FLOW_PKT_FILTER_IPV4_TCP 18 #define
> +RTE_ETH_FLOW_PKT_FILTER_IPV4_UDP 19 #define
> +RTE_ETH_FLOW_PKT_FILTER_IPV6_TCP 20 #define
> +RTE_ETH_FLOW_PKT_FILTER_IPV6_UDP 21
> +#define RTE_ETH_FLOW_MAX 22
>
> /**
> * Feature filter types
> @@ -407,6 +411,8 @@ struct rte_eth_l2_flow { struct rte_eth_ipv4_flow {
> uint32_t src_ip; /**< IPv4 source address to match. */
> uint32_t dst_ip; /**< IPv4 destination address to match. */
> + uint8_t tos; /**< IPV4 type of service to match. */
> + uint8_t proto; /**< IPV4 proto to match. */
> };
>
> /**
> @@ -500,6 +506,43 @@ struct rte_eth_tunnel_flow { };
>
> /**
> + * A structure used to define the input for vlan flow.
> + */
> +struct rte_eth_vlan_flow {
> + uint16_t inner_vlan; /**< Inner vlan field to match. */
> + uint16_t outer_vlan; /**< Outer vlan field to match. */ };
> +
> +/**
> + * A union used to define the input for N-Tuple flow */ union
> +rte_eth_ntuple_flow {
> + struct rte_eth_tcpv4_flow tcp4;
> + struct rte_eth_udpv4_flow udp4;
> + struct rte_eth_tcpv6_flow tcp6;
> + struct rte_eth_udpv6_flow udp6;
> +};
> +
> +/**
> + * A structure used to define the input for packet filter.
> + */
> +struct rte_eth_pkt_filter {
> + uint8_t port_id; /**< Port id to match. */
> + struct rte_eth_l2_flow l2_flow; /**< L2 flow fields to match. */
> + struct rte_eth_vlan_flow vlan_flow; /**< Vlan flow fields to match. */
> + union rte_eth_ntuple_flow ntuple_flow;
> + /**< N-tuple flow fields to match. */
> +};
> +
> +/**
> + * A structure used to define the input for packet filter flow.
> + */
> +struct rte_eth_pkt_filter_flow {
> + struct rte_eth_pkt_filter pkt; /**< Packet fields to match. */
> + struct rte_eth_pkt_filter mask; /**< Mask for matched fields. */
> +};
> +
> +/**
> * An union contains the inputs for all types of flow
> */
> union rte_eth_fdir_flow {
> @@ -514,6 +557,7 @@ union rte_eth_fdir_flow {
> struct rte_eth_ipv6_flow ipv6_flow;
> struct rte_eth_mac_vlan_flow mac_vlan_flow;
> struct rte_eth_tunnel_flow tunnel_flow;
> + struct rte_eth_pkt_filter_flow pkt_filter_flow;
> };
>
> /**
> @@ -545,6 +589,7 @@ enum rte_eth_fdir_behavior {
> RTE_ETH_FDIR_ACCEPT = 0,
> RTE_ETH_FDIR_REJECT,
> RTE_ETH_FDIR_PASSTHRU,
> + RTE_ETH_FDIR_SWITCH,
> };
>
> /**
> @@ -559,6 +604,69 @@ enum rte_eth_fdir_status { };
>
> /**
> + * Behavior sub operations on fields in matched flows.
> + */
> +enum rte_eth_fdir_behavior_sub_op {
> + RTE_FDIR_BEHAVIOR_SUB_OP_UNKNOWN = 0,
> + RTE_FDIR_BEHAVIOR_SUB_OP_INSERT,
> + /**< Add/rewrite fields in matched flows */
> + RTE_FDIR_BEHAVIOR_SUB_OP_DELETE,
> + /**< Delete/reset fields in matched flows */ };
> +
> +/**
> + * A structure used to define the input for passing port arguments for
> + * behavior taken.
> + */
> +struct rte_eth_behavior_arg_port {
> + enum rte_eth_fdir_behavior_sub_op op; /**< Sub operation to do */
> + uint8_t port_id; /**< Physical port to redirect */
> +};
> +
> +/**
> + * A structure used to define the input for passing mac arguments for
> + * behavior taken.
> + */
> +struct rte_eth_behavior_arg_mac {
> + enum rte_eth_fdir_behavior_sub_op op; /**< Sub operation to do */
> + struct ether_addr src_mac; /**< SRC Ethernet Address to rewirte. */
> + struct ether_addr dst_mac; /**< DST Ethernet Address to rewrite. */
> +};
> +
> +/**
> + * A structure used to define the input for passing vlan arguments for
> + * behavior taken.
> + */
> +struct rte_eth_behavior_arg_vlan {
> + enum rte_eth_fdir_behavior_sub_op op; /**< Sub operation to do */
> + uint16_t vlan_tci; /**< New vlan fields to rewrite matched ones */ };
> +
> +/**
> + * A structure used to define the input for passing Network Address
> + * Translation (NAT) arguments for behavior taken.
> + */
> +struct rte_eth_behavior_arg_nat {
> + enum rte_eth_fdir_behavior_sub_op op; /**< Sub operation to do */
> + union rte_eth_ntuple_flow nat;
> + /**< New NAT fields to rewrite matched ones */ };
> +
> +/**
> + * Extra arguments to pass for a behavior taken.
> + */
> +struct rte_eth_fdir_behavior_arg {
> + struct rte_eth_behavior_arg_port port_arg;
> + /**< Extra port arg to pass */
> + struct rte_eth_behavior_arg_mac mac_arg;
> + /**< Extra mac arg to pass */
> + struct rte_eth_behavior_arg_vlan vlan_arg;
> + /**< Extra vlan arg to pass */
> + struct rte_eth_behavior_arg_nat nat_arg;
> + /**< Extra NAT arg to pass */
> +};
> +
> +/**
> * A structure used to define an action when match FDIR packet filter.
> */
> struct rte_eth_fdir_action {
> @@ -569,6 +677,8 @@ struct rte_eth_fdir_action {
> /**< If report_status is RTE_ETH_FDIR_REPORT_ID_FLEX_4 or
> RTE_ETH_FDIR_REPORT_FLEX_8, flex_off specifies where the
> reported
> flex bytes start from in flexible payload. */
> + struct rte_eth_fdir_behavior_arg behavior_arg;
> + /**< Extra arguments for behavior taken */
> };
>
> /**
> --
> 2.5.3
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] doc: announce API change for rte_ether.h
@ 2015-12-10 23:27 5% Stephen Hemminger
2015-12-11 9:28 0% ` Panu Matilainen
2015-12-14 14:54 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2015-12-10 23:27 UTC (permalink / raw)
To: dev
Plan to change to <net/ethernet.h> version of struct ether_addr in
DPDK 2.3. The change in DPDK source is trivial but it will impact
source compatablilty therefore notification is necessary.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/deprecation.rst | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1c7ab01..8ecb990 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -19,3 +19,8 @@ Deprecation Notices
and table action handlers will be updated:
the pipeline parameter will be added, the packets mask parameter will be
either removed (for input port action handler) or made input-only.
+
+* librte_ether: The structure ether_addr in DPDK will be replaced
+ by using the standard header file <net/ethernet.h>. The structure
+ size will be the same (no ABI impact), but the structure field name
+ will change from addr_bytes[] to ether_addr_octet[].
--
2.1.4
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v2] doc: announce ABI change for struct rte_eth_conf
@ 2015-12-11 2:55 16% Jijiang Liu
0 siblings, 0 replies; 200+ results
From: Jijiang Liu @ 2015-12-11 2:55 UTC (permalink / raw)
To: dev
In current codes, tunnel configuration information is not stored in a device configuration, and it will get nothing if application want to retrieve tunnel config, so I think it is necessary
to add rte_eth_dev_tunnel_configure() function is to do the configurations including flow and classification information and store it in a device configuration.
And tunneling packet encapsulation operation will benifit from the change.
v2 change:
Add more description for the change.
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 5c458f2..df10249 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -23,3 +23,8 @@ Deprecation Notices
* ABI changes are planned for struct rte_eth_tunnel_flow in order to extend new fileds to support
tunneling packet configuration in unified tunneling APIs. The release 2.2 does not contain these ABI
changes, but release 2.3 will, and no backwards compatibility is planned.
+
+* ABI changes are planned for struct rte_eth_conf in order to support tunnel configuration using unified tunneling APIs,
+ which is the rte_eth_dev_tunnel_configure(uint8_t port_id, rte_eth_tunnel_conf * tunnel_conf)
+ API is planned to add. And the 'tunnel_conf' shloud be stored in global 'rte_eth_conf'.
+ The release 2.2 does not contain these ABI change, but release 2.3 will, and no backwards compatibility is planned.
--
1.7.7.6
^ permalink raw reply [relevance 16%]
* Re: [dpdk-dev] [RFC 1/3] ethdev: add packet filter flow and new behavior switch to fdir
2015-12-10 15:46 3% ` Chilikin, Andrey
@ 2015-12-11 7:08 0% ` Rahul Lakkireddy
0 siblings, 0 replies; 200+ results
From: Rahul Lakkireddy @ 2015-12-11 7:08 UTC (permalink / raw)
To: Chilikin, Andrey; +Cc: dev, Felix Marti, Nirranjan Kirubaharan, Kumar A S
Hi Andrey,
On Thursday, December 12/10/15, 2015 at 07:46:42 -0800, Chilikin, Andrey wrote:
> Hi Rahul,
>
> If ABI for fdir is going to be changed should we then take more general approach to accommodate other NICs as well? For example, for "rte_eth_ipv4_flow" you have "tos" and "proto" fields added, but "ttl" was left out of scope. I believe that "rte_eth_udpv6_flow" should be compatible with new IPv4 structure, so "flow label", "tc", "next header" and "hop limit" to be added as well as other NICs might have support for fdir rules for all these fields.
>
I agree.
I'll wait for some more review comments if there are any and then post a
v2 RFC series with above changes.
Thanks,
Rahul
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce API change for rte_ether.h
2015-12-10 23:27 5% [dpdk-dev] [PATCH] doc: announce API change for rte_ether.h Stephen Hemminger
@ 2015-12-11 9:28 0% ` Panu Matilainen
2015-12-11 16:33 0% ` Stephen Hemminger
2015-12-14 14:54 0% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-11 9:28 UTC (permalink / raw)
To: Stephen Hemminger, dev
On 12/11/2015 01:27 AM, Stephen Hemminger wrote:
> Plan to change to <net/ethernet.h> version of struct ether_addr in
> DPDK 2.3. The change in DPDK source is trivial but it will impact
> source compatablilty therefore notification is necessary.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> doc/guides/rel_notes/deprecation.rst | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 1c7ab01..8ecb990 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -19,3 +19,8 @@ Deprecation Notices
> and table action handlers will be updated:
> the pipeline parameter will be added, the packets mask parameter will be
> either removed (for input port action handler) or made input-only.
> +
> +* librte_ether: The structure ether_addr in DPDK will be replaced
> + by using the standard header file <net/ethernet.h>. The structure
> + size will be the same (no ABI impact), but the structure field name
> + will change from addr_bytes[] to ether_addr_octet[].
>
I hope there is some other reason/benefit besides getting rid of a
three-line custom struct definition. It may be a trivial
s/addr_bytes/ether_addr_octet/ change but it touches a lot of places all
over the DPDK codebase alone, and for 3rd party developers such (at
least seemingly) gratuitous renames are really irritating.
- Panu -
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce API change for rte_ether.h
2015-12-11 9:28 0% ` Panu Matilainen
@ 2015-12-11 16:33 0% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2015-12-11 16:33 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
On Fri, 11 Dec 2015 11:28:48 +0200
Panu Matilainen <pmatilai@redhat.com> wrote:
> On 12/11/2015 01:27 AM, Stephen Hemminger wrote:
> > Plan to change to <net/ethernet.h> version of struct ether_addr in
> > DPDK 2.3. The change in DPDK source is trivial but it will impact
> > source compatablilty therefore notification is necessary.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > ---
> > doc/guides/rel_notes/deprecation.rst | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> > index 1c7ab01..8ecb990 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -19,3 +19,8 @@ Deprecation Notices
> > and table action handlers will be updated:
> > the pipeline parameter will be added, the packets mask parameter will be
> > either removed (for input port action handler) or made input-only.
> > +
> > +* librte_ether: The structure ether_addr in DPDK will be replaced
> > + by using the standard header file <net/ethernet.h>. The structure
> > + size will be the same (no ABI impact), but the structure field name
> > + will change from addr_bytes[] to ether_addr_octet[].
> >
>
> I hope there is some other reason/benefit besides getting rid of a
> three-line custom struct definition. It may be a trivial
> s/addr_bytes/ether_addr_octet/ change but it touches a lot of places all
> over the DPDK codebase alone, and for 3rd party developers such (at
> least seemingly) gratuitous renames are really irritating.
>
> - Panu -
>
It allows dropping dependency on cmdline in several places in code (by using ether_ntoa instead).
The problem was a day 0 choice in DPDK to define their own struct's everywhere.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] vhost: note the ABI changes
2015-12-07 3:25 14% [dpdk-dev] [PATCH] vhost: note the ABI changes Yuanhan Liu
@ 2015-12-14 0:33 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-14 0:33 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev
2015-12-07 11:25, Yuanhan Liu:
> Note the ABI changes and update the ABI version to 2.
>
> Cc: Thomas Monjalon <thomas.monjalon@6wind.com>
> Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [dpdk-announce] release candidate 2.2.0-rc4
@ 2015-12-14 0:58 4% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-14 0:58 UTC (permalink / raw)
To: announce
A new DPDK release candidate is ready for testing:
http://dpdk.org/browse/dpdk/tag/?id=v2.2.0-rc4
Changelog (main changes since 2.2.0-rc3)
- enhancements:
* new NIC guides for enic and fm10k
- fixes for:
* compilation
* drivers
* Coverity warnings
This is the last release candidate.
Please check the documentation and ABI versioning.
We also need to validate the pending announces for ABI changes
before releasing. They had too few reviews.
Hope we will be able to close this release really soon.
Thank you everyone
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf
@ 2015-12-14 7:48 21% Jijiang Liu
2015-12-14 9:19 4% ` Chilikin, Andrey
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Jijiang Liu @ 2015-12-14 7:48 UTC (permalink / raw)
To: dev
In current codes, tunnel configuration information is not stored in a device configuration, and it will get nothing if application want to retrieve tunnel config, so I think it is necessary to add rte_eth_dev_tunnel_configure() function is to do the configurations including flow and classification information and store it in a device configuration.
And tunneling packet encapsulation operation will benifit from the change.
There are more descriptions for the ABI changes below,
The struct 'rte_eth_tunnel_conf' is a new, its defination like below,
struct rte_eth_tunnel_conf {
uint16_t tx_queue;
uint16_t filter_type;
struct rte_eth_tunnel_flow flow_tnl;
};
The ABI change announcement of struct 'rte_eth_tunnel_flow' have already sent out, refer to [1].
[1]http://dpdk.org/ml/archives/dev/2015-December/029837.html.
The change of struct 'rte_eth_conf' like below, but it have not finalized yet.
struct rte_eth_conf {
...
uint32_t dcb_capability_en;
struct rte_fdir_conf fdir_conf; /**< FDIR configuration. */
struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */
struct rte_eth_tunnel_conf *tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
/**< Tunnel configuration. */
};
v2 change:
Add more description for the change.
v3 change:
Change ABI announcement description.
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 5c458f2..9dbe89e 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -23,3 +23,9 @@ Deprecation Notices
* ABI changes are planned for struct rte_eth_tunnel_flow in order to extend new fileds to support
tunneling packet configuration in unified tunneling APIs. The release 2.2 does not contain these ABI
changes, but release 2.3 will, and no backwards compatibility is planned.
+
+* ABI changes are planned for the struct rte_eth_conf in order to add 'tunnel_conf' variable
+ in the struct to store tunnel configuration when using new API rte_eth_dev_tunnel_configure
+ (uint8_t port_id, uint16_t rx_queue, struct rte_eth_tunnel_conf * tunnel_conf) to configure
+ tunnel flow and classification information. The release 2.2 does not contain these ABI change,
+ but release 2.3 will, and no backward compatibility is planned.
--
1.7.7.6
^ permalink raw reply [relevance 21%]
* Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf
2015-12-14 7:48 21% [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf Jijiang Liu
@ 2015-12-14 9:19 4% ` Chilikin, Andrey
2015-12-14 15:10 4% ` Thomas Monjalon
2015-12-15 8:50 4% ` Ivan Boule
2 siblings, 0 replies; 200+ results
From: Chilikin, Andrey @ 2015-12-14 9:19 UTC (permalink / raw)
To: Liu, Jijiang, dev
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu
> Sent: Monday, December 14, 2015 7:49 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct
> rte_eth_conf
>
> v2 change:
> Add more description for the change.
>
> v3 change:
> Change ABI announcement description.
>
> Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
Acked-by: Andrey Chilikin <andrey.chilikin@intel.com>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v3] doc: add patch submit cheatsheet
2015-12-09 17:27 1% ` [dpdk-dev] [PATCH v2] " Harry van Haaren
@ 2015-12-14 10:03 1% ` Harry van Haaren
0 siblings, 0 replies; 200+ results
From: Harry van Haaren @ 2015-12-14 10:03 UTC (permalink / raw)
To: dev
This patch adds the patch submission cheatsheet to
the contributers guide. Both HTML and PDF docs show
the cheatsheet on its own page.
Right clicking the SVG image in the HTML doc allows
for viewing the image on its own, useful for printing
in high quality.
The exact appearance of of the cheatsheet will depend
on the default monospace font installed.
Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
---
v3: Added missing rst file, tested building docs on clean dpdk repo.
v2: Fixed Fixes: line, added format-patch workflow instead
of using -N for setting the number of patches during send-email.
doc/guides/contributing/cheatsheet.rst | 8 +
doc/guides/contributing/img/patch_cheatsheet.svg | 1484 ++++++++++++++++++++++
doc/guides/contributing/index.rst | 1 +
3 files changed, 1493 insertions(+)
create mode 100644 doc/guides/contributing/cheatsheet.rst
create mode 100644 doc/guides/contributing/img/patch_cheatsheet.svg
diff --git a/doc/guides/contributing/cheatsheet.rst b/doc/guides/contributing/cheatsheet.rst
new file mode 100644
index 0000000..7bc0771
--- /dev/null
+++ b/doc/guides/contributing/cheatsheet.rst
@@ -0,0 +1,8 @@
+Patch Cheatsheet
+================
+
+.. _figure_patch_cheatsheet:
+
+.. figure:: img/patch_cheatsheet.*
+
+ Cheat sheet for submitting patches to dev@dpdk.org
diff --git a/doc/guides/contributing/img/patch_cheatsheet.svg b/doc/guides/contributing/img/patch_cheatsheet.svg
new file mode 100644
index 0000000..8522592
--- /dev/null
+++ b/doc/guides/contributing/img/patch_cheatsheet.svg
@@ -0,0 +1,1484 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ version="1.1"
+ width="210mm"
+ height="297mm"
+ id="svg2985"
+ inkscape:version="0.48.4 r9939"
+ sodipodi:docname="patch_cheatsheet.svg">
+ <sodipodi:namedview
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1"
+ objecttolerance="10"
+ gridtolerance="10"
+ guidetolerance="10"
+ inkscape:pageopacity="0"
+ inkscape:pageshadow="2"
+ inkscape:window-width="1184"
+ inkscape:window-height="1822"
+ id="namedview274"
+ showgrid="false"
+ inkscape:zoom="1.2685914"
+ inkscape:cx="289.93958"
+ inkscape:cy="509.84194"
+ inkscape:window-x="0"
+ inkscape:window-y="19"
+ inkscape:window-maximized="0"
+ inkscape:current-layer="g3272" />
+ <defs
+ id="defs3">
+ <linearGradient
+ x1="748.62079"
+ y1="-220.1862"
+ x2="849.99768"
+ y2="-220.1862"
+ id="SVGID_1_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop16"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop18"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop20"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop22"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="749.70099"
+ y1="-220.1864"
+ x2="848.91772"
+ y2="-220.1864"
+ id="SVGID_2_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop27"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop29"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop31"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop33"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="760.65948"
+ y1="-220.1864"
+ x2="899.29993"
+ y2="-220.1864"
+ id="SVGID_3_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop40"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop42"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop44"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop46"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="761.73969"
+ y1="-220.1864"
+ x2="898.21973"
+ y2="-220.1864"
+ id="SVGID_4_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop51"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop53"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop55"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop57"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="716.09821"
+ y1="-220.18649"
+ x2="874.64807"
+ y2="-220.18649"
+ id="SVGID_5_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop64"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop66"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop68"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop70"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <linearGradient
+ x1="717.1781"
+ y1="-220.1864"
+ x2="873.56799"
+ y2="-220.1864"
+ id="SVGID_6_"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop75"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop77"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop79"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop81"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ </defs>
+ <metadata
+ id="metadata4">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ <dc:title />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ id="layer1">
+ <switch
+ transform="matrix(0.46699142,0,0,0.41996015,9.9845875,-77.168919)"
+ id="switch3">
+ <g
+ id="g7">
+ <g
+ id="g9">
+ <g
+ id="g11">
+ <g
+ id="g13">
+ <linearGradient
+ x1="748.62079"
+ y1="-220.1862"
+ x2="849.99768"
+ y2="-220.1862"
+ id="linearGradient3172"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3174"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3176"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3178"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3180"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 137.8,342.7 c -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 l 43.3,-17.7 c 5,-1.9 8.9,-5.6 11.1,-10.4 2.2,-4.8 2.4,-10.2 0.5,-15.2 -2.9,-7.7 -10.4,-12.9 -18.6,-12.9 -2.4,0 -4.7,0.4 -7,1.3 l -63.2,22.3 c -0.8,0.3 -1.8,0.6 -2.7,0.6 -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 L 164,271.5 c 3.4,-1.3 6.8,-1.9 10.4,-1.9 12.3,0 23.4,7.7 27.7,19.2 2.8,7.4 2.5,15.4 -0.8,22.6 -3.3,7.2 -9.1,12.7 -16.5,15.5 L 140.5,342 c -0.7,0.3 -1.7,0.7 -2.7,0.7 z"
+ id="path24"
+ style="fill:url(#SVGID_1_)"
+ inkscape:connector-curvature="0" />
+ <linearGradient
+ x1="749.70099"
+ y1="-220.1864"
+ x2="848.91772"
+ y2="-220.1864"
+ id="linearGradient3183"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3185"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3187"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3189"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3191"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="M 184.5,325.9 140.2,341 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 l 43.3,-17.7 c 10.8,-4.1 16.3,-16.2 12.3,-27 -4.1,-10.8 -16.2,-16.3 -27,-12.3 l -63.2,22.2 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 l 62.2,-24.8 c 14.7,-5.5 31.2,2 36.7,16.7 5.5,14.8 -1.9,31.2 -16.6,36.8 z"
+ id="path35"
+ style="fill:url(#SVGID_2_)"
+ inkscape:connector-curvature="0" />
+ </g>
+ <g
+ id="g37">
+ <linearGradient
+ x1="760.65948"
+ y1="-220.1864"
+ x2="899.29993"
+ y2="-220.1864"
+ id="linearGradient3195"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3197"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3199"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3201"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3203"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 147.5,391.7 c -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 l 50.9,-20.6 c 35.7,-13.4 53.9,-53.4 40.5,-89.1 C 229.1,248 203.1,230 174.4,230 c -8.3,0 -16.4,1.5 -24.2,4.4 l -51.9,18 c -0.8,0.3 -1.8,0.6 -2.7,0.6 -1.4,0 -2.5,-0.8 -3,-2.2 -0.6,-1.6 0,-2.7 0.6,-3.4 0.7,-0.8 1.8,-1.2 2.8,-1.6 l 50.9,-20.6 c 8.9,-3.3 18.2,-5 27.7,-5 32.7,0 62.4,20.6 73.9,51.2 15.3,40.7 -5.4,86.3 -46.1,101.6 l -51.9,18 c -1,0.3 -2,0.7 -3,0.7 z"
+ id="path48"
+ style="fill:url(#SVGID_3_)"
+ inkscape:connector-curvature="0" />
+ <linearGradient
+ x1="761.73969"
+ y1="-220.1864"
+ x2="898.21973"
+ y2="-220.1864"
+ id="linearGradient3206"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3208"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3210"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3212"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3214"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 201.8,372 -51.9,18 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 l 50.9,-20.6 c 36.3,-13.6 54.7,-54.2 41.1,-90.5 -13.6,-36.3 -54.2,-54.7 -90.5,-41.1 l -51.9,18 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 L 147,226.2 c 40.2,-15.1 85.1,5.3 100.2,45.5 15.1,40.3 -5.3,85.3 -45.4,100.3 z"
+ id="path59"
+ style="fill:url(#SVGID_4_)"
+ inkscape:connector-curvature="0" />
+ </g>
+ <g
+ id="g61">
+ <linearGradient
+ x1="716.09821"
+ y1="-220.18649"
+ x2="874.64807"
+ y2="-220.18649"
+ id="linearGradient3218"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3220"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3222"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3224"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3226"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 97.1,384.3 c -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 L 190,340.9 c 23,-8.6 34.7,-34.4 26.1,-57.3 -6.5,-17.3 -23.3,-28.9 -41.7,-28.9 -5.3,0 -10.6,1 -15.6,2.8 l -83.9,30 c -0.8,0.3 -1.8,0.6 -2.7,0.6 -1.4,0 -2.5,-0.8 -3,-2.2 -1.2,-3.3 2.1,-4.5 3.3,-5 l 82.9,-32.6 c 6.1,-2.3 12.5,-3.5 19,-3.5 22.5,0 42.9,14.1 50.8,35.2 5.1,13.5 4.6,28.3 -1.4,41.5 -6,13.2 -16.8,23.3 -30.3,28.4 l -93.6,33.7 c -0.8,0.3 -1.8,0.7 -2.8,0.7 z"
+ id="path72"
+ style="fill:url(#SVGID_5_)"
+ inkscape:connector-curvature="0" />
+ <linearGradient
+ x1="717.1781"
+ y1="-220.1864"
+ x2="873.56799"
+ y2="-220.1864"
+ id="linearGradient3229"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(0.9362,-0.3514,0.3514,0.9362,-516.294,793.6274)">
+ <stop
+ id="stop3231"
+ style="stop-color:#f04e23;stop-opacity:1"
+ offset="0.15000001" />
+ <stop
+ id="stop3233"
+ style="stop-color:#782b90;stop-opacity:1"
+ offset="0.70130002" />
+ <stop
+ id="stop3235"
+ style="stop-color:#8a2890;stop-opacity:1"
+ offset="0.8387" />
+ <stop
+ id="stop3237"
+ style="stop-color:#9c258f;stop-opacity:1"
+ offset="1" />
+ </linearGradient>
+ <path
+ d="m 193.1,348.9 -93.6,33.7 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.7,-1.9 0.7,-2.8 2.7,-3.6 l 92.7,-36.2 C 214,333.1 226,306.7 217.2,283.2 208.4,259.7 182,247.7 158.5,256.5 l -83.8,30 c -1.9,0.7 -3.6,1 -4.4,-0.9 -0.8,-1.9 0.7,-2.8 2.7,-3.6 l 82.9,-32.6 c 27.4,-10.3 58.1,3.6 68.4,31.1 10.2,27.5 -3.7,58.2 -31.2,68.4 z"
+ id="path83"
+ style="fill:url(#SVGID_6_)"
+ inkscape:connector-curvature="0" />
+ </g>
+ </g>
+ <g
+ id="g85">
+ <g
+ id="g87">
+ <path
+ d="m 300.7,235.7 h 33.5 c 30.7,0 51.8,19.4 51.8,47.5 0,28.1 -21.2,47.5 -51.8,47.5 h -33.5 v -95 z m 32.2,81.3 c 23.7,0 37.9,-13 37.9,-33.8 0,-20.8 -14.1,-33.8 -37.9,-33.8 H 315.7 V 317 h 17.2 z"
+ id="path89"
+ style="fill:#00233b"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 419.8,235.7 h 40.8 c 20.1,0 31.8,11.5 31.8,27.5 0,16.3 -11.7,28.2 -31.8,28.2 h -25.9 v 39.2 h -14.9 v -94.9 z m 39.7,42 c 11.1,0 17.9,-5.2 17.9,-14.2 0,-9.2 -6.8,-14.1 -17.9,-14.1 h -24.7 v 28.4 h 24.7 z"
+ id="path91"
+ style="fill:#00233b"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 523.2,235.7 h 33.5 c 30.7,0 51.8,19.4 51.8,47.5 0,28.1 -21.2,47.5 -51.8,47.5 h -33.5 v -95 z m 32.2,81.3 c 23.7,0 37.9,-13 37.9,-33.8 0,-20.8 -14.1,-33.8 -37.9,-33.8 H 538.2 V 317 h 17.2 z"
+ id="path93"
+ style="fill:#00233b"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 642.4,235.7 h 14.9 v 38.8 l 38.9,-38.8 h 19.1 l -44,43.4 51,51.6 h -20.4 l -44.8,-45.6 v 45.6 h -14.9 v -95 z"
+ id="path95"
+ style="fill:#00233b"
+ inkscape:connector-curvature="0" />
+ </g>
+ </g>
+ <g
+ id="g97">
+ <path
+ d="m 300.3,360 h 6.3 c 5.7,0 9.7,3.6 9.7,8.9 0,5.3 -4,8.9 -9.7,8.9 h -6.3 V 360 z m 6,15.2 c 4.4,0 7.1,-2.4 7.1,-6.3 0,-3.9 -2.6,-6.3 -7.1,-6.3 H 303 v 12.7 h 3.3 z"
+ id="path99"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 324.6,359.9 h 2.7 l 7.8,17.9 h -3 l -1.9,-4.4 h -8.4 l -1.9,4.4 h -3 l 7.7,-17.9 z m 4.6,11 -3.3,-7.5 -3.3,7.5 h 6.6 z"
+ id="path101"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 348.3,360 v 2.6 h -5.9 v 15.2 h -2.8 v -15.2 h -5.9 V 360 h 14.6 z"
+ id="path103"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 354.7,359.9 h 2.7 l 7.8,17.9 h -3 l -1.9,-4.4 h -8.4 l -1.9,4.4 h -3 l 7.7,-17.9 z m 4.6,11 -3.3,-7.5 -3.3,7.5 h 6.6 z"
+ id="path105"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 380.4,360 h 7.7 c 3.8,0 5.9,2.2 5.9,5.2 0,3.1 -2.2,5.3 -5.9,5.3 h -4.9 v 7.3 h -2.8 V 360 z m 7.4,7.8 c 2.1,0 3.4,-1 3.4,-2.7 0,-1.7 -1.3,-2.6 -3.4,-2.6 h -4.6 v 5.3 h 4.6 z"
+ id="path107"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 397,360 h 2.8 v 15.2 h 9.5 v 2.6 H 397 V 360 z"
+ id="path109"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 418.1,359.9 h 2.7 l 7.8,17.9 h -3 l -1.9,-4.4 h -8.4 l -1.9,4.4 h -3 l 7.7,-17.9 z m 4.6,11 -3.3,-7.5 -3.3,7.5 h 6.6 z"
+ id="path111"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 431.1,360 h 2.4 l 10,12.9 V 360 h 2.7 v 17.8 H 444 l -10.1,-12.9 v 12.9 h -2.7 V 360 z"
+ id="path113"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 450.5,360 h 12.7 v 2.6 h -9.9 v 4.4 h 8 v 2.6 h -8 v 5.6 h 10.2 v 2.6 h -13 V 360 z"
+ id="path115"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 479.3,360 h 6.3 c 5.7,0 9.7,3.6 9.7,8.9 0,5.3 -4,8.9 -9.7,8.9 h -6.3 V 360 z m 6,15.2 c 4.4,0 7.1,-2.4 7.1,-6.3 0,-3.9 -2.6,-6.3 -7.1,-6.3 h -3.2 v 12.7 h 3.2 z"
+ id="path117"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 498.8,360 h 12.7 v 2.6 h -9.9 v 4.4 h 8 v 2.6 h -8 v 5.6 h 10.2 v 2.6 h -13 V 360 z"
+ id="path119"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 513.3,360 h 3.1 l 5.9,14 5.9,-14 h 3 l -7.6,17.9 H 521 L 513.3,360 z"
+ id="path121"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 533.9,360 h 12.7 v 2.6 h -9.9 v 4.4 h 8 v 2.6 h -8 v 5.6 h 10.2 v 2.6 h -13 V 360 z"
+ id="path123"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 549.9,360 h 2.8 v 15.2 h 9.5 v 2.6 H 549.9 V 360 z"
+ id="path125"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 563,368.9 c 0,-5.2 3.8,-9.2 9.1,-9.2 5.3,0 9.1,4 9.1,9.2 0,5.2 -3.9,9.2 -9.1,9.2 -5.2,0 -9.1,-4.1 -9.1,-9.2 z m 15.3,0 c 0,-3.8 -2.7,-6.6 -6.2,-6.6 -3.5,0 -6.2,2.8 -6.2,6.6 0,3.8 2.7,6.6 6.2,6.6 3.5,0 6.2,-2.9 6.2,-6.6 z"
+ id="path127"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 584.7,360 h 7.7 c 3.8,0 5.9,2.2 5.9,5.2 0,3.1 -2.2,5.3 -5.9,5.3 h -4.9 v 7.3 h -2.8 V 360 z m 7.5,7.8 c 2.1,0 3.4,-1 3.4,-2.7 0,-1.7 -1.3,-2.6 -3.4,-2.6 h -4.6 v 5.3 h 4.6 z"
+ id="path129"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 601.3,360 h 2.8 l 5.8,8 5.7,-8 h 2.8 v 17.8 h -2.8 v -13.5 l -5,6.7 H 609 l -5,-6.7 v 13.5 h -2.8 V 360 z"
+ id="path131"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 622.6,360 h 12.7 v 2.6 h -9.9 v 4.4 h 8 v 2.6 h -8 v 5.6 h 10.2 v 2.6 h -13 V 360 z"
+ id="path133"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 638.7,360 h 2.4 l 10,12.9 V 360 h 2.7 v 17.8 h -2.4 l -10.1,-12.9 v 12.9 h -2.7 V 360 z"
+ id="path135"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 671.3,360 v 2.6 h -5.9 v 15.2 h -2.8 v -15.2 h -5.9 V 360 h 14.6 z"
+ id="path137"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 685.5,360 h 2.8 v 7.3 l 7.3,-7.3 h 3.6 l -8.2,8.1 9.6,9.7 h -3.8 l -8.4,-8.5 v 8.5 h -2.8 V 360 z"
+ id="path139"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 702.8,360 h 2.8 v 17.8 h -2.8 V 360 z"
+ id="path141"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 723.1,360 v 2.6 h -5.9 v 15.2 h -2.8 v -15.2 h -5.9 V 360 h 14.6 z"
+ id="path143"
+ style="fill:#f04e23"
+ inkscape:connector-curvature="0" />
+ </g>
+ </g>
+ </g>
+ </switch>
+ <g
+ transform="matrix(0.89980358,0,0,0.89980358,45.57817,-2.8793563)"
+ id="g4009">
+ <text
+ x="325.02054"
+ y="107.5126"
+ id="text3212"
+ xml:space="preserve"
+ style="font-size:43.11383057px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"
+ transform="scale(1.193782,0.83767389)"><tspan
+ x="325.02054"
+ y="107.5126"
+ id="tspan3214">CHEATSHEET</tspan></text>
+ <text
+ x="386.51117"
+ y="58.178116"
+ transform="scale(1.0054999,0.99453018)"
+ id="text3212-1"
+ xml:space="preserve"
+ style="font-size:42.11373901px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="386.51117"
+ y="58.178116"
+ id="tspan3214-7">PATCH SUBMIT</tspan></text>
+ </g>
+ <rect
+ width="714.94495"
+ height="88.618027"
+ rx="20.780111"
+ ry="15.96909"
+ x="14.574773"
+ y="7.0045133"
+ id="rect3239"
+ style="fill:none;stroke:#00233b;stroke-width:0.87678075;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="713.28113"
+ height="887.29156"
+ rx="17.656931"
+ ry="17.280584"
+ x="15.406689"
+ y="104.73515"
+ id="rect3239-0"
+ style="fill:none;stroke:#00233b;stroke-width:1.00973284;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="694.94904"
+ height="381.31"
+ rx="9.4761629"
+ ry="9.0904856"
+ x="24.336016"
+ y="601.75836"
+ id="rect3239-0-9-4"
+ style="fill:none;stroke:#00233b;stroke-width:1.02322531;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <path
+ d="m 386.3921,327.23442 323.14298,0"
+ id="path4088"
+ style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ inkscape:connector-curvature="0" />
+ <text
+ x="396.18015"
+ y="314.45731"
+ id="text4090"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="396.18015"
+ y="314.45731"
+ id="tspan4092"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Patch Pre-Checks</tspan></text>
+ <text
+ x="43.44949"
+ y="147.32129"
+ id="text4090-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="43.44949"
+ y="147.32129"
+ id="tspan4092-3"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Commit Pre-Checks</tspan></text>
+ <text
+ x="397.1235"
+ y="144.8549"
+ id="text4090-4-3"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="397.1235"
+ y="144.8549"
+ id="tspan4092-3-3"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Bugfix?</tspan></text>
+ <text
+ x="41.215897"
+ y="634.38617"
+ id="text4090-1"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="41.215897"
+ y="634.38617"
+ id="tspan4092-38"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Git send-email </tspan></text>
+ <path
+ d="m 31.232443,642.80575 376.113467,0"
+ id="path4088-7"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ inkscape:connector-curvature="0" />
+ <rect
+ width="342.13785"
+ height="230.74609"
+ rx="10.411126"
+ ry="10.411126"
+ x="25.418407"
+ y="114.92036"
+ id="rect3239-0-9-4-2"
+ style="fill:none;stroke:#00233b;stroke-width:0.93674862;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <text
+ x="43.44949"
+ y="385.8045"
+ id="text4090-86"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="43.44949"
+ y="385.8045"
+ id="tspan4092-5"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Compile Pre-Checks</tspan></text>
+ <g
+ transform="translate(352.00486,-348.25973)"
+ id="g3295">
+ <text
+ x="43.87738"
+ y="568.03088"
+ id="text4090-8-14"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="43.87738"
+ y="568.03088"
+ id="tspan4289"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Include warning/error</tspan></text>
+ <text
+ x="43.87738"
+ y="537.71906"
+ id="text4090-8-14-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="43.87738"
+ y="537.71906"
+ id="tspan4289-1"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Fixes: line</tspan></text>
+ <text
+ x="43.87738"
+ y="598.9939"
+ id="text4090-8-14-0"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="43.87738"
+ y="598.9939"
+ id="tspan4289-2"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ How to reproduce</tspan></text>
+ </g>
+ <g
+ transform="translate(-2.6258125,-26.708615)"
+ id="g4115">
+ <g
+ id="g3272">
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1"
+ y="454.36987"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7"
+ y="454.36987"
+ x="49.093246">+ build gcc icc clang </tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2"
+ y="516.59979"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79"
+ y="516.59979"
+ x="49.093246">+ make test doc </tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2-0-0"
+ y="544.71033"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79-9-0"
+ y="544.71033"
+ x="49.093246">+ make examples</tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2-0-07"
+ y="576.83533"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79-9-3"
+ y="576.83533"
+ x="49.093246">+ make shared-lib</tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2-0-07-4"
+ y="604.88947"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79-9-3-9"
+ y="604.88947"
+ x="49.093246">+ library ABI version</tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-2-9"
+ y="486.56659"
+ x="49.093246"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-79-3"
+ y="486.56659"
+ x="49.093246">+ build 32 and 64 bits</tspan></text>
+ </g>
+ </g>
+ <text
+ x="74.388756"
+ y="914.65686"
+ id="text4090-8-1-8-65-9"
+ xml:space="preserve"
+ style="font-size:19px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace"
+ sodipodi:linespacing="125%"><tspan
+ sodipodi:role="line"
+ id="tspan3268"
+ x="74.388756"
+ y="914.65686">git send-email *.patch --annotate --to <maintainer></tspan><tspan
+ sodipodi:role="line"
+ id="tspan3272"
+ x="74.388756"
+ y="938.40686"> --cc dev@dpdk.org [ --cc other@participants.com</tspan><tspan
+ sodipodi:role="line"
+ x="74.388756"
+ y="962.15686"
+ id="tspan3266"> --cover-letter -v[N] --in-reply-to <message ID> ]</tspan></text>
+ <text
+ x="543.47675"
+ y="1032.3459"
+ id="text4090-8-7-8-7-6-3-8-2-5"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="543.47675"
+ y="1032.3459"
+ id="tspan4092-8-6-3-1-8-4-4-5-3"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">harry.van.haaren@intel.com</tspan></text>
+ <rect
+ width="678.14105"
+ height="87.351799"
+ rx="6.7972355"
+ ry="6.7972355"
+ x="31.865864"
+ y="888.44696"
+ id="rect3239-0-9-4-3"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <text
+ x="543.29498"
+ y="1018.1843"
+ id="text4090-8-7-8-7-6-3-8-2-5-3"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="543.29498"
+ y="1018.1843"
+ id="tspan4092-8-6-3-1-8-4-4-5-3-7"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Suggestions / Updates?</tspan></text>
+ <g
+ id="g3268"
+ transform="translate(0,-6)">
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1-8"
+ y="704.07019"
+ x="41.658669"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7-6"
+ y="704.07019"
+ x="41.658669">+ Patch version ( eg: -v2 ) </tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1-8-0"
+ y="736.29175"
+ x="41.658669"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7-6-2"
+ y="736.29175"
+ x="41.658669">+ Patch version annotations</tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1-8-6"
+ y="766.70355"
+ x="41.911205"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7-6-1"
+ y="766.70355"
+ x="41.911205">+ Send --to maintainer </tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1-8-6-3"
+ y="795.30548"
+ x="41.658669"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7-6-1-8"
+ y="795.30548"
+ x="41.658669">+ Send --cc dev@dpdk.org </tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1-8-9"
+ y="675.25287"
+ x="41.658669"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7-6-9"
+ y="675.25287"
+ x="41.658669">+ Cover letter</tspan></text>
+ <g
+ id="g3303"
+ transform="translate(1.0962334,-40.034939)">
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1-8-65"
+ y="868.70337"
+ x="41.572586"><tspan
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7-6-10"
+ y="868.70337"
+ x="41.572586">+ Send --in-reply-to <message ID><tspan
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan3184" /></tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ xml:space="preserve"
+ id="text4090-8-1-8-9-1"
+ y="855.79816"
+ x="460.18405"><tspan
+ style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ id="tspan4092-8-7-6-9-7"
+ y="855.79816"
+ x="460.18405">****</tspan></text>
+ </g>
+ </g>
+ <text
+ x="685.67828"
+ y="76.55056"
+ id="text4090-8-1-8-9-1-9"
+ xml:space="preserve"
+ style="font-size:20.20989037px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="685.67828"
+ y="76.55056"
+ id="tspan4092-8-7-6-9-7-4"
+ style="font-size:9.09445095px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">v1.0</tspan></text>
+ <rect
+ width="342.3053"
+ height="155.54948"
+ rx="9.2344503"
+ ry="9.2344503"
+ x="377.58942"
+ y="114.55766"
+ id="rect3239-0-9-4-2-1"
+ style="fill:none;stroke:#00233b;stroke-width:0.76930124;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="342.12564"
+ height="236.79482"
+ rx="10.647112"
+ ry="9.584527"
+ x="25.642178"
+ y="356.86249"
+ id="rect3239-0-9-4-2-0"
+ style="fill:none;stroke:#00233b;stroke-width:0.9489302;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="341.98428"
+ height="312.73181"
+ rx="8.5358429"
+ ry="8.5358429"
+ x="377.96762"
+ y="280.45331"
+ id="rect3239-0-9-4-2-1-9"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <path
+ d="m 387.02742,157.3408 323.14298,0"
+ id="path4088-8"
+ style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 36.504486,397.33869 323.142974,0"
+ id="path4088-82"
+ style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 35.494337,156.92238 323.142983,0"
+ id="path4088-4"
+ style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ inkscape:connector-curvature="0" />
+ <g
+ transform="translate(1.0962334,-30.749225)"
+ id="g3363">
+ <text
+ x="45.371201"
+ y="214.1572"
+ id="text4090-8-11"
+ xml:space="preserve"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="214.1572"
+ id="tspan4092-8-52"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Signed-off-by: </tspan></text>
+ <text
+ x="45.371201"
+ y="243.81795"
+ id="text4090-8-7-8"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="243.81795"
+ id="tspan4092-8-6-3"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Suggested-by:</tspan></text>
+ <text
+ x="45.371201"
+ y="273.90939"
+ id="text4090-8-7-8-7"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="273.90939"
+ id="tspan4092-8-6-3-1"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Reported-by:</tspan></text>
+ <text
+ x="45.371201"
+ y="304.00082"
+ id="text4090-8-7-8-7-6"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="304.00082"
+ id="tspan4092-8-6-3-1-8"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Tested-by:</tspan></text>
+ <g
+ id="g3297"
+ transform="translate(1.1147904,-7.2461378)">
+ <text
+ x="45.371201"
+ y="368.8187"
+ id="text4090-8-7-8-7-6-3"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="368.8187"
+ id="tspan4092-8-6-3-1-8-4"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Previous Acks</tspan></text>
+ <text
+ x="235.24362"
+ y="360.3028"
+ id="text4090-8-1-8-9-1-4"
+ xml:space="preserve"
+ style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="235.24362"
+ y="360.3028"
+ id="tspan4092-8-7-6-9-7-0"
+ style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ </g>
+ <text
+ x="45.371201"
+ y="334.52298"
+ id="text4090-8-7-8-7-6-3-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="45.371201"
+ y="334.52298"
+ id="tspan4092-8-6-3-1-8-4-0"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Commit message</tspan></text>
+ </g>
+ <rect
+ width="295.87207"
+ height="164.50136"
+ rx="7.3848925"
+ ry="4.489974"
+ x="414.80502"
+ y="611.47064"
+ id="rect3239-0-9-4-2-1-9-9"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <text
+ x="439.4429"
+ y="638.35608"
+ id="text4090-1-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="439.4429"
+ y="638.35608"
+ id="tspan4092-38-8"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Mailing List</tspan></text>
+ <text
+ x="431.55353"
+ y="675.59857"
+ id="text4090-8-5-6-9-4-6-6-8"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="431.55353"
+ y="675.59857"
+ id="tspan4092-8-5-5-3-4-0-6-2"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Acked-by:</tspan></text>
+ <text
+ x="431.39734"
+ y="734.18231"
+ id="text4090-8-5-6-9-4-6-6-8-5"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="431.39734"
+ y="734.18231"
+ id="tspan4092-8-5-5-3-4-0-6-2-1"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Reviewed-by:</tspan></text>
+ <text
+ x="450.8428"
+ y="766.5578"
+ id="text4090-8-5-6-9-4-6-6-8-7"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="450.8428"
+ y="766.5578"
+ id="tspan4092-8-5-5-3-4-0-6-2-11"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Nack (refuse patch)</tspan></text>
+ <path
+ d="m 426.99385,647.80575 272.72607,0"
+ id="path4088-7-5"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ inkscape:connector-curvature="0" />
+ <path
+ d="m 424.7332,742.35699 272.72607,0"
+ id="path4088-7-5-2"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ inkscape:connector-curvature="0" />
+ <text
+ x="431.39734"
+ y="704.78278"
+ id="text4090-8-5-6-9-4-6-6-8-5-1"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="431.39734"
+ y="704.78278"
+ id="tspan4092-8-5-5-3-4-0-6-2-1-7"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Tested-by:</tspan></text>
+ <g
+ transform="translate(1.0962334,-2.7492248)"
+ id="g3613">
+ <text
+ x="43.146141"
+ y="1007.5879"
+ id="text4090-8-7-8-7-6-3-8"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="43.146141"
+ y="1007.5879"
+ id="tspan4092-8-6-3-1-8-4-4"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">Previous Acks only when fixing typos, rebased, or checkpatch issues.</tspan></text>
+ <text
+ x="30.942892"
+ y="1011.3757"
+ id="text4090-8-7-8-7-6-3-8-4-1"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="30.942892"
+ y="1011.3757"
+ id="tspan4092-8-6-3-1-8-4-4-55-7"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ </g>
+ <g
+ transform="translate(1.0962334,-2.7492248)"
+ id="g3605">
+ <text
+ x="42.176418"
+ y="1020.4383"
+ id="text4090-8-7-8-7-6-3-8-4"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="42.176418"
+ y="1020.4383"
+ id="tspan4092-8-6-3-1-8-4-4-55"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">The version.map function names must be in alphabetical order.</tspan></text>
+ <text
+ x="30.942892"
+ y="1024.2014"
+ id="text4090-8-7-8-7-6-3-8-4-1-5"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="30.942892"
+ y="1024.2014"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-2"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="25.247679"
+ y="1024.2014"
+ id="text4090-8-7-8-7-6-3-8-4-1-5-6"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="25.247679"
+ y="1024.2014"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-2-8"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ </g>
+ <g
+ transform="translate(1.0962334,-30.749225)"
+ id="g3275">
+ <g
+ id="g3341">
+ <text
+ x="394.78601"
+ y="390.17807"
+ id="text4090-8"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="390.17807"
+ id="tspan4092-8"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Rebase to git </tspan></text>
+ <text
+ x="394.78601"
+ y="420.24835"
+ id="text4090-8-5"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="420.24835"
+ id="tspan4092-8-5"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Checkpatch </tspan></text>
+ <text
+ x="394.78601"
+ y="450.53394"
+ id="text4090-8-5-6"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="450.53394"
+ id="tspan4092-8-5-5"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ ABI breakage </tspan></text>
+ <text
+ x="394.78601"
+ y="513.13031"
+ id="text4090-8-5-6-9-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="513.13031"
+ id="tspan4092-8-5-5-3-4"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Maintainers file</tspan></text>
+ <text
+ x="394.78601"
+ y="573.48621"
+ id="text4090-8-5-6-9-4-6"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="573.48621"
+ id="tspan4092-8-5-5-3-4-0"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Release notes</tspan></text>
+ <text
+ x="395.79617"
+ y="603.98718"
+ id="text4090-8-5-6-9-4-6-6"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="395.79617"
+ y="603.98718"
+ id="tspan4092-8-5-5-3-4-0-6"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Documentation</tspan></text>
+ <g
+ transform="translate(0,-0.83470152)"
+ id="g3334">
+ <g
+ id="g3267"
+ transform="translate(-13.517932,3.1531035)">
+ <text
+ x="660.46729"
+ y="468.01297"
+ id="text4090-8-1-8-9-1-4-1"
+ xml:space="preserve"
+ style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="660.46729"
+ y="468.01297"
+ id="tspan4092-8-7-6-9-7-0-7"
+ style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">**</tspan></text>
+ </g>
+ <text
+ x="394.78601"
+ y="483.59955"
+ id="text4090-8-5-6-9"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="483.59955"
+ id="tspan4092-8-5-5-3"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Update version.map</tspan></text>
+ </g>
+ <g
+ id="g3428"
+ transform="translate(0,0.88137813)">
+ <text
+ x="394.78601"
+ y="541.38928"
+ id="text4090-8-5-6-9-4-6-1"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="394.78601"
+ y="541.38928"
+ id="tspan4092-8-5-5-3-4-0-7"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Doxygen</tspan></text>
+ <g
+ transform="translate(-119.92979,57.949844)"
+ id="g3267-9">
+ <text
+ x="628.93628"
+ y="473.13675"
+ id="text4090-8-1-8-9-1-4-1-4"
+ xml:space="preserve"
+ style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="628.93628"
+ y="473.13675"
+ id="tspan4092-8-7-6-9-7-0-7-8"
+ style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">***</tspan></text>
+ </g>
+ </g>
+ </g>
+ </g>
+ <text
+ x="840.1828"
+ y="234.34692"
+ transform="matrix(0.70710678,0.70710678,-0.70710678,0.70710678,0,0)"
+ id="text4090-8-5-6-9-4-6-6-8-7-4"
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ sodipodi:linespacing="125%"><tspan
+ x="840.1828"
+ y="234.34692"
+ id="tspan4092-8-5-5-3-4-0-6-2-11-0"
+ style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+</tspan></text>
+ <g
+ transform="translate(1.0962334,-2.7492248)"
+ id="g3595">
+ <text
+ x="30.942892"
+ y="1037.0271"
+ id="text4090-8-7-8-7-6-3-8-4-1-2"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="30.942892"
+ y="1037.0271"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="25.247679"
+ y="1037.0271"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-5"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="25.247679"
+ y="1037.0271"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-7"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="19.552465"
+ y="1037.0271"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-7"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="19.552465"
+ y="1037.0271"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-9"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="42.830166"
+ y="1033.2393"
+ id="text4090-8-7-8-7-6-3-8-4-8"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="42.830166"
+ y="1033.2393"
+ id="tspan4092-8-6-3-1-8-4-4-55-2"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">New header files must get a new page in the API docs.</tspan></text>
+ </g>
+ <g
+ transform="translate(1.0962334,-2.7492248)"
+ id="g3619">
+ <text
+ x="42.212418"
+ y="1046.0962"
+ id="text4090-8-7-8-7-6-3-8-2"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ sodipodi:linespacing="125%"><tspan
+ x="42.212418"
+ y="1046.0962"
+ id="tspan4092-8-6-3-1-8-4-4-5"
+ style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">Available from patchwork, or email header. Reply to Cover letters.</tspan></text>
+ <text
+ x="31.140535"
+ y="1049.8527"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-2"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="31.140535"
+ y="1049.8527"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-3"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="25.445322"
+ y="1049.8527"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-5-2"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="25.445322"
+ y="1049.8527"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-7-2"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="19.750109"
+ y="1049.8527"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-7-1"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="19.750109"
+ y="1049.8527"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-9-6"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ <text
+ x="14.016749"
+ y="1049.8527"
+ id="text4090-8-7-8-7-6-3-8-4-1-2-7-1-8"
+ xml:space="preserve"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ x="14.016749"
+ y="1049.8527"
+ id="tspan4092-8-6-3-1-8-4-4-55-7-3-9-6-5"
+ style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ </g>
+ <rect
+ width="196.44218"
+ height="45.785767"
+ rx="10.771052"
+ ry="10.771052"
+ x="531.44666"
+ y="998.50568"
+ id="rect3239-0-9-4-2-1-9-9-7"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <rect
+ width="678.43036"
+ height="43.497677"
+ rx="7.8557949"
+ ry="6.7630997"
+ x="31.274473"
+ y="836.69745"
+ id="rect3239-0-9-4-3-6"
+ style="fill:none;stroke:#00233b;stroke-width:0.92794865;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ <text
+ x="73.804535"
+ y="864.28137"
+ id="text4090-8-1-8-65-9-1"
+ xml:space="preserve"
+ style="font-size:19px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace"
+ sodipodi:linespacing="125%"><tspan
+ sodipodi:role="line"
+ x="73.804535"
+ y="864.28137"
+ id="tspan3266-8">git format-patch -[N]</tspan></text>
+ <text
+ x="342.70221"
+ y="862.83478"
+ id="text4090-8-1-8-65-9-1-7"
+ xml:space="preserve"
+ style="font-size:19px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace"
+ sodipodi:linespacing="125%"><tspan
+ sodipodi:role="line"
+ x="342.70221"
+ y="862.83478"
+ id="tspan3266-8-2"
+ style="font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">// creates .patch files for final review</tspan></text>
+ </g>
+</svg>
diff --git a/doc/guides/contributing/index.rst b/doc/guides/contributing/index.rst
index 561427b..8dadb20 100644
--- a/doc/guides/contributing/index.rst
+++ b/doc/guides/contributing/index.rst
@@ -9,3 +9,4 @@ Contributor's Guidelines
design
versioning
documentation
+ cheatsheet
--
1.9.1
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size
@ 2015-12-14 14:13 4% ` Thomas Monjalon
2015-12-14 14:54 7% ` Olga Shern
2015-12-15 6:11 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-14 14:13 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev
2015-11-10 17:29, Mcnamara, John:
> From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > Current buffer size are not enough for a few testpmd commands.
> >
> > Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 2/2] doc: announce ABI change for RETA configuration
@ 2015-12-14 14:25 4% ` Thomas Monjalon
2015-12-14 15:09 7% ` Olga Shern
2015-12-15 5:32 4% ` Lu, Wenzhuo
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-14 14:25 UTC (permalink / raw)
To: Nelio Laranjeiro; +Cc: dev
2015-11-09 17:48, Nelio Laranjeiro:
> +* ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
> + which handles at most 256 entries (8 bits) while newer NICs support larger
> + tables (512 entries).
> + It should be integrated in release 2.3.
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_filter_conf
@ 2015-12-14 14:35 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-14 14:35 UTC (permalink / raw)
To: Jingjing Wu; +Cc: dev
2015-11-10 11:49, Jingjing Wu:
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -32,3 +32,8 @@ Deprecation Notices
> and table action handlers will be updated:
> the pipeline parameter will be added, the packets mask parameter will be
> either removed (for input port action handler) or made input-only.
> +
> +* ABI changes are planned for rte_eth_tunnel_filter_conf. Change the fields
> + of outer_mac and inner_mac from pointer to struct in order to keep the
> + code's readability. The release 2.2 does not contain these ABI changes, but
> + release 2.3 will, and no backwards compatibility is planned.
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size
2015-12-14 14:13 4% ` Thomas Monjalon
@ 2015-12-14 14:54 7% ` Olga Shern
0 siblings, 0 replies; 200+ results
From: Olga Shern @ 2015-12-14 14:54 UTC (permalink / raw)
To: Thomas Monjalon, Mcnamara, John; +Cc: dev
Acked-by: Olga Shern <olgas@mellanox.com>
-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Monday, December 14, 2015 4:13 PM
To: Mcnamara, John <john.mcnamara@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size
2015-11-10 17:29, Mcnamara, John:
> From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > Current buffer size are not enough for a few testpmd commands.
> >
> > Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH] doc: announce API change for rte_ether.h
2015-12-10 23:27 5% [dpdk-dev] [PATCH] doc: announce API change for rte_ether.h Stephen Hemminger
2015-12-11 9:28 0% ` Panu Matilainen
@ 2015-12-14 14:54 0% ` Thomas Monjalon
2015-12-14 15:30 0% ` Bruce Richardson
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-14 14:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
2015-12-10 15:27, Stephen Hemminger:
> Plan to change to <net/ethernet.h> version of struct ether_addr in
> DPDK 2.3. The change in DPDK source is trivial but it will impact
> source compatablilty therefore notification is necessary.
[...]
> +* librte_ether: The structure ether_addr in DPDK will be replaced
> + by using the standard header file <net/ethernet.h>. The structure
> + size will be the same (no ABI impact), but the structure field name
> + will change from addr_bytes[] to ether_addr_octet[].
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Any other votes for this API cleanup?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/2] doc: announce ABI change for RETA configuration
2015-12-14 14:25 4% ` Thomas Monjalon
@ 2015-12-14 15:09 7% ` Olga Shern
0 siblings, 0 replies; 200+ results
From: Olga Shern @ 2015-12-14 15:09 UTC (permalink / raw)
To: Thomas Monjalon, Nelio Laranjeiro; +Cc: dev
Acked-by: Olga Shern <olgas@mellanox.com>
-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Monday, December 14, 2015 4:25 PM
To: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 2/2] doc: announce ABI change for RETA configuration
2015-11-09 17:48, Nelio Laranjeiro:
> +* ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
> + which handles at most 256 entries (8 bits) while newer NICs support larger
> + tables (512 entries).
> + It should be integrated in release 2.3.
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf
2015-12-14 7:48 21% [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf Jijiang Liu
2015-12-14 9:19 4% ` Chilikin, Andrey
@ 2015-12-14 15:10 4% ` Thomas Monjalon
2015-12-15 3:00 4% ` Liu, Jijiang
2015-12-15 8:50 4% ` Ivan Boule
2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-14 15:10 UTC (permalink / raw)
To: Jijiang Liu; +Cc: dev
2015-12-14 15:48, Jijiang Liu:
> In current codes, tunnel configuration information is not stored in a device configuration, and it will get nothing if application want to retrieve tunnel config, so I think it is necessary to add rte_eth_dev_tunnel_configure() function is to do the configurations including flow and classification information and store it in a device configuration.
>
> And tunneling packet encapsulation operation will benifit from the change.
Sorry, I don't understand what you mean.
Maybe others have a clue?
> There are more descriptions for the ABI changes below,
>
> The struct 'rte_eth_tunnel_conf' is a new, its defination like below,
> struct rte_eth_tunnel_conf {
> uint16_t tx_queue;
> uint16_t filter_type;
> struct rte_eth_tunnel_flow flow_tnl;
> };
>
> The ABI change announcement of struct 'rte_eth_tunnel_flow' have already sent out, refer to [1].
>
> [1]http://dpdk.org/ml/archives/dev/2015-December/029837.html.
>
> The change of struct 'rte_eth_conf' like below, but it have not finalized yet.
> struct rte_eth_conf {
> ...
> uint32_t dcb_capability_en;
> struct rte_fdir_conf fdir_conf; /**< FDIR configuration. */
> struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */
> struct rte_eth_tunnel_conf *tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
> /**< Tunnel configuration. */
> };
More generally, is it possible/reasonnable to try saving the whole device
configuration in this struct? What is the limit?
This rte_eth_conf struct is an input for rte_eth_dev_configure().
Should we add some fields which are not used by rte_eth_dev_configure()
but configured through rte_eth_dev_filter_ctrl() instead?
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_flow
2015-12-09 5:37 11% [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_flow Jijiang Liu
2015-12-09 5:42 4% ` Lu, Wenzhuo
@ 2015-12-14 15:03 4% ` Thomas Monjalon
2015-12-15 1:17 4% ` Liu, Jijiang
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-14 15:03 UTC (permalink / raw)
To: Jijiang Liu; +Cc: dev
2015-12-09 13:37, Jijiang Liu:
> The struct 'rte_eth_tunnel_flow' is only used by struct 'rte_eth_fdir_flow' now, but its name is generic,
> and I plan to extend new fileds like below to support generic configuration for tunneling packet.
You have not explained what the changes are for.
So it's really difficult to have an opinion.
Please describe an use case.
PS: "filed" -> "field"
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce API change for rte_ether.h
2015-12-14 14:54 0% ` Thomas Monjalon
@ 2015-12-14 15:30 0% ` Bruce Richardson
2015-12-14 15:41 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2015-12-14 15:30 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Mon, Dec 14, 2015 at 03:54:06PM +0100, Thomas Monjalon wrote:
> 2015-12-10 15:27, Stephen Hemminger:
> > Plan to change to <net/ethernet.h> version of struct ether_addr in
> > DPDK 2.3. The change in DPDK source is trivial but it will impact
> > source compatablilty therefore notification is necessary.
> [...]
> > +* librte_ether: The structure ether_addr in DPDK will be replaced
> > + by using the standard header file <net/ethernet.h>. The structure
> > + size will be the same (no ABI impact), but the structure field name
> > + will change from addr_bytes[] to ether_addr_octet[].
>
>
> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
>
> Any other votes for this API cleanup?
>
Are the structures and contents of net/ethernet.h the same on both Linux and
FreeBSD?
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce API change for rte_ether.h
2015-12-14 15:30 0% ` Bruce Richardson
@ 2015-12-14 15:41 0% ` Thomas Monjalon
2015-12-14 16:00 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-14 15:41 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
2015-12-14 15:30, Bruce Richardson:
> On Mon, Dec 14, 2015 at 03:54:06PM +0100, Thomas Monjalon wrote:
> > 2015-12-10 15:27, Stephen Hemminger:
> > > Plan to change to <net/ethernet.h> version of struct ether_addr in
> > > DPDK 2.3. The change in DPDK source is trivial but it will impact
> > > source compatablilty therefore notification is necessary.
> > [...]
> > > +* librte_ether: The structure ether_addr in DPDK will be replaced
> > > + by using the standard header file <net/ethernet.h>. The structure
> > > + size will be the same (no ABI impact), but the structure field name
> > > + will change from addr_bytes[] to ether_addr_octet[].
> >
> >
> > Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> >
> > Any other votes for this API cleanup?
> >
> Are the structures and contents of net/ethernet.h the same on both Linux and
> FreeBSD?
Good question. I'm afraid the answer is no.
In FreeBSD, it is ether_addr.octet[].
Linux
-----
struct ether_addr
{
u_int8_t ether_addr_octet[ETH_ALEN];
} __attribute__ ((__packed__));
struct ether_header
{
u_int8_t ether_dhost[ETH_ALEN]; /* destination eth addr */
u_int8_t ether_shost[ETH_ALEN]; /* source ether addr */
u_int16_t ether_type; /* packet type ID field */
} __attribute__ ((__packed__));
FreeBSD
-------
struct ether_addr {
u_char octet[ETHER_ADDR_LEN];
} __packed;
struct ether_header {
u_char ether_dhost[ETHER_ADDR_LEN];
u_char ether_shost[ETHER_ADDR_LEN];
u_short ether_type;
} __packed;
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce API change for rte_ether.h
2015-12-14 15:41 0% ` Thomas Monjalon
@ 2015-12-14 16:00 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2015-12-14 16:00 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Mon, Dec 14, 2015 at 04:41:28PM +0100, Thomas Monjalon wrote:
> 2015-12-14 15:30, Bruce Richardson:
> > On Mon, Dec 14, 2015 at 03:54:06PM +0100, Thomas Monjalon wrote:
> > > 2015-12-10 15:27, Stephen Hemminger:
> > > > Plan to change to <net/ethernet.h> version of struct ether_addr in
> > > > DPDK 2.3. The change in DPDK source is trivial but it will impact
> > > > source compatablilty therefore notification is necessary.
> > > [...]
> > > > +* librte_ether: The structure ether_addr in DPDK will be replaced
> > > > + by using the standard header file <net/ethernet.h>. The structure
> > > > + size will be the same (no ABI impact), but the structure field name
> > > > + will change from addr_bytes[] to ether_addr_octet[].
> > >
> > >
> > > Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> > >
> > > Any other votes for this API cleanup?
> > >
> > Are the structures and contents of net/ethernet.h the same on both Linux and
> > FreeBSD?
>
> Good question. I'm afraid the answer is no.
> In FreeBSD, it is ether_addr.octet[].
>
> Linux
> -----
>
> struct ether_addr
> {
> u_int8_t ether_addr_octet[ETH_ALEN];
> } __attribute__ ((__packed__));
>
> struct ether_header
> {
> u_int8_t ether_dhost[ETH_ALEN]; /* destination eth addr */
> u_int8_t ether_shost[ETH_ALEN]; /* source ether addr */
> u_int16_t ether_type; /* packet type ID field */
> } __attribute__ ((__packed__));
>
> FreeBSD
> -------
>
> struct ether_addr {
> u_char octet[ETHER_ADDR_LEN];
> } __packed;
>
> struct ether_header {
> u_char ether_dhost[ETHER_ADDR_LEN];
> u_char ether_shost[ETHER_ADDR_LEN];
> u_short ether_type;
> } __packed;
>
Unfortunate. While the idea seems good, I think the structures being different
on the different OS's is a problem that need to be solved before we make such
a change.
/Bruce
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] doc: fix release notes for 2.2
@ 2015-12-14 18:51 1% John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2015-12-14 18:51 UTC (permalink / raw)
To: dev
Fix grammar, spelling and formatting of DPDK 2.2 release notes.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/release_2_2.rst | 335 ++++++++++++++++++-----------------
1 file changed, 171 insertions(+), 164 deletions(-)
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index c0f3be2..cfcb88c 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -4,7 +4,7 @@ DPDK Release 2.2
New Features
------------
-* **Introduce ARMv7 and ARMv8 architectures**
+* **Introduce ARMv7 and ARMv8 architectures.**
* It is now possible to build DPDK for the ARMv7 and ARMv8 platforms.
* ARMv7 can be tested with virtual PMD drivers.
@@ -12,14 +12,14 @@ New Features
* **Enabled freeing of ring.**
- New function rte_ring_free() allows the user to free a ring
- if it was created with rte_ring_create().
+ A new function ``rte_ring_free()`` has been added to allow the user to free
+ a ring if it was created with ``rte_ring_create()``.
* **Added keepalive support to EAL and example application.**
* **Added experimental cryptodev API**
- The cryptographic processing of packet is provided as a preview
+ The cryptographic processing of packets is provided as a preview
with two drivers for:
* Intel QuickAssist devices
@@ -27,29 +27,32 @@ New Features
Due to its experimental state, the API may change without prior notice.
-* **Added ethdev API to support IEEE1588.**
+* **Added ethdev APIs for additional IEEE1588 support.**
Added functions to read, write and adjust system time in the NIC.
+ Added client slave sample application to demonstrate the IEEE1588
+ functionality.
-* **Extended Statistics**
+* **Extended Statistics.**
- Define extended statistics naming scheme to store metadata in the name
- string name of each statistic, refer to the Extended Statistics section
- of the programmers guide. Implemented the extended stats API for these
- PMDs:
+ Defined an extended statistics naming scheme to store metadata in the name
+ string of each statistic. Refer to the Extended Statistics section of the
+ Programmers Guide for more details.
- * igb
- * igbvf
- * i40e
- * i40evf
- * fm10k
- * virtio
+ Implemented the extended statistics API for the following PMDs:
+
+ * ``igb``
+ * ``igbvf``
+ * ``i40e``
+ * ``i40evf``
+ * ``fm10k``
+ * ``virtio``
* **Added API in ethdev to retrieve RX/TX queue information.**
- * Add the ability for the upper layer to query RX/TX queue information.
- * Add into rte_eth_dev_info new fields to represent information about
- RX/TX descriptors min/max/align numbers per queue for the device.
+ * Added the ability for the upper layer to query RX/TX queue information.
+ * Added new fields in ``rte_eth_dev_info`` to represent information about
+ RX/TX descriptors min/max/align numbers, per queue, for the device.
* **Added RSS dynamic configuration to bonding.**
@@ -58,31 +61,31 @@ New Features
The e1000 base driver was updated with several features including the
following:
- * Add new i218 devices
- * Allow both ULP and EEE in Sx state
- * Initialize 88E1543 (Marvell 1543) PHY
- * Add flags to set EEE advertisement modes
- * Support inverted format ETrackId
- * Add bit to disable packetbuffer read
- * Add defaults for i210 Rx/Tx PBSIZE
+ * Added new i218 devices
+ * Allowed both ULP and EEE in Sx state
+ * Initialized 88E1543 (Marvell 1543) PHY
+ * Added flags to set EEE advertisement modes
+ * Supported inverted format ETrackId
+ * Added bit to disable packetbuffer read
+ * Added defaults for i210 RX/TX PBSIZE
* Check more errors for ESB2 init and reset
* Check more NVM read errors
* Return code after setting receive address register
- * Remove all NAHUM6LP_HW tags
+ * Removed all NAHUM6LP_HW tags
-* **Added e1000 Rx interrupt support.**
+* **Added e1000 RX interrupt support.**
* **Added igb TSO support for both PF and VF.**
-* **RSS enhancement on Intel x550 NIC**
+* **Added RSS enhancements to Intel x550 NIC.**
- * Support 512 entries RSS redirection table.
- * Support per VF RSS redirection table.
+ * Added support for 512 entry RSS redirection table.
+ * Added support for per VF RSS redirection table.
-* **Flow director enhancement on Intel x550 NIC**
+* **Added Flow director enhancements on Intel x550 NIC.**
- * Add 2 new flow director modes on x550.
- * One is MAC VLAN mode, the other is tunnel mode.
+ * Added 2 new flow director modes on x550.
+ One is MAC VLAN mode, the other is tunnel mode.
* **Updated the i40e base driver.**
@@ -92,16 +95,16 @@ New Features
* Added promiscuous on VLAN support
* Added a workaround to drop all flow control frames
* Added VF capabilities to virtual channel interface
- * Added Tx Scheduling related AQ commands
+ * Added TX Scheduling related AQ commands
* Added additional PCTYPES supported for FortPark RSS
* Added parsing for CEE DCBX TLVs
* Added FortPark specific registers
* Added AQ functions to handle RSS Key and LUT programming
- * Increased pf reset max loop limit
+ * Increased PF reset max loop limit
* **Added i40e vector RX/TX.**
-* **Added i40e Rx interrupt support.**
+* **Added i40e RX interrupt support.**
* **Added i40e flow control support.**
@@ -115,7 +118,7 @@ New Features
* **Added i40e support of early X722 series.**
- Add early X722 support for evaluation only, as the hardware is in A0.
+ Added early X722 support, for evaluation only, as the hardware is alpha.
* **Added fm10k vector RX/TX.**
@@ -125,16 +128,16 @@ New Features
* **New NIC Boulder Rapid support.**
- Boulder Rapid is a new NIC of Intel's fm10k family.
+ Added support for the Boulder Rapid variant of Intel's fm10k NIC family.
* **Enhanced support for the Chelsio CXGBE driver.**
* Added support for Jumbo Frames.
- * Optimize forwarding performance for Chelsio T5 40GbE cards.
+ * Optimized forwarding performance for Chelsio T5 40GbE cards.
-* **Improved enic Tx packet rate.**
+* **Improved enic TX packet rate.**
- Reduced frequency of Tx tail pointer updates to the NIC.
+ Reduced frequency of TX tail pointer updates to the NIC.
* **Added support for link status interrupts in mlx4.**
@@ -173,30 +176,30 @@ New Features
* **Added experimental performance thread example application.**
- The application demonstrates L3 fowarding with different threading
- models: pthreads, cgroups, or lighweight threads. The example inludes
+ The new sample application demonstrates L3 forwarding with different threading
+ models: pthreads, cgroups, or lightweight threads. The example includes
a simple cooperative scheduler.
Due to its experimental state this application may change without notice.
The application is supported only for Linux x86_64.
-* **IP pipeline application**
+* **Enhancements to the IP pipeline application.**
- The following features have been added to ip_pipeline
+ The following features have been added to the ``ip_pipeline``
application;
- * Added Multiple Producers Multiple Consumers (MPSC)
+ * Added Multiple Producers/Multiple Consumers (MPSC)
and fragmentation/reassembly support to software rings.
- * Added dynamic pipeline reconfiguration feature that
- allows binding pipeline to other threads at runtime
+ * Added a dynamic pipeline reconfiguration feature that
+ allows binding a pipeline to other threads at runtime
using CLI commands.
- * Added Enable/disable of promisc mode from ip_pipeline
+ * Added enable/disable of ``promisc`` mode from ``ip_pipeline``
configuration file.
- * Added check on rx queues and tx queues of each link
- whether they are used correctly in ip_pipeline
+ * Added check on RX queues and TX queues of each link
+ whether they are used correctly in the ``ip_pipeline``
configuration file.
* Added flow id parameters to the flow-classification
@@ -204,14 +207,14 @@ New Features
* Added more functions to the routing pipeline:
ARP table enable/disable, Q-in-Q and MPLS encapsulation,
- add colour (Traffic-class for QoS) to the MPLS tag.
+ add color (traffic-class for QoS) to the MPLS tag.
* Added flow-actions pipeline for traffic metering/marking
(for e.g. Two Rate Three Color Marker (trTCM)), policer etc.
* Modified the pass-through pipeline's actions-handler to
implement a generic approach to extract fields from the
- packet's header and copying them to packet metadata.
+ packet's header and copy them to packet metadata.
Resolved Issues
@@ -231,27 +234,26 @@ Drivers
* **e1000/base: Synchronize PHY interface on non-ME systems.**
- On power up, the MAC - PHY interface needs to be set to PCIe, even if
- cable is disconnected. In ME systems, the ME handles this on exit from
- Sx(Sticky mode) state. In non-ME, the driver handles it. Add a check
- for non-ME system to the driver code that handles that.
+ On power up, the MAC - PHY interface needs to be set to PCIe, even if the
+ cable is disconnected. In ME systems, the ME handles this on exit from the
+ Sx (Sticky mode) state. In non-ME, the driver handles it. Added a check for
+ non-ME system to the driver code that handles it.
-* **e1000/base: Increase timeout of reset check.**
+* **e1000/base: Increased timeout of reset check.**
- Previously, in check_reset_block RSPCIPHY was polled for 100 ms before
- determining that the ME veto is set. It's not enough. It need to be increased
- to 300 ms.
+ Previously, in ``check_reset_block`` RSPCIPHY was polled for 100 ms before
+ determining that the ME veto was set. This was not enough and it was
+ increased to 300 ms.
-* **e1000/base: Disable IPv6 extension header parsing on 82575.**
+* **e1000/base: Disabled IPv6 extension header parsing on 82575.**
- Disable IPv6 options as per hardware limitation.
+ Disabled IPv6 options as per hardware limitation.
* **e1000/base: Prevent ULP flow if cable connected.**
- Enabling ulp on link down when cable is connect caused an infinite
- loop of linkup/down indications in the NDIS driver.
- After discussed, correct flow is to enable ULP only when cable is
- disconnected.
+ Enabling ULP on link down when the cable is connected caused an infinite
+ loop of link up/down indications in the NDIS driver.
+ The driver now enables ULP only when the cable is disconnected.
* **e1000/base: Support different EEARBC for i210.**
@@ -259,74 +261,76 @@ Drivers
i210 than on other NICs. So, add a new entity named EEARBC_I210 to the
register list and make sure the right one is being used on i210.
-* **e1000/base: Fix K1 configuration**
+* **e1000/base: Fix K1 configuration.**
- This patch is for the following updates to the K1 configurations:
- Tx idle period for entering K1 should be 128 ns.
- Minimum Tx idle period in K1 should be 256 ns.
+ Added fix for the following updates to the K1 configurations:
+ TX idle period for entering K1 should be 128 ns.
+ Minimum TX idle period in K1 should be 256 ns.
-* **e1000/base: Fix link detect flow**
+* **e1000/base: Fix link detect flow.**
- In case that auto-negotiate is not enabled, call
- e1000_setup_copper_link_generic instead of e1000_phy_setup_autoneg.
+ Fix link detect flow in case where auto-negotiate is not enabled, by calling
+ ``e1000_setup_copper_link_generic`` instead of ``e1000_phy_setup_autoneg``.
-* **e1000/base: Fix link check for i354 M88E1112 PHY**
+* **e1000/base: Fix link check for i354 M88E1112 PHY.**
- e1000_check_for_link_media_swap() is supposed to check PHY page 0 for
- copper and PHY page 1 for "other" (fiber) link. We switched back from
- page 1 to page 0 too soon, before e1000_check_for_link_82575() is
- executed and we were never finding link on fiber (other).
+ The ``e1000_check_for_link_media_swap()`` function is supposed to check PHY
+ page 0 for copper and PHY page 1 for "other" (fiber) links. The driver
+ switched back from page 1 to page 0 too soon, before
+ ``e1000_check_for_link_82575()`` is executed and was never finding the link
+ on the fiber (other).
If the link is copper, as the M88E1112 page address is set to 1, it should be
set back to 0 before checking this link.
-* **e1000/base: Fix beacon duration for i217**
+* **e1000/base: Fix beacon duration for i217.**
Fix for I217 Packet Loss issue - The Management Engine sets the FEXTNVM4
- Beacon Duration incorrectly. This fix ensures that the correct value will
+ Beacon Duration incorrectly. This fix ensures that the correct value will
always be set. Correct value for this field is 8 usec.
-* **e1000/base: Fix TIPG for non 10 half duplex mode**
+* **e1000/base: Fix TIPG for non 10 half duplex mode.**
- TIPG value is increased when setting speed to 10 half to prevent
+ TIPG value is increased when setting speed to 10 half duplex to prevent
packet loss. However, it was never decreased again when speed
- changes. This caused performance issues in the NDIS driver.
- Fix this to restore TIPG to default value on non 10 half.
+ changed. This caused performance issues in the NDIS driver.
+ Fix this to restore TIPG to default value on non 10 half duplex.
-* **e1000/base: Fix reset of DH89XXCC SGMII**
+* **e1000/base: Fix reset of DH89XXCC SGMII.**
- For DH89XXCC_SGMII, write flush leaves registers of this device trashed
+ For DH89XXCC_SGMII, a write flush leaves registers of this device trashed
(0xFFFFFFFF). Add check for this device.
- Also, after both for Port SW Reset and Device Reset case, platform should
- wait at least 3ms before reading any registers. Since waiting is
- conditionally executed only for Device Reset - remove the condition.
-* **e1000/base: Fix redundant PHY power down for i210**
+ Also, after both Port SW Reset and Device Reset case, the platform should
+ wait at least 3ms before reading any registers. Remove this condition since
+ waiting is conditionally executed only for Device Reset.
+
+* **e1000/base: Fix redundant PHY power down for i210.**
Bit 11 of PHYREG 0 is used to power down PHY. The use of PHYREG 16 is
- unnecessary any more.
+ no longer necessary.
-* **e1000/base: fix jumbo frame CRC failures**
+* **e1000/base: fix jumbo frame CRC failures.**
Change the value of register 776.20[11:2] for jumbo mode from 0x1A to 0x1F.
- This is to enlarge the gap between read and write pointers in the TX Fifo.
- And replace the magic number with a macro by the way.
+ This is to enlarge the gap between read and write pointers in the TX FIFO.
-* **e1000/base: Fix link flap on 82579**
+* **e1000/base: Fix link flap on 82579.**
Several customers have reported a link flap issue on 82579. The symptoms
are random and intermittent link losses when 82579 is connected to specific
- switches. Issue has been root caused as interoperability problem between
+ switches. the Issue was root caused as an inter-operability problem between
the NIC and at least some Broadcom PHYs in the Energy Efficient Ethernet
wake mechanism.
+
To fix the issue, we are disabling the Phase Locked Loop shutdown in 100M
Low Power Idle. This solution will cause an increase of power in 100M EEE
- link. It may cost additional 28mW in this specific mode.
+ link. It may cost an additional 28mW in this specific mode.
* **igb: Fixed IEEE1588 frame identification in I210.**
- Fixed issue where the flag PKT_RX_IEEE1588_PTP was not being set
- in Intel I210 NIC, as EtherType in RX descriptor is in bits 8:10 of
+ Fixed issue where the flag ``PKT_RX_IEEE1588_PTP`` was not being set
+ in the Intel I210 NIC, as the EtherType in RX descriptor is in bits 8:10 of
Packet Type and not in the default bits 0:2.
* **igb: Fixed VF start with PF stopped.**
@@ -353,10 +357,9 @@ Drivers
* **ixgbe: Fixed TX hang when RS distance exceeds HW limit.**
- Fixed an issue when TX queue can hang when a lot of highly fragmented
- packets have to be sent.
- As part of that fix, tx_rs_thresh for ixgbe PMD is not allowed to be greater
- then to 32 to comply with HW restrictions.
+ Fixed an issue where the TX queue can hang when a lot of highly fragmented
+ packets have to be sent. As part of that fix, ``tx_rs_thresh`` for ixgbe PMD
+ is not allowed to be greater then to 32 to comply with HW restrictions.
* **i40e: Fixed base driver allocation when not using first numa node.**
@@ -365,10 +368,10 @@ Drivers
* **i40e: Fixed maximum of 64 queues per port.**
- Fixed the issue in i40e of cannot supporting more than 64 queues per port,
- though hardware actually supports that. The real number of queues may vary,
- as long as the total number of queues used in PF, VFs, VMDq and FD does not
- exceeds the hardware maximum.
+ Fixed an issue in i40e where it would not support more than 64 queues per
+ port, even though the hardware actually supports it. The real number of
+ queues may vary, as long as the total number of queues used in PF, VFs, VMDq
+ and FD does not exceeds the hardware maximum.
* **i40e: Fixed statistics of packets.**
@@ -376,21 +379,21 @@ Drivers
* **i40e: Fixed issue of not freeing memzone.**
- Fixed the issue of not freeing memzone in the call to free the memory for
+ Fixed an issue of not freeing a memzone in the call to free the memory for
adminq DMA.
* **mlx: Fixed driver loading.**
The mlx drivers were unable to load when built as a shared library,
- due to a missing symbol in mempool library.
+ due to a missing symbol in the mempool library.
* **mlx4: Performance improvements.**
Fixed bugs in TX and RX flows that improves mlx4 performance.
-* **mlx4: Fixed Tx loss after initialization.**
+* **mlx4: Fixed TX loss after initialization.**
-* **mlx4: Fixed scattered Tx with too many segments.**
+* **mlx4: Fixed scattered TX with too many segments.**
* **mlx4: Fixed memory registration for indirect mbuf data.**
@@ -400,7 +403,7 @@ Drivers
* **virtio: Fixed crash after changing link state.**
- Fixed io permission in the interrupt handler.
+ Fixed IO permission in the interrupt handler.
* **virtio: Fixed crash when releasing queue.**
@@ -418,12 +421,12 @@ Libraries
* **hash: Fixed incorrect lookup if key is all zero.**
Fixed issue in hash library that occurred if an all zero
- key was not added in the table and the key was looked up,
+ key was not added to the table and the key was looked up,
resulting in an incorrect hit.
* **hash: Fixed thread scaling by reducing contention.**
- Fixed issue in hash library where, using multiple cores with
+ Fixed issue in the hash library where, using multiple cores with
hardware transactional memory support, thread scaling did not work,
due to the global ring that is shared by all cores.
@@ -446,23 +449,23 @@ Other
Known Issues
------------
-* Some drivers do not fill the packet type when receiving.
+* Some drivers do not fill in the packet type when receiving.
As the l3fwd example application requires this info, the i40e vector
driver must be disabled to benefit of the packet type with i40e.
* Some (possibly all) VF drivers (e.g. i40evf) do not handle any PF reset
- events/requests in VF driver, that means VF driver may not work after a
- PF reset in host side. The workaround is to avoid triggering any PF reset
- events/requests on host side.
+ events/requests in the VF driver. This means that the VF driver may not work
+ after a PF reset in the host side. The workaround is to avoid triggering any
+ PF reset events/requests on the host side.
-* **Mellanox PMDs (mlx4 & mlx5):**
+* **Mellanox PMDs (mlx4 & mlx5):.**
* PMDs do not support DPDK integrated shared library.
- * There is performance degradation for small packets when PMD
- is compiled with SGE_WR_N = 4 compared to the performance when SGE_WR_N = 1.
- If scattered packets are not used it is recomended
- to compile PMD with SGE_WR_N = 1.
+ * There is performance degradation for small packets when the PMD is
+ compiled with ``SGE_WR_N = 4`` compared to the performance when ``SGE_WR_N
+ = 1``. If scattered packets are not used it is recommended to compile the
+ PMD with ``SGE_WR_N = 1``.
* When a Multicast or Broadcast packet is sent to the SR-IOV mlx4 VF,
it is returned back to the port.
@@ -472,87 +475,91 @@ API Changes
-----------
* The deprecated flow director API is removed.
- It was replaced by rte_eth_dev_filter_ctrl().
+ It was replaced by ``rte_eth_dev_filter_ctrl()``.
-* The dcb_queue is renamed to dcb_tc in following dcb configuration
- structures: rte_eth_dcb_rx_conf, rte_eth_dcb_tx_conf,
- rte_eth_vmdq_dcb_conf, rte_eth_vmdq_dcb_tx_conf.
+* The ``dcb_queue`` is renamed to ``dcb_tc`` in following dcb configuration
+ structures: ``rte_eth_dcb_rx_conf``, ``rte_eth_dcb_tx_conf``,
+ ``rte_eth_vmdq_dcb_conf``, ``rte_eth_vmdq_dcb_tx_conf``.
-* The rte_eth_rx_queue_count() function now returns "int" instead of "uint32_t"
- to allow the use of negative values as error codes on return.
+* The ``rte_eth_rx_queue_count()`` function now returns "int" instead of
+ "uint32_t" to allow the use of negative values as error codes on return.
-* The function rte_eal_pci_close_one() is removed.
- It was replaced by rte_eal_pci_detach().
+* The function ``rte_eal_pci_close_one()`` is removed.
+ It was replaced by ``rte_eal_pci_detach()``.
-* The deprecated ACL API ipv4vlan is removed.
+* The deprecated ACL API ``ipv4vlan`` is removed.
-* The deprecated hash function rte_jhash2() is removed.
- It was replaced by rte_jhash_32b().
+* The deprecated hash function ``rte_jhash2()`` is removed.
+ It was replaced by ``rte_jhash_32b()``.
* The deprecated KNI functions are removed:
- rte_kni_create(), rte_kni_get_port_id() and rte_kni_info_get().
+ ``rte_kni_create()``, ``rte_kni_get_port_id()`` and ``rte_kni_info_get()``.
* The deprecated ring PMD functions are removed:
- rte_eth_ring_pair_create() and rte_eth_ring_pair_attach().
+ ``rte_eth_ring_pair_create()`` and ``rte_eth_ring_pair_attach()``.
+
+* The devargs union field ``virtual`` is renamed to ``virt`` for C++
+ compatibility.
-* The devargs union field virtual is renamed to virt for C++ compatibility.
ABI Changes
-----------
-* The EAL and ethdev structures rte_intr_handle and rte_eth_conf were changed
- to support Rx interrupt. It was already done in 2.1 for CONFIG_RTE_NEXT_ABI.
+* The EAL and ethdev structures ``rte_intr_handle`` and ``rte_eth_conf`` were
+ changed to support RX interrupt. This was already included in 2.1 under the
+ ``CONFIG_RTE_NEXT_ABI`` #define.
* The ethdev flow director entries for SCTP were changed.
- It was already done in 2.1 for CONFIG_RTE_NEXT_ABI.
+ This was already included in 2.1 under the ``CONFIG_RTE_NEXT_ABI`` #define.
-* The ethdev flow director structure rte_eth_fdir_flow_ext structure is changed.
- New fields are added to support flow director filtering in VF.
+* The ethdev flow director structure ``rte_eth_fdir_flow_ext`` structure was
+ changed. New fields were added to support flow director filtering in VF.
-* The size of the ethdev structure rte_eth_hash_filter_info is changed
- by adding a new element rte_eth_input_set_conf in an union.
+* The size of the ethdev structure ``rte_eth_hash_filter_info`` is changed
+ by adding a new element ``rte_eth_input_set_conf`` in a union.
-* The new fields rx_desc_lim and tx_desc_lim are added into rte_eth_dev_info
- structure.
+* New fields ``rx_desc_lim`` and ``tx_desc_lim`` are added into
+ ``rte_eth_dev_info`` structure.
-* For debug builds, the functions rte_eth_rx_burst(), rte_eth_tx_burst()
- rte_eth_rx_descriptor_done() and rte_eth_rx_queue_count() will
+* For debug builds, the functions ``rte_eth_rx_burst()``, ``rte_eth_tx_burst()``
+ ``rte_eth_rx_descriptor_done()`` and ``rte_eth_rx_queue_count()`` will
no longer be separate functions in the DPDK libraries. Instead, they will
- only be present in the rte_ethdev.h header file.
+ only be present in the ``rte_ethdev.h`` header file.
-* The maximum number of queues per port CONFIG_RTE_MAX_QUEUES_PER_PORT is
+* The maximum number of queues per port ``CONFIG_RTE_MAX_QUEUES_PER_PORT`` is
increased to 1024.
-* The mbuf structure was changed to support unified packet type.
- It was already done in 2.1 for CONFIG_RTE_NEXT_ABI.
+* The mbuf structure was changed to support the unified packet type.
+ This was already included in 2.1 under the ``CONFIG_RTE_NEXT_ABI`` #define.
* The dummy malloc library is removed. The content was moved into EAL in 2.1.
-* The LPM structure is changed. The deprecated field mem_location is removed.
+* The LPM structure is changed. The deprecated field ``mem_location`` is
+ removed.
* librte_table LPM: A new parameter to hold the table name will be added to
the LPM table parameter structure.
* librte_table hash: The key mask parameter is added to the hash table
- parameter structure for 8-byte key and 16-byte key extendible bucket
+ parameter structure for 8-byte key and 16-byte key extendable bucket
and LRU tables.
* librte_port: Macros to access the packet meta-data stored within the packet
buffer has been adjusted to cover the packet mbuf structure.
* librte_cfgfile: Allow longer names and values by increasing the constants
- CFG_NAME_LEN and CFG_VALUE_LEN to 64 and 256 respectively.
+ ``CFG_NAME_LEN`` and ``CFG_VALUE_LEN`` to 64 and 256 respectively.
-* vhost: a new field enabled is added to the vhost_virtqueue structure.
+* vhost: a new field enabled is added to the ``vhost_virtqueue`` structure.
-* vhost: a new field virt_qp_nb is added to virtio_net structure, and the
- virtqueue field is moved to the end of virtio_net structure.
+* vhost: a new field ``virt_qp_nb`` is added to ``virtio_net`` structure, and
+ the ``virtqueue`` field is moved to the end of virtio_net structure.
-* vhost: a new operation vring_state_changed is added to virtio_net_device_ops
- structure.
+* vhost: a new operation ``vring_state_changed`` is added to
+ ``virtio_net_device_ops`` structure.
-* vhost: a few spaces are reserved both at vhost_virtqueue and virtio_net
- structure for future extension.
+* vhost: a few spaces are reserved both at ``vhost_virtqueue`` and
+ ``virtio_net`` structure for future extension.
Shared Library Versions
--
2.5.0
^ permalink raw reply [relevance 1%]
* [dpdk-dev] Draft release notes for 2.2
@ 2015-12-14 18:54 1% Mcnamara, John
0 siblings, 0 replies; 200+ results
From: Mcnamara, John @ 2015-12-14 18:54 UTC (permalink / raw)
To: dev
Hi,
Below is the draft release notes for DPDK 2.2. Please scan them for corrections and/or omissions.
John
DPDK Release 2.2
================
New Features
------------
* **Introduce ARMv7 and ARMv8 architectures.**
* It is now possible to build DPDK for the ARMv7 and ARMv8 platforms.
* ARMv7 can be tested with virtual PMD drivers.
* ARMv8 can be tested with virtual and physical PMD drivers.
* **Enabled freeing of ring.**
A new function ``rte_ring_free()`` has been added to allow the user to free
a ring if it was created with ``rte_ring_create()``.
* **Added keepalive support to EAL and example application.**
* **Added experimental cryptodev API**
The cryptographic processing of packets is provided as a preview
with two drivers for:
* Intel QuickAssist devices
* Intel AES-NI multi-buffer library
Due to its experimental state, the API may change without prior notice.
* **Added ethdev APIs for additional IEEE1588 support.**
Added functions to read, write and adjust system time in the NIC.
Added client slave sample application to demonstrate the IEEE1588
functionality.
* **Extended Statistics.**
Defined an extended statistics naming scheme to store metadata in the name
string of each statistic. Refer to the Extended Statistics section of the
Programmers Guide for more details.
Implemented the extended statistics API for the following PMDs:
* ``igb``
* ``igbvf``
* ``i40e``
* ``i40evf``
* ``fm10k``
* ``virtio``
* **Added API in ethdev to retrieve RX/TX queue information.**
* Added the ability for the upper layer to query RX/TX queue information.
* Added new fields in ``rte_eth_dev_info`` to represent information about
RX/TX descriptors min/max/align numbers, per queue, for the device.
* **Added RSS dynamic configuration to bonding.**
* **Updated the e1000 base driver.**
The e1000 base driver was updated with several features including the
following:
* Added new i218 devices
* Allowed both ULP and EEE in Sx state
* Initialized 88E1543 (Marvell 1543) PHY
* Added flags to set EEE advertisement modes
* Supported inverted format ETrackId
* Added bit to disable packetbuffer read
* Added defaults for i210 RX/TX PBSIZE
* Check more errors for ESB2 init and reset
* Check more NVM read errors
* Return code after setting receive address register
* Removed all NAHUM6LP_HW tags
* **Added e1000 RX interrupt support.**
* **Added igb TSO support for both PF and VF.**
* **Added RSS enhancements to Intel x550 NIC.**
* Added support for 512 entry RSS redirection table.
* Added support for per VF RSS redirection table.
* **Added Flow director enhancements on Intel x550 NIC.**
* Added 2 new flow director modes on x550.
One is MAC VLAN mode, the other is tunnel mode.
* **Updated the i40e base driver.**
The i40e base driver was updated with several changes including the
following:
* Added promiscuous on VLAN support
* Added a workaround to drop all flow control frames
* Added VF capabilities to virtual channel interface
* Added TX Scheduling related AQ commands
* Added additional PCTYPES supported for FortPark RSS
* Added parsing for CEE DCBX TLVs
* Added FortPark specific registers
* Added AQ functions to handle RSS Key and LUT programming
* Increased PF reset max loop limit
* **Added i40e vector RX/TX.**
* **Added i40e RX interrupt support.**
* **Added i40e flow control support.**
* **Added DCB support to i40e PF driver.**
* **Added RSS/FD input set granularity on Intel X710/XL710.**
* **Added different GRE key length for input set on Intel X710/XL710.**
* **Added flow director support in i40e VF.**
* **Added i40e support of early X722 series.**
Added early X722 support, for evaluation only, as the hardware is alpha.
* **Added fm10k vector RX/TX.**
* **Added fm10k TSO support for both PF and VF.**
* **Added fm10k VMDQ support.**
* **New NIC Boulder Rapid support.**
Added support for the Boulder Rapid variant of Intel's fm10k NIC family.
* **Enhanced support for the Chelsio CXGBE driver.**
* Added support for Jumbo Frames.
* Optimized forwarding performance for Chelsio T5 40GbE cards.
* **Improved enic TX packet rate.**
Reduced frequency of TX tail pointer updates to the NIC.
* **Added support for link status interrupts in mlx4.**
* **Added partial support (TX only) for secondary processes in mlx4.**
* **Added support for Mellanox ConnectX-4 adapters (mlx5).**
The mlx5 poll-mode driver implements support for Mellanox ConnectX-4 EN
and Mellanox ConnectX-4 Lx EN families of 10/25/40/50/100 Gb/s adapters.
Like mlx4, this PMD is only available for Linux and is disabled by default
due to external dependencies (libibverbs and libmlx5).
* **Added driver for Netronome nfp-6xxx card.**
Support for using Netronome nfp-6xxx with PCI VFs.
* **Added virtual szedata2 driver for COMBO cards.**
Added virtual PMD for COMBO-100G and COMBO-80G cards.
PMD is disabled in default configuration.
* **Enhanced support for virtio driver.**
* Virtio ring layout optimization (fixed avail ring)
* Vector RX
* Simple TX
* **Added vhost-user multiple queue support.**
* **Added port hotplug support to vmxnet3.**
* **Added port hotplug support to xenvirt.**
* **Added ethtool shim and sample application.**
* **Added experimental performance thread example application.**
The new sample application demonstrates L3 forwarding with different threading
models: pthreads, cgroups, or lightweight threads. The example includes
a simple cooperative scheduler.
Due to its experimental state this application may change without notice.
The application is supported only for Linux x86_64.
* **Enhancements to the IP pipeline application.**
The following features have been added to the ``ip_pipeline``
application;
* Added Multiple Producers/Multiple Consumers (MPSC)
and fragmentation/reassembly support to software rings.
* Added a dynamic pipeline reconfiguration feature that
allows binding a pipeline to other threads at runtime
using CLI commands.
* Added enable/disable of ``promisc`` mode from ``ip_pipeline``
configuration file.
* Added check on RX queues and TX queues of each link
whether they are used correctly in the ``ip_pipeline``
configuration file.
* Added flow id parameters to the flow-classification
table entries.
* Added more functions to the routing pipeline:
ARP table enable/disable, Q-in-Q and MPLS encapsulation,
add color (traffic-class for QoS) to the MPLS tag.
* Added flow-actions pipeline for traffic metering/marking
(for e.g. Two Rate Three Color Marker (trTCM)), policer etc.
* Modified the pass-through pipeline's actions-handler to
implement a generic approach to extract fields from the
packet's header and copy them to packet metadata.
Resolved Issues
---------------
EAL
~~~
* **eal/linux: Fixed epoll timeout.**
Fixed issue where the ``rte_epoll_wait()`` function didn't return when the
underlying call to ``epoll_wait()`` timed out.
Drivers
~~~~~~~
* **e1000/base: Synchronize PHY interface on non-ME systems.**
On power up, the MAC - PHY interface needs to be set to PCIe, even if the
cable is disconnected. In ME systems, the ME handles this on exit from the
Sx (Sticky mode) state. In non-ME, the driver handles it. Added a check for
non-ME system to the driver code that handles it.
* **e1000/base: Increased timeout of reset check.**
Previously, in ``check_reset_block`` RSPCIPHY was polled for 100 ms before
determining that the ME veto was set. This was not enough and it was
increased to 300 ms.
* **e1000/base: Disabled IPv6 extension header parsing on 82575.**
Disabled IPv6 options as per hardware limitation.
* **e1000/base: Prevent ULP flow if cable connected.**
Enabling ULP on link down when the cable is connected caused an infinite
loop of link up/down indications in the NDIS driver.
The driver now enables ULP only when the cable is disconnected.
* **e1000/base: Support different EEARBC for i210.**
EEARBC has changed on i210. It means EEARBC has a different address on
i210 than on other NICs. So, add a new entity named EEARBC_I210 to the
register list and make sure the right one is being used on i210.
* **e1000/base: Fix K1 configuration.**
Added fix for the following updates to the K1 configurations:
TX idle period for entering K1 should be 128 ns.
Minimum TX idle period in K1 should be 256 ns.
* **e1000/base: Fix link detect flow.**
Fix link detect flow in case where auto-negotiate is not enabled, by calling
``e1000_setup_copper_link_generic`` instead of ``e1000_phy_setup_autoneg``.
* **e1000/base: Fix link check for i354 M88E1112 PHY.**
The ``e1000_check_for_link_media_swap()`` function is supposed to check PHY
page 0 for copper and PHY page 1 for "other" (fiber) links. The driver
switched back from page 1 to page 0 too soon, before
``e1000_check_for_link_82575()`` is executed and was never finding the link
on the fiber (other).
If the link is copper, as the M88E1112 page address is set to 1, it should be
set back to 0 before checking this link.
* **e1000/base: Fix beacon duration for i217.**
Fix for I217 Packet Loss issue - The Management Engine sets the FEXTNVM4
Beacon Duration incorrectly. This fix ensures that the correct value will
always be set. Correct value for this field is 8 usec.
* **e1000/base: Fix TIPG for non 10 half duplex mode.**
TIPG value is increased when setting speed to 10 half duplex to prevent
packet loss. However, it was never decreased again when speed
changed. This caused performance issues in the NDIS driver.
Fix this to restore TIPG to default value on non 10 half duplex.
* **e1000/base: Fix reset of DH89XXCC SGMII.**
For DH89XXCC_SGMII, a write flush leaves registers of this device trashed
(0xFFFFFFFF). Add check for this device.
Also, after both Port SW Reset and Device Reset case, the platform should
wait at least 3ms before reading any registers. Remove this condition since
waiting is conditionally executed only for Device Reset.
* **e1000/base: Fix redundant PHY power down for i210.**
Bit 11 of PHYREG 0 is used to power down PHY. The use of PHYREG 16 is
no longer necessary.
* **e1000/base: fix jumbo frame CRC failures.**
Change the value of register 776.20[11:2] for jumbo mode from 0x1A to 0x1F.
This is to enlarge the gap between read and write pointers in the TX FIFO.
* **e1000/base: Fix link flap on 82579.**
Several customers have reported a link flap issue on 82579. The symptoms
are random and intermittent link losses when 82579 is connected to specific
switches. the Issue was root caused as an inter-operability problem between
the NIC and at least some Broadcom PHYs in the Energy Efficient Ethernet
wake mechanism.
To fix the issue, we are disabling the Phase Locked Loop shutdown in 100M
Low Power Idle. This solution will cause an increase of power in 100M EEE
link. It may cost an additional 28mW in this specific mode.
* **igb: Fixed IEEE1588 frame identification in I210.**
Fixed issue where the flag ``PKT_RX_IEEE1588_PTP`` was not being set
in the Intel I210 NIC, as the EtherType in RX descriptor is in bits 8:10 of
Packet Type and not in the default bits 0:2.
* **igb: Fixed VF start with PF stopped.**
VF needs the PF interrupt support initialized even if not started.
* **igb: Fixed VF MAC address when using with DPDK PF.**
Assign a random MAC address in VF when not assigned by PF.
* **ixgbe: Fixed issue with X550 DCB.**
Fixed a DCB issue with x550 where for 8 TCs (Traffic Classes), if a packet
with user priority 6 or 7 was injected to the NIC, then the NIC would only
put 3 packets into the queue. There was also a similar issue for 4 TCs.
* **ixgbe: Removed burst size restriction of vector RX.**
Fixed issue where a burst size less than 32 didn't receive anything.
* **ixgbe: Fixed VF start with PF stopped.**
VF needs the PF interrupt support initialized even if not started.
* **ixgbe: Fixed TX hang when RS distance exceeds HW limit.**
Fixed an issue where the TX queue can hang when a lot of highly fragmented
packets have to be sent. As part of that fix, ``tx_rs_thresh`` for ixgbe PMD
is not allowed to be greater then to 32 to comply with HW restrictions.
* **i40e: Fixed base driver allocation when not using first numa node.**
Fixed i40e issue that occurred when a DPDK application didn't initialize
ports if memory wasn't available on socket 0.
* **i40e: Fixed maximum of 64 queues per port.**
Fixed an issue in i40e where it would not support more than 64 queues per
port, even though the hardware actually supports it. The real number of
queues may vary, as long as the total number of queues used in PF, VFs, VMDq
and FD does not exceeds the hardware maximum.
* **i40e: Fixed statistics of packets.**
Added discarding packets on VSI to the stats and rectify the old statistics.
* **i40e: Fixed issue of not freeing memzone.**
Fixed an issue of not freeing a memzone in the call to free the memory for
adminq DMA.
* **mlx: Fixed driver loading.**
The mlx drivers were unable to load when built as a shared library,
due to a missing symbol in the mempool library.
* **mlx4: Performance improvements.**
Fixed bugs in TX and RX flows that improves mlx4 performance.
* **mlx4: Fixed TX loss after initialization.**
* **mlx4: Fixed scattered TX with too many segments.**
* **mlx4: Fixed memory registration for indirect mbuf data.**
* **vhost: Fixed Qemu shutdown.**
Fixed issue with libvirt ``virsh destroy`` not killing the VM.
* **virtio: Fixed crash after changing link state.**
Fixed IO permission in the interrupt handler.
* **virtio: Fixed crash when releasing queue.**
Fixed issue when releasing null control queue.
Libraries
~~~~~~~~~
* **hash: Fixed memory allocation of Cuckoo Hash key table.**
Fixed issue where an incorrect Cuckoo Hash key table size could be
calculated limiting the size to 4GB.
* **hash: Fixed incorrect lookup if key is all zero.**
Fixed issue in hash library that occurred if an all zero
key was not added to the table and the key was looked up,
resulting in an incorrect hit.
* **hash: Fixed thread scaling by reducing contention.**
Fixed issue in the hash library where, using multiple cores with
hardware transactional memory support, thread scaling did not work,
due to the global ring that is shared by all cores.
Examples
~~~~~~~~
* **l3fwd: Fixed crash with IPv6.**
* **vhost_xen: Fixed compile error.**
Other
~~~~~
* This release drops compatibility with Linux kernel 2.6.33. The minimum
kernel requirement is now 2.6.34.
Known Issues
------------
* Some drivers do not fill in the packet type when receiving.
As the l3fwd example application requires this info, the i40e vector
driver must be disabled to benefit of the packet type with i40e.
* Some (possibly all) VF drivers (e.g. i40evf) do not handle any PF reset
events/requests in the VF driver. This means that the VF driver may not work
after a PF reset in the host side. The workaround is to avoid triggering any
PF reset events/requests on the host side.
* **Mellanox PMDs (mlx4 & mlx5):.**
* PMDs do not support DPDK integrated shared library.
* There is performance degradation for small packets when the PMD is
compiled with ``SGE_WR_N = 4`` compared to the performance when ``SGE_WR_N
= 1``. If scattered packets are not used it is recommended to compile the
PMD with ``SGE_WR_N = 1``.
* When a Multicast or Broadcast packet is sent to the SR-IOV mlx4 VF,
it is returned back to the port.
API Changes
-----------
* The deprecated flow director API is removed.
It was replaced by ``rte_eth_dev_filter_ctrl()``.
* The ``dcb_queue`` is renamed to ``dcb_tc`` in following dcb configuration
structures: ``rte_eth_dcb_rx_conf``, ``rte_eth_dcb_tx_conf``,
``rte_eth_vmdq_dcb_conf``, ``rte_eth_vmdq_dcb_tx_conf``.
* The ``rte_eth_rx_queue_count()`` function now returns "int" instead of
"uint32_t" to allow the use of negative values as error codes on return.
* The function ``rte_eal_pci_close_one()`` is removed.
It was replaced by ``rte_eal_pci_detach()``.
* The deprecated ACL API ``ipv4vlan`` is removed.
* The deprecated hash function ``rte_jhash2()`` is removed.
It was replaced by ``rte_jhash_32b()``.
* The deprecated KNI functions are removed:
``rte_kni_create()``, ``rte_kni_get_port_id()`` and ``rte_kni_info_get()``.
* The deprecated ring PMD functions are removed:
``rte_eth_ring_pair_create()`` and ``rte_eth_ring_pair_attach()``.
* The devargs union field ``virtual`` is renamed to ``virt`` for C++
compatibility.
ABI Changes
-----------
* The EAL and ethdev structures ``rte_intr_handle`` and ``rte_eth_conf`` were
changed to support RX interrupt. This was already included in 2.1 under the
``CONFIG_RTE_NEXT_ABI`` #define.
* The ethdev flow director entries for SCTP were changed.
This was already included in 2.1 under the ``CONFIG_RTE_NEXT_ABI`` #define.
* The ethdev flow director structure ``rte_eth_fdir_flow_ext`` structure was
changed. New fields were added to support flow director filtering in VF.
* The size of the ethdev structure ``rte_eth_hash_filter_info`` is changed
by adding a new element ``rte_eth_input_set_conf`` in a union.
* New fields ``rx_desc_lim`` and ``tx_desc_lim`` are added into
``rte_eth_dev_info`` structure.
* For debug builds, the functions ``rte_eth_rx_burst()``, ``rte_eth_tx_burst()``
``rte_eth_rx_descriptor_done()`` and ``rte_eth_rx_queue_count()`` will
no longer be separate functions in the DPDK libraries. Instead, they will
only be present in the ``rte_ethdev.h`` header file.
* The maximum number of queues per port ``CONFIG_RTE_MAX_QUEUES_PER_PORT`` is
increased to 1024.
* The mbuf structure was changed to support the unified packet type.
This was already included in 2.1 under the ``CONFIG_RTE_NEXT_ABI`` #define.
* The dummy malloc library is removed. The content was moved into EAL in 2.1.
* The LPM structure is changed. The deprecated field ``mem_location`` is
removed.
* librte_table LPM: A new parameter to hold the table name will be added to
the LPM table parameter structure.
* librte_table hash: The key mask parameter is added to the hash table
parameter structure for 8-byte key and 16-byte key extendable bucket
and LRU tables.
* librte_port: Macros to access the packet meta-data stored within the packet
buffer has been adjusted to cover the packet mbuf structure.
* librte_cfgfile: Allow longer names and values by increasing the constants
``CFG_NAME_LEN`` and ``CFG_VALUE_LEN`` to 64 and 256 respectively.
* vhost: a new field enabled is added to the ``vhost_virtqueue`` structure.
* vhost: a new field ``virt_qp_nb`` is added to ``virtio_net`` structure, and
the ``virtqueue`` field is moved to the end of virtio_net structure.
* vhost: a new operation ``vring_state_changed`` is added to
``virtio_net_device_ops`` structure.
* vhost: a few spaces are reserved both at ``vhost_virtqueue`` and
``virtio_net`` structure for future extension.
Shared Library Versions
-----------------------
The libraries prepended with a plus sign were incremented in this version.
.. code-block:: diff
+ libethdev.so.2
+ librte_acl.so.2
+ librte_cfgfile.so.2
librte_cmdline.so.1
librte_distributor.so.1
+ librte_eal.so.2
+ librte_hash.so.2
librte_ip_frag.so.1
librte_ivshmem.so.1
librte_jobstats.so.1
+ librte_kni.so.2
librte_kvargs.so.1
+ librte_lpm.so.2
+ librte_mbuf.so.2
librte_mempool.so.1
librte_meter.so.1
+ librte_pipeline.so.2
librte_pmd_bond.so.1
+ librte_pmd_ring.so.2
+ librte_port.so.2
librte_power.so.1
librte_reorder.so.1
librte_ring.so.1
librte_sched.so.1
+ librte_table.so.2
librte_timer.so.1
+ librte_vhost.so.2
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v2] doc: add contributors guide
@ 2015-12-14 20:32 2% ` John McNamara
2015-12-14 20:45 2% ` [dpdk-dev] [PATCH v5] " John McNamara
1 sibling, 0 replies; 200+ results
From: John McNamara @ 2015-12-14 20:32 UTC (permalink / raw)
To: dev
Add a document to explain the DPDK patch submission and review process.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
---
v2:
* Added references to new checkpatches.sh and test-build.sh scripts
as per Thomas' suggestion on the mailing list.
doc/guides/contributing/documentation.rst | 2 +-
doc/guides/contributing/index.rst | 1 +
doc/guides/contributing/patches.rst | 389 ++++++++++++++++++++++++++++++
3 files changed, 391 insertions(+), 1 deletion(-)
create mode 100644 doc/guides/contributing/patches.rst
diff --git a/doc/guides/contributing/documentation.rst b/doc/guides/contributing/documentation.rst
index 6dfaaa8..ba5c4de 100644
--- a/doc/guides/contributing/documentation.rst
+++ b/doc/guides/contributing/documentation.rst
@@ -1,4 +1,4 @@
-.. doc_guidelines:
+.. _doc_guidelines:
DPDK Documentation Guidelines
=============================
diff --git a/doc/guides/contributing/index.rst b/doc/guides/contributing/index.rst
index 561427b..f49ca88 100644
--- a/doc/guides/contributing/index.rst
+++ b/doc/guides/contributing/index.rst
@@ -9,3 +9,4 @@ Contributor's Guidelines
design
versioning
documentation
+ patches
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
new file mode 100644
index 0000000..1729c6b
--- /dev/null
+++ b/doc/guides/contributing/patches.rst
@@ -0,0 +1,389 @@
+.. submitting_patches:
+
+Contributing Code to DPDK
+=========================
+
+This document outlines the guidelines for submitting code to DPDK.
+
+The DPDK development process is modeled (loosely) on the Linux Kernel development model so it is worth reading the
+Linux kernel guide on submitting patches:
+`How to Get Your Change Into the Linux Kernel <http://www.kernel.org/doc/Documentation/SubmittingPatches>`_.
+The rationale for many of the DPDK guidelines is explained in greater detail in the kernel guidelines.
+
+
+The DPDK Development Process
+-----------------------------
+
+The DPDK development process has the following features:
+
+* The code is hosted in a public git repository.
+* There is a mailing list where developers submit patches.
+* There are maintainers for hierarchical components.
+* Patches are reviewed publicly on the mailing list.
+* Successfully reviewed patches are merged to the master branch of the repository.
+
+The mailing list for DPDK development is `dev@dpkg.org <http://dpdk.org/ml/archives/dev/>`_.
+Contributors will need to `register for the mailing list <http://dpdk.org/ml/listinfo/dev>`_ in order to submit patches.
+It is also worth registering for the DPDK `Patchwork <http://dpdk.org/dev/patchwxispork/project/dpdk/list/>`_
+
+The development process requires some familiarity with the ``git`` version control system.
+Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further information.
+
+
+Getting the Source Code
+-----------------------
+
+The source code can be cloned using either of the following::
+
+ git clone git://dpdk.org/dpdk
+
+ git clone http://dpdk.org/git/dpdk
+
+
+Make your Changes
+-----------------
+
+Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines and requirements:
+
+* Follow the :ref:`coding_style` guidelines.
+
+* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+
+* New external functions should be added to the local ``version.map`` file.
+ See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
+ New external functions should also be added in alphabetical order.
+
+* Important changes will require an addition to the release notes in ``doc/guides/rel_notes/``.
+ See the :ref:`Release Notes section of the Documentation Guidelines <doc_guidelines>` for details.
+
+* Test the compilation works with different targets, compilers and options, see :ref:`contrib_check_compilation`.
+
+* Don't break compilation between commits with forward dependencies in a patchset.
+ Each commit should compile on its own to allow for ``git bisect`` and continuous integration testing.
+
+* Add tests to the the ``app/test`` unit test framework where possible.
+
+* Add documentation, if relevant, in the form of Doxygen comments or a User Guide in RST format.
+ See the :ref:`Documentation Guidelines <doc_guidelines>`.
+
+Once the changes have been made you should commit them to your local repo.
+
+For small changes, that do not require specific explanations, it is better to keep things together in the
+same patch.
+Larger changes that require different explanations should be separated into logical patches in a patchset.
+A good way of thinking about whether a patch should be split is to consider whether the change could be
+applied without dependencies as a backport.
+
+As a guide to how patches should be structured run ``git log`` on similar files.
+
+
+Commit Messages: Subject Line
+-----------------------------
+
+The first, summary, line of the git commit message becomes the subject line of the patch email.
+Here are some guidelines for the summary line:
+
+* The summary line must capture the area and the impact of the change.
+
+* The summary line should be around 50 characters.
+
+* The summary line should be lowercase apart from acronyms.
+
+* It should be prefixed with the component name (use git log to check existing components).
+ For example::
+
+ ixgbe: fix offload config option name
+
+ config: increase max queues per port
+
+* Use the imperative of the verb (like instructions to the code base).
+
+* Don't add a period/full stop to the subject line or you will end up two in the patch name: ``dpdk_description..patch``.
+
+The actual email subject line should be prefixed by ``[PATCH]`` and the version, if greater than v1,
+for example: ``PATCH v2``.
+The is generally added by ``git send-email`` or ``git format-patch``, see below.
+
+If you are submitting an RFC draft of a feature you can use ``[RFC]`` instead of ``[PATCH]``.
+An RFC patch doesn't have to be complete.
+It is intended as a way of getting early feedback.
+
+
+Commit Messages: Body
+---------------------
+
+Here are some guidelines for the body of a commit message:
+
+* The body of the message should describe the issue being fixed or the feature being added.
+ It is important to provide enough information to allow a reviewer to understand the purpose of the patch.
+
+* When the change is obvious the body can be blank, apart from the signoff.
+
+* The commit message must end with a ``Signed-off-by:`` line which is added using::
+
+ git commit --signoff # or -s
+
+ The purpose of the signoff is explained in the
+ `Developer's Certificate of Origin <http://www.kernel.org/doc/Documentation/SubmittingPatches>`_
+ section of the Linux kernel guidelines.
+
+ .. Note::
+
+ All developers must ensure that they have read and understood the
+ Developer's Certificate of Origin section of the documentation prior
+ to applying the signoff and submitting a patch.
+
+* The signoff must be a real name and not an alias or nickname.
+ More than one signoff is allowed.
+
+* The text of the commit message should be wrapped at 72 characters.
+
+* When fixing a regression, it is a good idea to reference the id of the commit which introduced the bug.
+ You can generate the required text using the following git alias::
+
+ git config alias.fixline "log -1 --abbrev=12 --format='Fixes: %h (\"%s\")'"
+
+ The ``Fixes:`` line can then be added to the commit message::
+
+ doc: fix vhost sample parameter
+
+ Update the docs to reflect removed dev-index.
+
+ Fixes: 17b8320a3e11 ("vhost: remove index parameter")
+
+ Signed-off-by: Alex Smith <alex.smith@example.com>
+
+* When fixing an error or warning it is useful to add the error message and instructions on how to reproduce it.
+
+* Use correct capitalization, punctuation and spelling.
+
+In addition to the ``Signed-off-by:`` name the commit messages can also have one or more of the following:
+
+* ``Reported-by:`` The reporter of the issue.
+* ``Tested-by:`` The tester of the change.
+* ``Reviewed-by:`` The reviewer of the change.
+* ``Suggested-by:`` The person who suggested the change.
+* ``Acked-by:`` When a previous version of the patch was acked and the ack is still relevant.
+
+
+Creating Patches
+----------------
+
+It is possible to send patches directly from git but for new contributors it is recommended to generate the
+patches with ``git format-patch`` and then when everything looks okay, and the patches have been checked, to
+send them with ``git send-email``.
+
+Here are some examples of using ``git format-patch`` to generate patches:
+
+.. code-block:: console
+
+ # Generate a patch from the last commit.
+ git format-patch -1
+
+ # Generate a patch from the last 3 commits.
+ git format-patch -3
+
+ # Generate the patches in a directory.
+ git format-patch -3 -o ~/patch/
+
+ # Add a cover letter to explain a patchset.
+ git format-patch -3 -o ~/patch/ --cover-letter
+
+ # Add a prefix with a version number.
+ git format-patch -3 -o ~/patch/ -v 2
+
+
+Cover letters are useful for explaining a patchset and help to generate a logical threading to the patches.
+Smaller notes can be put inline in the patch after the ``---`` separator, for example::
+
+ Subject: [PATCH] fm10k/base: add FM10420 device ids
+
+ Add the device ID for Boulder Rapids and Atwood Channel to enable
+ drivers to support those devices.
+
+ Signed-off-by: Alex Smith <alex.smith@example.com>
+ ---
+
+ ADD NOTES HERE.
+
+ drivers/net/fm10k/base/fm10k_api.c | 6 ++++++
+ drivers/net/fm10k/base/fm10k_type.h | 6 ++++++
+ 2 files changed, 12 insertions(+)
+ ...
+
+Version 2 and later of a patchset should also include a short log of the changes so the reviewer knows what has changed.
+This can be added to the cover letter or the annotations.
+For example::
+
+ ---
+ v3:
+ * Fixed issued with version.map.
+
+ v2:
+ * Added i40e support.
+ * Renamed ethdev functions from rte_eth_ieee15888_*() to rte_eth_timesync_*()
+ since 802.1AS can be supported through the same interfaces.
+
+
+.. _contrib_checkpatch:
+
+Checking the Patches
+--------------------
+
+Patches should be checked for formatting and syntax issues using the ``checkpatches.sh`` script in the ``scripts``
+directory of the DPDK repo.
+This uses the Linux kernel development tool ``checkpatch.pl`` which can be obtained by cloning, and periodically,
+updating the Linux kernel sources.
+
+The path to the original Linux script must be set in the environment variable ``DPDK_CHECKPATCH_PATH``.
+This, and any other configuration variables required by the development tools, are loaded from the following
+files, in order of preference::
+
+ .develconfig
+ ~/.config/dpdk/devel.config
+ /etc/dpdk/devel.config.
+
+Once the environment variable the script can be run as follows::
+
+ scripts/checkpatches.sh ~/patch/
+
+The script usage is::
+
+ checkpatches.sh [-h] [-q] [-v] [patch1 [patch2] ...]]"
+
+Where:
+
+* ``-h``: help, usage.
+* ``-q``: quiet. Don't output anything for files without issues.
+* ``-v``: verbose.
+* ``patchX``: path to one or more patches.
+
+
+.. _contrib_check_compilation:
+
+Checking Compilation
+--------------------
+
+Compilation of patches and changes should be tested using the the ``test-build.sh`` script in the ``scripts``
+directory of the DPDK repo::
+
+ scripts/test-build.sh x86_64-native-linuxapp-gcc+next+shared+combined
+
+The script usage is::
+
+ test-build.sh [-h] [-jX] [-s] [config1 [config2] ...]]
+
+Where:
+
+* ``-h``: help, usage.
+* ``-jX``: use X parallel jobs in "make".
+* ``-s``: short test with only first config and without examples/doc.
+* ``config``: default config name plus config switches delimited with a ``+`` sign.
+
+Examples of configs are::
+
+ x86_64-native-linuxapp-gcc
+ x86_64-native-linuxapp-gcc+next+shared+combined
+ x86_64-native-linuxapp-gcc+shared+next
+ x86_64-native-linuxapp-clang+shared+combined
+ i686-native-linuxapp-gcc+combined
+
+The builds can be modifies via the following environmental variables:
+
+* ``DPDK_BUILD_TEST_CONFIGS`` (target1+option1+option2 target2)
+* ``DPDK_DEP_CFLAGS``
+* ``DPDK_DEP_LDFLAGS``
+* ``DPDK_DEP_MOFED`` (y/[n])
+* ``DPDK_DEP_PCAP`` (y/[n])
+* ``DPDK_NOTIFY`` (notify-send)
+
+These can be set from the command line or in the config files shown above in the :ref:`contrib_checkpatch`.
+
+The recommended configurations and options to test compilation prior to submitting patches are::
+
+ x86_64-native-linuxapp-gcc+shared+next
+ x86_64-native-linuxapp-clang+shared+combined
+ i686-native-linuxapp-gcc+combined
+
+ export DPDK_DEP_ZLIB=y
+ export DPDK_DEP_PCAP=y
+ export DPDK_DEP_SSL=y
+
+
+Sending Patches
+---------------
+
+Patches should be sent to the mailing list using ``git send-email``.
+You can configure an external SMTP with something like the following::
+
+ [sendemail]
+ smtpuser = name@domain.com
+ smtpserver = smtp.domain.com
+ smtpserverport = 465
+ smtpencryption = ssl
+
+See the `Git send-email <https://git-scm.com/docs/git-send-email>`_ documentation for more details.
+
+The patches should be sent to ``dev@dpdk.org``.
+If the patches are a change to existing files then you should send them TO the maintainer(s) and CC ``dev@dpdk.org``.
+The appropriate maintainer can be found in the ``MAINTAINERS`` file::
+
+ git send-email --to maintainer@some.org --cc dev@dpdk.org 000*.patch
+
+New additions can be sent without a maintainer::
+
+ git send-email --to dev@dpdk.org 000*.patch
+
+You can test the emails by sending it to yourself or with the ``--dry-run`` option.
+
+If the patch is in relation to a previous email thread you can add it to the same thread using the Message ID::
+
+ git send-email --to dev@dpdk.org --in-reply-to <1234-foo@bar.com> 000*.patch
+
+The Message ID can be found in the raw text of emails or at the top of each Patchwork patch,
+`for example <http://dpdk.org/dev/patchwork/patch/7646/>`_.
+Shallow threading (``--thread --no-chain-reply-to``) is preferred for a patch series.
+
+Once submitted your patches will appear on the mailing list and in Patchwork.
+
+Experienced committers may send patches directly with ``git send-email`` without the ``git format-patch`` step.
+The options ``--annotate`` and ``confirm = always`` are recommended for checking patches before sending.
+
+
+The Review Process
+------------------
+
+The more work you put into the previous steps the easier it will be to get a patch accepted.
+
+The general cycle for patch review and acceptance is:
+
+#. Submit the patch.
+
+#. Check the automatic test reports in the coming hours.
+
+#. Wait for review comments. While you are waiting review some other patches.
+
+#. Fix the review comments and submit a ``v n+1`` patchset::
+
+ git format-patch -3 -v 2
+
+#. Update Patchwork to mark your previous patches as "Superseded".
+
+#. If the patch is deemed suitable for merging by the relevant maintainer(s) or other developers they will ``ack``
+ the patch with an email that includes something like::
+
+ Acked-by: Alex Smith <alex.smith@example.com>
+
+ **Note**: When acking patches please remove as much of the text of the patch email as possible.
+ It is generally best to delete everything after the ``Signed-off-by:`` line.
+
+#. Having the patch ``Reviewed-by:`` and/or ``Tested-by:`` will also help the patch to be accepted.
+
+#. If the patch isn't deemed suitable based on being out of scope or conflicting with existing functionality
+ it may receive a ``nack``.
+ In this case you will need to make a more convincing technical argument in favor of your patches.
+
+#. In addition a patch will not be accepted if it doesn't address comments from a previous version with fixes or
+ valid arguments.
+
+#. Acked patches will be merged in the current or next merge window.
--
2.5.0
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v5] doc: add contributors guide
2015-12-14 20:32 2% ` [dpdk-dev] [PATCH v2] " John McNamara
@ 2015-12-14 20:45 2% ` John McNamara
1 sibling, 0 replies; 200+ results
From: John McNamara @ 2015-12-14 20:45 UTC (permalink / raw)
To: dev
Add a document to explain the DPDK patch submission and review process.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
---
v5:
* Added references to new checkpatches.sh and test-build.sh scripts
as per Thomas' suggestion on the mailing list.
v4:
* Fixes for mailing list comments.
v3:
* Add recommendation to test build the shared and combined libraries.
v2:
* Fixes for mailing list comments.
* Fix for broken link target.
doc/guides/contributing/documentation.rst | 2 +-
doc/guides/contributing/index.rst | 1 +
doc/guides/contributing/patches.rst | 389 ++++++++++++++++++++++++++++++
3 files changed, 391 insertions(+), 1 deletion(-)
create mode 100644 doc/guides/contributing/patches.rst
diff --git a/doc/guides/contributing/documentation.rst b/doc/guides/contributing/documentation.rst
index 6dfaaa8..ba5c4de 100644
--- a/doc/guides/contributing/documentation.rst
+++ b/doc/guides/contributing/documentation.rst
@@ -1,4 +1,4 @@
-.. doc_guidelines:
+.. _doc_guidelines:
DPDK Documentation Guidelines
=============================
diff --git a/doc/guides/contributing/index.rst b/doc/guides/contributing/index.rst
index 561427b..f49ca88 100644
--- a/doc/guides/contributing/index.rst
+++ b/doc/guides/contributing/index.rst
@@ -9,3 +9,4 @@ Contributor's Guidelines
design
versioning
documentation
+ patches
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
new file mode 100644
index 0000000..1729c6b
--- /dev/null
+++ b/doc/guides/contributing/patches.rst
@@ -0,0 +1,389 @@
+.. submitting_patches:
+
+Contributing Code to DPDK
+=========================
+
+This document outlines the guidelines for submitting code to DPDK.
+
+The DPDK development process is modeled (loosely) on the Linux Kernel development model so it is worth reading the
+Linux kernel guide on submitting patches:
+`How to Get Your Change Into the Linux Kernel <http://www.kernel.org/doc/Documentation/SubmittingPatches>`_.
+The rationale for many of the DPDK guidelines is explained in greater detail in the kernel guidelines.
+
+
+The DPDK Development Process
+-----------------------------
+
+The DPDK development process has the following features:
+
+* The code is hosted in a public git repository.
+* There is a mailing list where developers submit patches.
+* There are maintainers for hierarchical components.
+* Patches are reviewed publicly on the mailing list.
+* Successfully reviewed patches are merged to the master branch of the repository.
+
+The mailing list for DPDK development is `dev@dpkg.org <http://dpdk.org/ml/archives/dev/>`_.
+Contributors will need to `register for the mailing list <http://dpdk.org/ml/listinfo/dev>`_ in order to submit patches.
+It is also worth registering for the DPDK `Patchwork <http://dpdk.org/dev/patchwxispork/project/dpdk/list/>`_
+
+The development process requires some familiarity with the ``git`` version control system.
+Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further information.
+
+
+Getting the Source Code
+-----------------------
+
+The source code can be cloned using either of the following::
+
+ git clone git://dpdk.org/dpdk
+
+ git clone http://dpdk.org/git/dpdk
+
+
+Make your Changes
+-----------------
+
+Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines and requirements:
+
+* Follow the :ref:`coding_style` guidelines.
+
+* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+
+* New external functions should be added to the local ``version.map`` file.
+ See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
+ New external functions should also be added in alphabetical order.
+
+* Important changes will require an addition to the release notes in ``doc/guides/rel_notes/``.
+ See the :ref:`Release Notes section of the Documentation Guidelines <doc_guidelines>` for details.
+
+* Test the compilation works with different targets, compilers and options, see :ref:`contrib_check_compilation`.
+
+* Don't break compilation between commits with forward dependencies in a patchset.
+ Each commit should compile on its own to allow for ``git bisect`` and continuous integration testing.
+
+* Add tests to the the ``app/test`` unit test framework where possible.
+
+* Add documentation, if relevant, in the form of Doxygen comments or a User Guide in RST format.
+ See the :ref:`Documentation Guidelines <doc_guidelines>`.
+
+Once the changes have been made you should commit them to your local repo.
+
+For small changes, that do not require specific explanations, it is better to keep things together in the
+same patch.
+Larger changes that require different explanations should be separated into logical patches in a patchset.
+A good way of thinking about whether a patch should be split is to consider whether the change could be
+applied without dependencies as a backport.
+
+As a guide to how patches should be structured run ``git log`` on similar files.
+
+
+Commit Messages: Subject Line
+-----------------------------
+
+The first, summary, line of the git commit message becomes the subject line of the patch email.
+Here are some guidelines for the summary line:
+
+* The summary line must capture the area and the impact of the change.
+
+* The summary line should be around 50 characters.
+
+* The summary line should be lowercase apart from acronyms.
+
+* It should be prefixed with the component name (use git log to check existing components).
+ For example::
+
+ ixgbe: fix offload config option name
+
+ config: increase max queues per port
+
+* Use the imperative of the verb (like instructions to the code base).
+
+* Don't add a period/full stop to the subject line or you will end up two in the patch name: ``dpdk_description..patch``.
+
+The actual email subject line should be prefixed by ``[PATCH]`` and the version, if greater than v1,
+for example: ``PATCH v2``.
+The is generally added by ``git send-email`` or ``git format-patch``, see below.
+
+If you are submitting an RFC draft of a feature you can use ``[RFC]`` instead of ``[PATCH]``.
+An RFC patch doesn't have to be complete.
+It is intended as a way of getting early feedback.
+
+
+Commit Messages: Body
+---------------------
+
+Here are some guidelines for the body of a commit message:
+
+* The body of the message should describe the issue being fixed or the feature being added.
+ It is important to provide enough information to allow a reviewer to understand the purpose of the patch.
+
+* When the change is obvious the body can be blank, apart from the signoff.
+
+* The commit message must end with a ``Signed-off-by:`` line which is added using::
+
+ git commit --signoff # or -s
+
+ The purpose of the signoff is explained in the
+ `Developer's Certificate of Origin <http://www.kernel.org/doc/Documentation/SubmittingPatches>`_
+ section of the Linux kernel guidelines.
+
+ .. Note::
+
+ All developers must ensure that they have read and understood the
+ Developer's Certificate of Origin section of the documentation prior
+ to applying the signoff and submitting a patch.
+
+* The signoff must be a real name and not an alias or nickname.
+ More than one signoff is allowed.
+
+* The text of the commit message should be wrapped at 72 characters.
+
+* When fixing a regression, it is a good idea to reference the id of the commit which introduced the bug.
+ You can generate the required text using the following git alias::
+
+ git config alias.fixline "log -1 --abbrev=12 --format='Fixes: %h (\"%s\")'"
+
+ The ``Fixes:`` line can then be added to the commit message::
+
+ doc: fix vhost sample parameter
+
+ Update the docs to reflect removed dev-index.
+
+ Fixes: 17b8320a3e11 ("vhost: remove index parameter")
+
+ Signed-off-by: Alex Smith <alex.smith@example.com>
+
+* When fixing an error or warning it is useful to add the error message and instructions on how to reproduce it.
+
+* Use correct capitalization, punctuation and spelling.
+
+In addition to the ``Signed-off-by:`` name the commit messages can also have one or more of the following:
+
+* ``Reported-by:`` The reporter of the issue.
+* ``Tested-by:`` The tester of the change.
+* ``Reviewed-by:`` The reviewer of the change.
+* ``Suggested-by:`` The person who suggested the change.
+* ``Acked-by:`` When a previous version of the patch was acked and the ack is still relevant.
+
+
+Creating Patches
+----------------
+
+It is possible to send patches directly from git but for new contributors it is recommended to generate the
+patches with ``git format-patch`` and then when everything looks okay, and the patches have been checked, to
+send them with ``git send-email``.
+
+Here are some examples of using ``git format-patch`` to generate patches:
+
+.. code-block:: console
+
+ # Generate a patch from the last commit.
+ git format-patch -1
+
+ # Generate a patch from the last 3 commits.
+ git format-patch -3
+
+ # Generate the patches in a directory.
+ git format-patch -3 -o ~/patch/
+
+ # Add a cover letter to explain a patchset.
+ git format-patch -3 -o ~/patch/ --cover-letter
+
+ # Add a prefix with a version number.
+ git format-patch -3 -o ~/patch/ -v 2
+
+
+Cover letters are useful for explaining a patchset and help to generate a logical threading to the patches.
+Smaller notes can be put inline in the patch after the ``---`` separator, for example::
+
+ Subject: [PATCH] fm10k/base: add FM10420 device ids
+
+ Add the device ID for Boulder Rapids and Atwood Channel to enable
+ drivers to support those devices.
+
+ Signed-off-by: Alex Smith <alex.smith@example.com>
+ ---
+
+ ADD NOTES HERE.
+
+ drivers/net/fm10k/base/fm10k_api.c | 6 ++++++
+ drivers/net/fm10k/base/fm10k_type.h | 6 ++++++
+ 2 files changed, 12 insertions(+)
+ ...
+
+Version 2 and later of a patchset should also include a short log of the changes so the reviewer knows what has changed.
+This can be added to the cover letter or the annotations.
+For example::
+
+ ---
+ v3:
+ * Fixed issued with version.map.
+
+ v2:
+ * Added i40e support.
+ * Renamed ethdev functions from rte_eth_ieee15888_*() to rte_eth_timesync_*()
+ since 802.1AS can be supported through the same interfaces.
+
+
+.. _contrib_checkpatch:
+
+Checking the Patches
+--------------------
+
+Patches should be checked for formatting and syntax issues using the ``checkpatches.sh`` script in the ``scripts``
+directory of the DPDK repo.
+This uses the Linux kernel development tool ``checkpatch.pl`` which can be obtained by cloning, and periodically,
+updating the Linux kernel sources.
+
+The path to the original Linux script must be set in the environment variable ``DPDK_CHECKPATCH_PATH``.
+This, and any other configuration variables required by the development tools, are loaded from the following
+files, in order of preference::
+
+ .develconfig
+ ~/.config/dpdk/devel.config
+ /etc/dpdk/devel.config.
+
+Once the environment variable the script can be run as follows::
+
+ scripts/checkpatches.sh ~/patch/
+
+The script usage is::
+
+ checkpatches.sh [-h] [-q] [-v] [patch1 [patch2] ...]]"
+
+Where:
+
+* ``-h``: help, usage.
+* ``-q``: quiet. Don't output anything for files without issues.
+* ``-v``: verbose.
+* ``patchX``: path to one or more patches.
+
+
+.. _contrib_check_compilation:
+
+Checking Compilation
+--------------------
+
+Compilation of patches and changes should be tested using the the ``test-build.sh`` script in the ``scripts``
+directory of the DPDK repo::
+
+ scripts/test-build.sh x86_64-native-linuxapp-gcc+next+shared+combined
+
+The script usage is::
+
+ test-build.sh [-h] [-jX] [-s] [config1 [config2] ...]]
+
+Where:
+
+* ``-h``: help, usage.
+* ``-jX``: use X parallel jobs in "make".
+* ``-s``: short test with only first config and without examples/doc.
+* ``config``: default config name plus config switches delimited with a ``+`` sign.
+
+Examples of configs are::
+
+ x86_64-native-linuxapp-gcc
+ x86_64-native-linuxapp-gcc+next+shared+combined
+ x86_64-native-linuxapp-gcc+shared+next
+ x86_64-native-linuxapp-clang+shared+combined
+ i686-native-linuxapp-gcc+combined
+
+The builds can be modifies via the following environmental variables:
+
+* ``DPDK_BUILD_TEST_CONFIGS`` (target1+option1+option2 target2)
+* ``DPDK_DEP_CFLAGS``
+* ``DPDK_DEP_LDFLAGS``
+* ``DPDK_DEP_MOFED`` (y/[n])
+* ``DPDK_DEP_PCAP`` (y/[n])
+* ``DPDK_NOTIFY`` (notify-send)
+
+These can be set from the command line or in the config files shown above in the :ref:`contrib_checkpatch`.
+
+The recommended configurations and options to test compilation prior to submitting patches are::
+
+ x86_64-native-linuxapp-gcc+shared+next
+ x86_64-native-linuxapp-clang+shared+combined
+ i686-native-linuxapp-gcc+combined
+
+ export DPDK_DEP_ZLIB=y
+ export DPDK_DEP_PCAP=y
+ export DPDK_DEP_SSL=y
+
+
+Sending Patches
+---------------
+
+Patches should be sent to the mailing list using ``git send-email``.
+You can configure an external SMTP with something like the following::
+
+ [sendemail]
+ smtpuser = name@domain.com
+ smtpserver = smtp.domain.com
+ smtpserverport = 465
+ smtpencryption = ssl
+
+See the `Git send-email <https://git-scm.com/docs/git-send-email>`_ documentation for more details.
+
+The patches should be sent to ``dev@dpdk.org``.
+If the patches are a change to existing files then you should send them TO the maintainer(s) and CC ``dev@dpdk.org``.
+The appropriate maintainer can be found in the ``MAINTAINERS`` file::
+
+ git send-email --to maintainer@some.org --cc dev@dpdk.org 000*.patch
+
+New additions can be sent without a maintainer::
+
+ git send-email --to dev@dpdk.org 000*.patch
+
+You can test the emails by sending it to yourself or with the ``--dry-run`` option.
+
+If the patch is in relation to a previous email thread you can add it to the same thread using the Message ID::
+
+ git send-email --to dev@dpdk.org --in-reply-to <1234-foo@bar.com> 000*.patch
+
+The Message ID can be found in the raw text of emails or at the top of each Patchwork patch,
+`for example <http://dpdk.org/dev/patchwork/patch/7646/>`_.
+Shallow threading (``--thread --no-chain-reply-to``) is preferred for a patch series.
+
+Once submitted your patches will appear on the mailing list and in Patchwork.
+
+Experienced committers may send patches directly with ``git send-email`` without the ``git format-patch`` step.
+The options ``--annotate`` and ``confirm = always`` are recommended for checking patches before sending.
+
+
+The Review Process
+------------------
+
+The more work you put into the previous steps the easier it will be to get a patch accepted.
+
+The general cycle for patch review and acceptance is:
+
+#. Submit the patch.
+
+#. Check the automatic test reports in the coming hours.
+
+#. Wait for review comments. While you are waiting review some other patches.
+
+#. Fix the review comments and submit a ``v n+1`` patchset::
+
+ git format-patch -3 -v 2
+
+#. Update Patchwork to mark your previous patches as "Superseded".
+
+#. If the patch is deemed suitable for merging by the relevant maintainer(s) or other developers they will ``ack``
+ the patch with an email that includes something like::
+
+ Acked-by: Alex Smith <alex.smith@example.com>
+
+ **Note**: When acking patches please remove as much of the text of the patch email as possible.
+ It is generally best to delete everything after the ``Signed-off-by:`` line.
+
+#. Having the patch ``Reviewed-by:`` and/or ``Tested-by:`` will also help the patch to be accepted.
+
+#. If the patch isn't deemed suitable based on being out of scope or conflicting with existing functionality
+ it may receive a ``nack``.
+ In this case you will need to make a more convincing technical argument in favor of your patches.
+
+#. In addition a patch will not be accepted if it doesn't address comments from a previous version with fixes or
+ valid arguments.
+
+#. Acked patches will be merged in the current or next merge window.
--
2.5.0
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_flow
2015-12-14 15:03 4% ` Thomas Monjalon
@ 2015-12-15 1:17 4% ` Liu, Jijiang
2015-12-15 2:05 7% ` Liu, Jijiang
0 siblings, 1 reply; 200+ results
From: Liu, Jijiang @ 2015-12-15 1:17 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Monday, December 14, 2015 11:04 PM
> To: Liu, Jijiang
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct
> rte_eth_tunnel_flow
>
> 2015-12-09 13:37, Jijiang Liu:
> > The struct 'rte_eth_tunnel_flow' is only used by struct
> > 'rte_eth_fdir_flow' now, but its name is generic, and I plan to extend new
> fileds like below to support generic configuration for tunneling packet.
>
> You have not explained what the changes are for.
> So it's really difficult to have an opinion.
> Please describe an use case.
For i40e flow director, it can use more fields such as inner destination IP, inner MAC outer destination MAC and outer destination IP to do classification for tunneling packet.
Otherwise, we also can use this structure to store tunnel flow configuration, not just for classification.
> PS: "filed" -> "field"
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_flow
2015-12-15 1:17 4% ` Liu, Jijiang
@ 2015-12-15 2:05 7% ` Liu, Jijiang
0 siblings, 0 replies; 200+ results
From: Liu, Jijiang @ 2015-12-15 2:05 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
>
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Monday, December 14, 2015 11:04 PM
> > To: Liu, Jijiang
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct
> > rte_eth_tunnel_flow
> >
> > 2015-12-09 13:37, Jijiang Liu:
> > > The struct 'rte_eth_tunnel_flow' is only used by struct
> > > 'rte_eth_fdir_flow' now, but its name is generic, and I plan to
> > > extend new
> > fileds like below to support generic configuration for tunneling packet.
> >
> > You have not explained what the changes are for.
> > So it's really difficult to have an opinion.
> > Please describe an use case.
> For i40e flow director, it can use more fields such as inner destination IP,
> inner MAC outer destination MAC and outer destination IP to do
> classification for tunneling packet.
> Otherwise, we also can use this structure to store tunnel flow configuration,
> not just for classification.
>
> > PS: "filed" -> "field"
After aligning with Jingjing, she have already sent ABI change announcement for struct 'rte_eth_fdir_flow'to extend input set of FD, refer to[1].
And change of struct 'rte_eth_tunnel_flow' I want to announce can be included in hers, so I don't need to announce it again. Thanks.
[1]http://dpdk.org/ml/archives/dev/2015-November/027915.html
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf
2015-12-14 15:10 4% ` Thomas Monjalon
@ 2015-12-15 3:00 4% ` Liu, Jijiang
0 siblings, 0 replies; 200+ results
From: Liu, Jijiang @ 2015-12-15 3:00 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Monday, December 14, 2015 11:10 PM
> To: Liu, Jijiang
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct
> rte_eth_conf
>
> > And tunneling packet encapsulation operation will benefit from the change.
>
> Sorry, I don't understand what you mean.
> Maybe others have a clue?
We want to add functions of tunneling packet decapsulation/encapsulation as APIs into DPDK, and it had better store tunnel configuration in a device's configuration, as a result, outer src/dst MAC address, outer src/dst IP address and others can be stored for a pair of queues.
The stored configuration can be used when encapsulating a tunneling packet for sending out via a specific queue.
And for RX side, we can use flow director or tunnel filter mechanism to guarantee a specific flow enter the a specific.
For example,
We do the following configuration,
rx_queue: 1
tx_queue: 1
Tunnel id: 1000
Outer Src MAC:
Outer dst MAC: 66.55.44.33.22.11
Outer Src IP:
Outer dst IP: 192.168.10.2
inner dst MAC: 22.33.44.55.66.77
And set RX classification condition for RX queue 1: Outer dst MAC + Tunnel id + inner dst MAC ( or 5 tuples), and decapsulate the tunneling packet and save some fields in the 'tunnel_conf' in the ' rte_eth_conf ',
then these stored configuration can be used when encapsulating a tunneling packet for sending out via TX queue 1.
> > The change of struct 'rte_eth_conf' like below, but it have not finalized yet.
> > struct rte_eth_conf {
> > ...
> >
> > struct rte_eth_tunnel_conf *tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
> > /**< Tunnel configuration. */
> > };
> This rte_eth_conf struct is an input for rte_eth_dev_configure().
> Should we add some fields which are not used by rte_eth_dev_configure()
> but configured through rte_eth_dev_filter_ctrl() instead?
The tunnel configuration is not just for classification, we also need them to do encapsulation operation.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 2/2] doc: announce ABI change for RETA configuration
2015-12-14 14:25 4% ` Thomas Monjalon
@ 2015-12-15 5:32 4% ` Lu, Wenzhuo
2015-12-15 6:14 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Lu, Wenzhuo @ 2015-12-15 5:32 UTC (permalink / raw)
To: Nelio Laranjeiro, dev
Hi,
> -----Original Message-----
> From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> Sent: Tuesday, November 10, 2015 12:48 AM
> To: dev@dpdk.org
> Cc: olivier.matz@6wind.com; thomas.monjalon@6wind.com; Mcnamara,
> John <john.mcnamara@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>
> Subject: [PATCH 2/2] doc: announce ABI change for RETA configuration
>
> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size
2015-12-14 14:13 4% ` Thomas Monjalon
@ 2015-12-15 6:11 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 6:11 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev
> > Current buffer size are not enough for a few testpmd commands.
> >
> > Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> Acked-by: John McNamara <john.mcnamara@intel.com>
> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> Acked-by: Olga Shern <olgas@mellanox.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 2/2] doc: announce ABI change for RETA configuration
2015-12-15 5:32 4% ` Lu, Wenzhuo
@ 2015-12-15 6:14 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 6:14 UTC (permalink / raw)
To: Nelio Laranjeiro; +Cc: dev
> > Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> Acked-by: Olga Shern <olgas@mellanox.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_fdir_flow
@ 2015-12-15 6:46 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 6:46 UTC (permalink / raw)
To: Wu, Jingjing; +Cc: dev
> > Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
> Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> Acked-by: Helin Zhang <helin.zhang@intel.com>
> Acked-by: Andrey Chilikin <andrey.chilikin@intel.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_filter_conf
@ 2015-12-15 6:52 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 6:52 UTC (permalink / raw)
To: Wu, Jingjing; +Cc: dev
> > Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
> Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> Acked-by: Helin Zhang <helin.zhang@intel.com>
> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] doc: announce ABI change for link speed
@ 2015-12-15 7:21 9% Thomas Monjalon
2015-12-15 9:22 12% ` Olga Shern
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 7:21 UTC (permalink / raw)
To: dev; +Cc: Matej Vido
A rework was prepared by Marc Sune:
http://dpdk.org/ml/archives/dev/2015-October/026037.html
The goal is to retrieve the supported link speed of a device
and to allow 100G devices while having a consistent API.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
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 a4abb08..f8a41dd 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -12,6 +12,9 @@ Deprecation Notices
ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff
+* The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
+ must be updated to support 100G link and to have a cleaner link speed API.
+
* ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
which handles at most 256 entries (8 bits) while newer NICs support larger
tables (512 entries).
--
2.5.2
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support
2015-12-10 14:01 4% ` [dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support Rahul Lakkireddy
@ 2015-12-15 8:40 7% ` Rahul Lakkireddy
2015-12-15 8:55 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Rahul Lakkireddy @ 2015-12-15 8:40 UTC (permalink / raw)
To: dev, Thomas Monjalon; +Cc: Kumar Sanghvi, Felix Marti, Nirranjan Kirubaharan
Hi Thomas,
I am preparing a v2 of this series where I will be accomodating some
more fields to be considered for filtering. However, if the overall
approach seems ok to everyone then, should I submit a separate patch
for this ABI change announcement ?
Thanks,
Rahul.
On Thursday, December 12/10/15, 2015 at 19:31:04 +0530, Rahul Lakkireddy wrote:
> Current filtering support will be enhanced to accommodate support
> for Chelsio T5 hardware filtering support.
>
> Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
> Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 1c7ab01..ca43b16 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -19,3 +19,9 @@ Deprecation Notices
> and table action handlers will be updated:
> the pipeline parameter will be added, the packets mask parameter will be
> either removed (for input port action handler) or made input-only.
> +
> +* The filtering support will be changed to add a new packet filter
> + flow, add a new behavior 'switch', add an ability to add mask
> + for fields in each filter rule, and add an ability to pass extra
> + arguments for the behavior taken to allow rewriting matched fields
> + in filter rule.
> --
> 2.5.3
>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf
2015-12-14 7:48 21% [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf Jijiang Liu
2015-12-14 9:19 4% ` Chilikin, Andrey
2015-12-14 15:10 4% ` Thomas Monjalon
@ 2015-12-15 8:50 4% ` Ivan Boule
2015-12-18 2:00 4% ` Liu, Jijiang
2 siblings, 1 reply; 200+ results
From: Ivan Boule @ 2015-12-15 8:50 UTC (permalink / raw)
To: Jijiang Liu; +Cc: dev
On 12/14/2015 08:48 AM, Jijiang Liu wrote:
> In current codes, tunnel configuration information is not stored in a device configuration, and it will get nothing if application want to retrieve tunnel config, so I think it is necessary to add rte_eth_dev_tunnel_configure() function is to do the configurations including flow and classification information and store it in a device configuration.
>
> And tunneling packet encapsulation operation will benifit from the change.
>
> There are more descriptions for the ABI changes below,
>
> The struct 'rte_eth_tunnel_conf' is a new, its defination like below,
> struct rte_eth_tunnel_conf {
> uint16_t tx_queue;
> uint16_t filter_type;
> struct rte_eth_tunnel_flow flow_tnl;
> };
>
> The ABI change announcement of struct 'rte_eth_tunnel_flow' have already sent out, refer to [1].
>
> [1]http://dpdk.org/ml/archives/dev/2015-December/029837.html.
>
> The change of struct 'rte_eth_conf' like below, but it have not finalized yet.
> struct rte_eth_conf {
> ...
> uint32_t dcb_capability_en;
> struct rte_fdir_conf fdir_conf; /**< FDIR configuration. */
> struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */
> struct rte_eth_tunnel_conf *tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
> /**< Tunnel configuration. */
> };
>
> v2 change:
> Add more description for the change.
>
> v3 change:
> Change ABI announcement description.
>
> Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
> ---cmdline.c
> doc/guides/rel_notes/deprecation.rst | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 5c458f2..9dbe89e 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -23,3 +23,9 @@ Deprecation Notices
> * ABI changes are planned for struct rte_eth_tunnel_flow in order to extend new fileds to support
> tunneling packet configuration in unified tunneling APIs. The release 2.2 does not contain these ABI
> changes, but release 2.3 will, and no backwards compatibility is planned.
> +
> +* ABI changes are planned for the struct rte_eth_conf in order to add 'tunnel_conf' variable
> + in the struct to store tunnel configuration when using new API rte_eth_dev_tunnel_configure
> + (uint8_t port_id, uint16_t rx_queue, struct rte_eth_tunnel_conf * tunnel_conf) to configure
> + tunnel flow and classification information. The release 2.2 does not contain these ABI change,
> + but release 2.3 will, and no backward compatibility is planned.
>
Hi Jijiang,
Can you provide a real use case - I mean an example of a real network
application - that really needs to save tunnel configurations in a data
structure associated with a NIC port?
Firstly, if the only usage is to enable applications to retrieve tunnel
configurations, then you are simply growing the size of the per-port
structure with tunnel configurations, and imposing it to every DPDK
application.
You impose it to those applications that don't care about tunneling, but
also to those applications which do care, but which prefer to have their
own representation of ports where they store everything they need to.
If the tunnel configuration is also used for other purposes, then it
must be precisely described what happens with the saved tunnel
configuration when the application changes the state of a port.
This is the case for instance when the application reconfigures the
number of RX queues of a port.
Who is responsible for checking that some tunnels won't be matched anymore?
Who is responsible for dropping/invalidating the saved tunnel
configuration, if such operations must be performed?
This list is likely to be not exhaustive, of course.
More globally, all side-effects of saving the tunnel configuration must
be considered and addressed in a coherent way and in an easy-to-use
approach.
By the way, as far as I know, the Linux kernel does not [need to] save
tunnel data or ARP entries behind "netdevice" structures.
PS : in the "rte_eth_tunnel_conf" data structure, I think that the first
field should be named "rx_queue" instead of "tx_queue".
Regards,
Ivan
--
Ivan Boule
6WIND Development Engineer
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support
2015-12-15 8:40 7% ` Rahul Lakkireddy
@ 2015-12-15 8:55 4% ` Thomas Monjalon
2015-12-15 13:51 9% ` Rahul Lakkireddy
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-15 8:55 UTC (permalink / raw)
To: Rahul Lakkireddy; +Cc: dev, Felix Marti, Nirranjan Kirubaharan, Kumar Sanghvi
2015-12-15 14:10, Rahul Lakkireddy:
> Hi Thomas,
>
> I am preparing a v2 of this series where I will be accomodating some
> more fields to be considered for filtering. However, if the overall
> approach seems ok to everyone then, should I submit a separate patch
> for this ABI change announcement ?
Yes, if this announce is not enough:
http://dpdk.org/browse/dpdk/commit/?id=648e6b3815a35
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for link speed
2015-12-15 7:21 9% [dpdk-dev] [PATCH] doc: announce ABI change for link speed Thomas Monjalon
@ 2015-12-15 9:22 12% ` Olga Shern
2015-12-15 10:54 4% ` Adrien Mazarguil
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Olga Shern @ 2015-12-15 9:22 UTC (permalink / raw)
To: Thomas Monjalon, dev; +Cc: Matej Vido
Acked-by: Olga Shern <olgas@mellanox.com>
-----Original Message-----
From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
Sent: Tuesday, December 15, 2015 9:21 AM
To: dev@dpdk.org
Cc: Marc Sune <marcdevel@gmail.com>; Olga Shern <olgas@mellanox.com>; Matej Vido <matejvido@gmail.com>
Subject: [PATCH] doc: announce ABI change for link speed
A rework was prepared by Marc Sune:
http://dpdk.org/ml/archives/dev/2015-October/026037.html
The goal is to retrieve the supported link speed of a device and to allow 100G devices while having a consistent API.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
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 a4abb08..f8a41dd 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -12,6 +12,9 @@ Deprecation Notices
ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff
+* The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
+ must be updated to support 100G link and to have a cleaner link speed API.
+
* ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
which handles at most 256 entries (8 bits) while newer NICs support larger
tables (512 entries).
--
2.5.2
^ permalink raw reply [relevance 12%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for link speed
2015-12-15 7:21 9% [dpdk-dev] [PATCH] doc: announce ABI change for link speed Thomas Monjalon
2015-12-15 9:22 12% ` Olga Shern
@ 2015-12-15 10:54 4% ` Adrien Mazarguil
2015-12-15 11:16 4% ` Jan Viktorin
2015-12-15 11:59 4% ` Matej Vido
3 siblings, 0 replies; 200+ results
From: Adrien Mazarguil @ 2015-12-15 10:54 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Matej Vido
On Tue, Dec 15, 2015 at 08:21:14AM +0100, Thomas Monjalon wrote:
> A rework was prepared by Marc Sune:
> http://dpdk.org/ml/archives/dev/2015-October/026037.html
> The goal is to retrieve the supported link speed of a device
> and to allow 100G devices while having a consistent API.
>
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for link speed
2015-12-15 7:21 9% [dpdk-dev] [PATCH] doc: announce ABI change for link speed Thomas Monjalon
2015-12-15 9:22 12% ` Olga Shern
2015-12-15 10:54 4% ` Adrien Mazarguil
@ 2015-12-15 11:16 4% ` Jan Viktorin
2015-12-15 11:59 4% ` Matej Vido
3 siblings, 0 replies; 200+ results
From: Jan Viktorin @ 2015-12-15 11:16 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Matej Vido
On Tue, 15 Dec 2015 08:21:14 +0100
Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> A rework was prepared by Marc Sune:
> http://dpdk.org/ml/archives/dev/2015-October/026037.html
> The goal is to retrieve the supported link speed of a device
> and to allow 100G devices while having a consistent API.
>
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Jan Viktorin <viktorin@rehivetech.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] Urgent - Fwd: [PATCH] doc: announce ABI change for link speed
[not found] ` <D52B67DD-3646-4121-B2C2-73E5B27D898B@cesnet.cz>
@ 2015-12-15 11:21 4% ` Jan Viktorin
0 siblings, 0 replies; 200+ results
From: Jan Viktorin @ 2015-12-15 11:21 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Viktor Puš, dev, Matej Vido
Matej is aware of those changes (towards 100G) and we were discussing
this extension already. Great to see that this topic is moving on.
Jan
On Tue, 15 Dec 2015 11:56:47 +0100
Viktor Puš <pus@cesnet.cz> wrote:
> CCing to Jan in case Matej is offline today - can you ack this?
>
> Best,
> Viktor
>
> > On 15 Dec 2015, at 11:42, Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> >
> > Please, are you available to allow 100G in next DPDK release?
> > It must be accepted before releasing 2.2 (today).
> > Thanks
> >
> > 2015-12-15 08:31, Thomas Monjalon:
> >> Please ack ASAP to reach 3 acks before the release (in the coming hours).
> >> Thanks a lot
> >>
> >> -----------------------------------
> >>
> >> Objet : [PATCH] doc: announce ABI change for link speed
> >> Date : mardi 15 décembre 2015, 08:21:14
> >> De : Thomas Monjalon <thomas.monjalon@6wind.com>
> >> À : dev@dpdk.org
> >> CC : Marc Sune <marcdevel@gmail.com>, Olga Shern <olgas@mellanox.com>, Matej Vido <matejvido@gmail.com>
> >>
> >> A rework was prepared by Marc Sune:
> >> http://dpdk.org/ml/archives/dev/2015-October/026037.html
> >> The goal is to retrieve the supported link speed of a device
> >> and to allow 100G devices while having a consistent API.
> >>
> >> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> >> ---
> >> 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 a4abb08..f8a41dd 100644
> >> --- a/doc/guides/rel_notes/deprecation.rst
> >> +++ b/doc/guides/rel_notes/deprecation.rst
> >> @@ -12,6 +12,9 @@ Deprecation Notices
> >> ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
> >> tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff
> >>
> >> +* The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
> >> + must be updated to support 100G link and to have a cleaner link speed API.
> >> +
> >> * ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
> >> which handles at most 256 entries (8 bits) while newer NICs support larger
> >> tables (512 entries).
> >>
>
--
Jan Viktorin E-mail: Viktorin@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for link speed
2015-12-15 7:21 9% [dpdk-dev] [PATCH] doc: announce ABI change for link speed Thomas Monjalon
` (2 preceding siblings ...)
2015-12-15 11:16 4% ` Jan Viktorin
@ 2015-12-15 11:59 4% ` Matej Vido
2015-12-15 12:52 4% ` Thomas Monjalon
3 siblings, 1 reply; 200+ results
From: Matej Vido @ 2015-12-15 11:59 UTC (permalink / raw)
To: Thomas Monjalon, dev
Acked-by: Matej Vido <matejvido@gmail.com>
Dňa 15.12.2015 o 08:21 Thomas Monjalon napísal(a):
> A rework was prepared by Marc Sune:
> http://dpdk.org/ml/archives/dev/2015-October/026037.html
> The goal is to retrieve the supported link speed of a device
> and to allow 100G devices while having a consistent API.
>
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for link speed
2015-12-15 11:59 4% ` Matej Vido
@ 2015-12-15 12:52 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 12:52 UTC (permalink / raw)
To: dev; +Cc: Matej Vido
> > A rework was prepared by Marc Sune:
> > http://dpdk.org/ml/archives/dev/2015-October/026037.html
> > The goal is to retrieve the supported link speed of a device
> > and to allow 100G devices while having a consistent API.
> >
> > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> Acked-by: Olga Shern <olgas@mellanox.com>
> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Acked-by: Jan Viktorin <viktorin@rehivetech.com>
> Acked-by: Matej Vido <matejvido@gmail.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] doc: improve linux guide layout
@ 2015-12-15 13:34 2% John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2015-12-15 13:34 UTC (permalink / raw)
To: dev
Fixed Linux Getting Started Guide rst layout to improve
rendering in PDF.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/linux_gsg/build_dpdk.rst | 88 +++++++++---------
doc/guides/linux_gsg/build_sample_apps.rst | 141 +++++++++++++++++------------
doc/guides/linux_gsg/enable_func.rst | 95 ++++++++++---------
doc/guides/linux_gsg/intro.rst | 8 +-
doc/guides/linux_gsg/quick_start.rst | 25 ++---
doc/guides/linux_gsg/sys_reqs.rst | 114 ++++++++---------------
6 files changed, 234 insertions(+), 237 deletions(-)
diff --git a/doc/guides/linux_gsg/build_dpdk.rst b/doc/guides/linux_gsg/build_dpdk.rst
index c4d1e08..1f4c1f7 100644
--- a/doc/guides/linux_gsg/build_dpdk.rst
+++ b/doc/guides/linux_gsg/build_dpdk.rst
@@ -28,14 +28,13 @@
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-.. _linux_gsg_compiling_dpdk:
-
Compiling the DPDK Target from Source
=====================================
.. note::
- Parts of this process can also be done using the setup script described in Chapter 6 of this document.
+ Parts of this process can also be done using the setup script described in
+ the :ref:`linux_setup_script` section of this document.
Install the DPDK and Browse Sources
-----------------------------------
@@ -44,10 +43,12 @@ First, uncompress the archive and move to the uncompressed DPDK source directory
.. code-block:: console
- user@host:~$ unzip DPDK-<version>.zip
- user@host:~$ cd DPDK-<version>
- user@host:~/DPDK-<version>$ ls
- app/ config/ drivers/ examples/ lib/ LICENSE.GPL LICENSE.LGPL Makefile mk/ scripts/ tools/
+ unzip DPDK-<version>.zip
+ cd DPDK-<version>
+
+ ls
+ app/ config/ examples/ lib/ LICENSE.GPL LICENSE.LGPL Makefile
+ mk/ scripts/ tools/
The DPDK is composed of several directories:
@@ -64,19 +65,19 @@ The DPDK is composed of several directories:
Installation of DPDK Target Environments
----------------------------------------
-The format of a DPDK target is:
+The format of a DPDK target is::
ARCH-MACHINE-EXECENV-TOOLCHAIN
where:
-* ARCH can be: i686, x86_64, ppc_64
+* ``ARCH`` can be: ``i686``, ``x86_64``, ``ppc_64``
-* MACHINE can be: native, ivshmem, power8
+* ``MACHINE`` can be: ``native``, ``ivshmem``, ``power8``
-* EXECENV can be: linuxapp, bsdapp
+* ``EXECENV`` can be: ``linuxapp``, ``bsdapp``
-* TOOLCHAIN can be: gcc, icc
+* ``TOOLCHAIN`` can be: ``gcc``, ``icc``
The targets to be installed depend on the 32-bit and/or 64-bit packages and compilers installed on the host.
Available targets can be found in the DPDK/config directory.
@@ -84,13 +85,13 @@ The defconfig\_ prefix should not be used.
.. note::
- Configuration files are provided with the RTE_MACHINE optimization level set.
- Within the configuration files, the RTE_MACHINE configuration value is set to native,
+ Configuration files are provided with the ``RTE_MACHINE`` optimization level set.
+ Within the configuration files, the ``RTE_MACHINE`` configuration value is set to native,
which means that the compiled software is tuned for the platform on which it is built.
For more information on this setting, and its possible values, see the *DPDK Programmers Guide*.
When using the Intel® C++ Compiler (icc), one of the following commands should be invoked for 64-bit or 32-bit use respectively.
-Notice that the shell scripts update the $PATH variable and therefore should not be performed in the same session.
+Notice that the shell scripts update the ``$PATH`` variable and therefore should not be performed in the same session.
Also, verify the compiler's installation directory since the path may be different:
.. code-block:: console
@@ -98,7 +99,7 @@ Also, verify the compiler's installation directory since the path may be differe
source /opt/intel/bin/iccvars.sh intel64
source /opt/intel/bin/iccvars.sh ia32
-To install and make targets, use the make install T=<target> command in the top-level DPDK directory.
+To install and make targets, use the ``make install T=<target>`` command in the top-level DPDK directory.
For example, to compile a 64-bit target using icc, run:
@@ -113,7 +114,7 @@ To compile a 32-bit build using gcc, the make command should be:
make install T=i686-native-linuxapp-gcc
To prepare a target without building it, for example, if the configuration changes need to be made before compilation,
-use the make config T=<target> command:
+use the ``make config T=<target>`` command:
.. code-block:: console
@@ -121,10 +122,10 @@ use the make config T=<target> command:
.. warning::
- Any kernel modules to be used, e.g. igb_uio, kni, must be compiled with the
+ Any kernel modules to be used, e.g. ``igb_uio``, ``kni``, must be compiled with the
same kernel as the one running on the target.
If the DPDK is not being built on the target machine,
- the RTE_KERNELDIR environment variable should be used to point the compilation at a copy of the kernel version to be used on the target machine.
+ the ``RTE_KERNELDIR`` environment variable should be used to point the compilation at a copy of the kernel version to be used on the target machine.
Once the target environment is created, the user may move to the target environment directory and continue to make code changes and re-compile.
The user may also make modifications to the compile-time DPDK configuration by editing the .config file in the build directory.
@@ -147,21 +148,22 @@ A kmod directory is also present that contains kernel modules which may be load
.. code-block:: console
- $ ls x86_64-native-linuxapp-gcc
+ ls x86_64-native-linuxapp-gcc
+
app build hostapp include kmod lib Makefile
Loading Modules to Enable Userspace IO for DPDK
-----------------------------------------------
To run any DPDK application, a suitable uio module can be loaded into the running kernel.
-In many cases, the standard uio_pci_generic module included in the Linux kernel
+In many cases, the standard ``uio_pci_generic`` module included in the Linux kernel
can provide the uio capability. This module can be loaded using the command
.. code-block:: console
sudo modprobe uio_pci_generic
-As an alternative to the uio_pci_generic, the DPDK also includes the igb_uio
+As an alternative to the ``uio_pci_generic``, the DPDK also includes the igb_uio
module which can be found in the kmod subdirectory referred to above. It can
be loaded as shown below:
@@ -173,7 +175,7 @@ be loaded as shown below:
.. note::
For some devices which lack support for legacy interrupts, e.g. virtual function
- (VF) devices, the igb_uio module may be needed in place of uio_pci_generic.
+ (VF) devices, the ``igb_uio`` module may be needed in place of ``uio_pci_generic``.
Since DPDK release 1.7 onward provides VFIO support, use of UIO is optional
for platforms that support using VFIO.
@@ -181,7 +183,7 @@ for platforms that support using VFIO.
Loading VFIO Module
-------------------
-To run an DPDK application and make use of VFIO, the vfio-pci module must be loaded:
+To run an DPDK application and make use of VFIO, the ``vfio-pci`` module must be loaded:
.. code-block:: console
@@ -196,29 +198,31 @@ Also, to use VFIO, both kernel and BIOS must support and be configured to use IO
For proper operation of VFIO when running DPDK applications as a non-privileged user, correct permissions should also be set up.
This can be done by using the DPDK setup script (called setup.sh and located in the tools directory).
+.. _linux_gsg_binding_kernel:
+
Binding and Unbinding Network Ports to/from the Kernel Modules
-----------------------------------------------------------------------
+--------------------------------------------------------------
As of release 1.4, DPDK applications no longer automatically unbind all supported network ports from the kernel driver in use.
Instead, all ports that are to be used by an DPDK application must be bound to the
-uio_pci_generic, igb_uio or vfio-pci module before the application is run.
+``uio_pci_generic``, ``igb_uio`` or ``vfio-pci`` module before the application is run.
Any network ports under Linux* control will be ignored by the DPDK poll-mode drivers and cannot be used by the application.
.. warning::
The DPDK will, by default, no longer automatically unbind network ports from the kernel driver at startup.
Any ports to be used by an DPDK application must be unbound from Linux* control and
- bound to the uio_pci_generic, igb_uio or vfio-pci module before the application is run.
+ bound to the ``uio_pci_generic``, ``igb_uio`` or ``vfio-pci`` module before the application is run.
-To bind ports to the uio_pci_generic, igb_uio or vfio-pci module for DPDK use,
+To bind ports to the ``uio_pci_generic``, ``igb_uio`` or ``vfio-pci`` module for DPDK use,
and then subsequently return ports to Linux* control,
a utility script called dpdk_nic _bind.py is provided in the tools subdirectory.
This utility can be used to provide a view of the current state of the network ports on the system,
and to bind and unbind those ports from the different kernel modules, including the uio and vfio modules.
The following are some examples of how the script can be used.
-A full description of the script and its parameters can be obtained by calling the script with the --help or --usage options.
+A full description of the script and its parameters can be obtained by calling the script with the ``--help`` or ``--usage`` options.
Note that the uio or vfio kernel modules to be used, should be loaded into the kernel before
-running the dpdk_nic_bind.py script.
+running the ``dpdk_nic_bind.py`` script.
.. warning::
@@ -239,38 +243,38 @@ To see the status of all network ports on the system:
.. code-block:: console
- root@host:DPDK# ./tools/dpdk_nic_bind.py --status
+ ./tools/dpdk_nic_bind.py --status
Network devices using DPDK-compatible driver
============================================
- 0000:82:00.0 '82599EB 10-Gigabit SFI/SFP+ Network Connection' drv=uio_pci_generic unused=ixgbe
- 0000:82:00.1 '82599EB 10-Gigabit SFI/SFP+ Network Connection' drv=uio_pci_generic unused=ixgbe
+ 0000:82:00.0 '82599EB 10-GbE NIC' drv=uio_pci_generic unused=ixgbe
+ 0000:82:00.1 '82599EB 10-GbE NIC' drv=uio_pci_generic unused=ixgbe
Network devices using kernel driver
===================================
- 0000:04:00.0 'I350 Gigabit Network Connection' if=em0 drv=igb unused=uio_pci_generic *Active*
- 0000:04:00.1 'I350 Gigabit Network Connection' if=eth1 drv=igb unused=uio_pci_generic
- 0000:04:00.2 'I350 Gigabit Network Connection' if=eth2 drv=igb unused=uio_pci_generic
- 0000:04:00.3 'I350 Gigabit Network Connection' if=eth3 drv=igb unused=uio_pci_generic
+ 0000:04:00.0 'I350 1-GbE NIC' if=em0 drv=igb unused=uio_pci_generic *Active*
+ 0000:04:00.1 'I350 1-GbE NIC' if=eth1 drv=igb unused=uio_pci_generic
+ 0000:04:00.2 'I350 1-GbE NIC' if=eth2 drv=igb unused=uio_pci_generic
+ 0000:04:00.3 'I350 1-GbE NIC' if=eth3 drv=igb unused=uio_pci_generic
Other network devices
=====================
<none>
-To bind device eth1, 04:00.1, to the uio_pci_generic driver:
+To bind device ``eth1``,``04:00.1``, to the ``uio_pci_generic`` driver:
.. code-block:: console
- root@host:DPDK# ./tools/dpdk_nic_bind.py --bind=uio_pci_generic 04:00.1
+ ./tools/dpdk_nic_bind.py --bind=uio_pci_generic 04:00.1
or, alternatively,
.. code-block:: console
- root@host:DPDK# ./tools/dpdk_nic_bind.py --bind=uio_pci_generic eth1
+ ./tools/dpdk_nic_bind.py --bind=uio_pci_generic eth1
-To restore device 82:00.0 to its original kernel binding:
+To restore device ``82:00.0`` to its original kernel binding:
.. code-block:: console
- root@host:DPDK# ./tools/dpdk_nic_bind.py --bind=ixgbe 82:00.0
+ ./tools/dpdk_nic_bind.py --bind=ixgbe 82:00.0
diff --git a/doc/guides/linux_gsg/build_sample_apps.rst b/doc/guides/linux_gsg/build_sample_apps.rst
index 07d84df..e53bd51 100644
--- a/doc/guides/linux_gsg/build_sample_apps.rst
+++ b/doc/guides/linux_gsg/build_sample_apps.rst
@@ -36,59 +36,62 @@ It also provides a pointer to where sample applications are stored.
.. note::
- Parts of this process can also be done using the setup script described in **Chapter 6** of this document.
+ Parts of this process can also be done using the setup script described the
+ :ref:`linux_setup_script` section of this document.
Compiling a Sample Application
------------------------------
-Once an DPDK target environment directory has been created (such as x86_64-native-linuxapp-gcc),
+Once an DPDK target environment directory has been created (such as ``x86_64-native-linuxapp-gcc``),
it contains all libraries and header files required to build an application.
When compiling an application in the Linux* environment on the DPDK, the following variables must be exported:
-* RTE_SDK - Points to the DPDK installation directory.
+* ``RTE_SDK`` - Points to the DPDK installation directory.
-* RTE_TARGET - Points to the DPDK target environment directory.
+* ``RTE_TARGET`` - Points to the DPDK target environment directory.
-The following is an example of creating the helloworld application, which runs in the DPDK Linux environment.
-This example may be found in the ${RTE_SDK}/examples directory.
+The following is an example of creating the ``helloworld`` application, which runs in the DPDK Linux environment.
+This example may be found in the ``${RTE_SDK}/examples`` directory.
-The directory contains the main.c file. This file, when combined with the libraries in the DPDK target environment,
+The directory contains the ``main.c`` file. This file, when combined with the libraries in the DPDK target environment,
calls the various functions to initialize the DPDK environment,
then launches an entry point (dispatch application) for each core to be utilized.
By default, the binary is generated in the build directory.
.. code-block:: console
- user@host:~/DPDK$ cd examples/helloworld/
- user@host:~/DPDK/examples/helloworld$ export RTE_SDK=$HOME/DPDK
- user@host:~/DPDK/examples/helloworld$ export RTE_TARGET=x86_64-native-linuxapp-gcc
- user@host:~/DPDK/examples/helloworld$ make
+ cd examples/helloworld/
+ export RTE_SDK=$HOME/DPDK
+ export RTE_TARGET=x86_64-native-linuxapp-gcc
+
+ make
CC main.o
LD helloworld
INSTALL-APP helloworld
INSTALL-MAP helloworld.map
- user@host:~/DPDK/examples/helloworld$ ls build/app
+ ls build/app
helloworld helloworld.map
.. note::
- In the above example, helloworld was in the directory structure of the DPDK.
+ In the above example, ``helloworld`` was in the directory structure of the DPDK.
However, it could have been located outside the directory structure to keep the DPDK structure intact.
- In the following case, the helloworld application is copied to a new directory as a new starting point.
+ In the following case, the ``helloworld`` application is copied to a new directory as a new starting point.
.. code-block:: console
- user@host:~$ export RTE_SDK=/home/user/DPDK
- user@host:~$ cp -r $(RTE_SDK)/examples/helloworld my_rte_app
- user@host:~$ cd my_rte_app/
- user@host:~$ export RTE_TARGET=x86_64-native-linuxapp-gcc
- user@host:~/my_rte_app$ make
- CC main.o
- LD helloworld
- INSTALL-APP helloworld
- INSTALL-MAP helloworld.map
+ export RTE_SDK=/home/user/DPDK
+ cp -r $(RTE_SDK)/examples/helloworld my_rte_app
+ cd my_rte_app/
+ export RTE_TARGET=x86_64-native-linuxapp-gcc
+
+ make
+ CC main.o
+ LD helloworld
+ INSTALL-APP helloworld
+ INSTALL-MAP helloworld.map
Running a Sample Application
----------------------------
@@ -100,7 +103,7 @@ Running a Sample Application
.. warning::
Any ports to be used by the application must be already bound to an appropriate kernel
- module, as described in Section 3.5, prior to running the application.
+ module, as described in :ref:`linux_gsg_binding_kernel`, prior to running the application.
The application is linked with the DPDK target environment's Environmental Abstraction Layer (EAL) library,
which provides some options that are generic to every DPDK application.
@@ -109,55 +112,75 @@ The following is the list of options that can be given to the EAL:
.. code-block:: console
- ./rte-app -n NUM [-c COREMASK] [-b <domain:bus:devid.func>] [--socket-mem=MB,...] [-m MB] [-r NUM] [-v] [--file-prefix] [--proc-type <primary|secondary|auto>] [-- xen-dom0]
+ ./rte-app -c COREMASK [-n NUM] [-b <domain:bus:devid.func>] \
+ [--socket-mem=MB,...] [-m MB] [-r NUM] [-v] [--file-prefix] \
+ [--proc-type <primary|secondary|auto>] [-- xen-dom0]
The EAL options are as follows:
-* -c COREMASK: An hexadecimal bit mask of the cores to run on. Note that core numbering can change between platforms and should be determined beforehand.
+* ``-c COREMASK``:
+ An hexadecimal bit mask of the cores to run on. Note that core numbering can
+ change between platforms and should be determined beforehand.
-* -n NUM: Number of memory channels per processor socket
+* ``-n NUM``:
+ Number of memory channels per processor socket.
-* -b <domain:bus:devid.func>: blacklisting of ports; prevent EAL from using specified PCI device (multiple -b options are allowed)
+* ``-b <domain:bus:devid.func>``:
+ Blacklisting of ports; prevent EAL from using specified PCI device
+ (multiple ``-b`` options are allowed).
-* --use-device: use the specified Ethernet device(s) only. Use comma-separate <[domain:]bus:devid.func> values. Cannot be used with -b option
+* ``--use-device``:
+ use the specified Ethernet device(s) only. Use comma-separate
+ ``[domain:]bus:devid.func`` values. Cannot be used with ``-b`` option.
-* --socket-mem: Memory to allocate from hugepages on specific sockets
+* ``--socket-mem``:
+ Memory to allocate from hugepages on specific sockets.
-* -m MB: Memory to allocate from hugepages, regardless of processor socket. It is recommended that --socket-mem be used instead of this option.
+* ``-m MB``:
+ Memory to allocate from hugepages, regardless of processor socket. It is
+ recommended that ``--socket-mem`` be used instead of this option.
-* -r NUM: Number of memory ranks
+* ``-r NUM``:
+ Number of memory ranks.
-* -v: Display version information on startup
+* ``-v``:
+ Display version information on startup.
-* --huge-dir: The directory where hugetlbfs is mounted
+* ``--huge-dir``:
+ The directory where hugetlbfs is mounted.
-* --file-prefix: The prefix text used for hugepage filenames
+* ``--file-prefix``:
+ The prefix text used for hugepage filenames.
-* --proc-type: The type of process instance
+* ``--proc-type``:
+ The type of process instance.
-* --xen-dom0: Support application running on Xen Domain0 without hugetlbfs
+* ``--xen-dom0``:
+ Support application running on Xen Domain0 without hugetlbfs.
-* --vmware-tsc-map: use VMware TSC map instead of native RDTSC
+* ``--vmware-tsc-map``:
+ Use VMware TSC map instead of native RDTSC.
-* --base-virtaddr: specify base virtual address
+* ``--base-virtaddr``:
+ Specify base virtual address.
-* --vfio-intr: specify interrupt type to be used by VFIO (has no effect if VFIO is not used)
+* ``--vfio-intr``:
+ Specify interrupt type to be used by VFIO (has no effect if VFIO is not used).
-The -c and the -n options are mandatory; the others are optional.
+The ``-c`` and option is mandatory; the others are optional.
Copy the DPDK application binary to your target, then run the application as follows
(assuming the platform has four memory channels per processor socket,
-and that cores 0-3 are present and are to be used for running the application):
-
-.. code-block:: console
+and that cores 0-3 are present and are to be used for running the application)::
- user@target:~$ ./helloworld -c f -n 4
+ ./helloworld -c f -n 4
.. note::
- The --proc-type and --file-prefix EAL options are used for running multiple DPDK processes.
- See the “Multi-process Sample Application” chapter in the *DPDK Sample Applications User Guide* and
- the *DPDK Programmers Guide* for more details.
+ The ``--proc-type`` and ``--file-prefix`` EAL options are used for running
+ multiple DPDK processes. See the "Multi-process Sample Application"
+ chapter in the *DPDK Sample Applications User Guide* and the *DPDK
+ Programmers Guide* for more details.
Logical Core Use by Applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -168,16 +191,14 @@ Since these logical core numbers, and their mapping to specific cores on specifi
it is recommended that the core layout for each platform be considered when choosing the coremask to use in each case.
On initialization of the EAL layer by an DPDK application, the logical cores to be used and their socket location are displayed.
-This information can also be determined for all cores on the system by examining the /proc/cpuinfo file, for example, by running cat /proc/cpuinfo.
+This information can also be determined for all cores on the system by examining the ``/proc/cpuinfo`` file, for example, by running cat ``/proc/cpuinfo``.
The physical id attribute listed for each processor indicates the CPU socket to which it belongs.
This can be useful when using other processors to understand the mapping of the logical cores to the sockets.
.. note::
- A more graphical view of the logical core layout may be obtained using the lstopo Linux utility.
- On Fedora* Linux, this may be installed and run using the following command:
-
-.. code-block:: console
+ A more graphical view of the logical core layout may be obtained using the ``lstopo`` Linux utility.
+ On Fedora Linux, this may be installed and run using the following command::
sudo yum install hwloc
./lstopo
@@ -191,25 +212,25 @@ Hugepage Memory Use by Applications
When running an application, it is recommended to use the same amount of memory as that allocated for hugepages.
This is done automatically by the DPDK application at startup,
-if no -m or --socket-mem parameter is passed to it when run.
+if no ``-m`` or ``--socket-mem`` parameter is passed to it when run.
-If more memory is requested by explicitly passing a -m or --socket-mem value, the application fails.
-However, the application itself can also fail if the user requests less memory than the reserved amount of hugepage-memory, particularly if using the -m option.
+If more memory is requested by explicitly passing a ``-m`` or ``--socket-mem`` value, the application fails.
+However, the application itself can also fail if the user requests less memory than the reserved amount of hugepage-memory, particularly if using the ``-m`` option.
The reason is as follows.
Suppose the system has 1024 reserved 2 MB pages in socket 0 and 1024 in socket 1.
If the user requests 128 MB of memory, the 64 pages may not match the constraints:
* The hugepage memory by be given to the application by the kernel in socket 1 only.
In this case, if the application attempts to create an object, such as a ring or memory pool in socket 0, it fails.
- To avoid this issue, it is recommended that the -- socket-mem option be used instead of the -m option.
+ To avoid this issue, it is recommended that the ``--socket-mem`` option be used instead of the ``-m`` option.
* These pages can be located anywhere in physical memory, and, although the DPDK EAL will attempt to allocate memory in contiguous blocks,
it is possible that the pages will not be contiguous. In this case, the application is not able to allocate big memory pools.
The socket-mem option can be used to request specific amounts of memory for specific sockets.
-This is accomplished by supplying the --socket-mem flag followed by amounts of memory requested on each socket,
-for example, supply --socket-mem=0,512 to try and reserve 512 MB for socket 1 only.
-Similarly, on a four socket system, to allocate 1 GB memory on each of sockets 0 and 2 only, the parameter --socket-mem=1024,0,1024 can be used.
+This is accomplished by supplying the ``--socket-mem`` flag followed by amounts of memory requested on each socket,
+for example, supply ``--socket-mem=0,512`` to try and reserve 512 MB for socket 1 only.
+Similarly, on a four socket system, to allocate 1 GB memory on each of sockets 0 and 2 only, the parameter ``--socket-mem=1024,0,1024`` can be used.
No memory will be reserved on any CPU socket that is not explicitly referenced, for example, socket 3 in this case.
If the DPDK cannot allocate enough memory on each socket, the EAL initialization fails.
diff --git a/doc/guides/linux_gsg/enable_func.rst b/doc/guides/linux_gsg/enable_func.rst
index 0105a82..c3fa6d3 100644
--- a/doc/guides/linux_gsg/enable_func.rst
+++ b/doc/guides/linux_gsg/enable_func.rst
@@ -47,11 +47,9 @@ The BIOS is typically accessed by pressing F2 while the platform is starting up.
The user can then navigate to the HPET option. On the Crystal Forest platform BIOS, the path is:
**Advanced -> PCH-IO Configuration -> High Precision Timer ->** (Change from Disabled to Enabled if necessary).
-On a system that has already booted, the following command can be issued to check if HPET is enabled:
+On a system that has already booted, the following command can be issued to check if HPET is enabled::
-.. code-block:: console
-
- # grep hpet /proc/timer_list
+ grep hpet /proc/timer_list
If no entries are returned, HPET must be enabled in the BIOS (as per the instructions above) and the system rebooted.
@@ -59,75 +57,84 @@ Linux Kernel Support
~~~~~~~~~~~~~~~~~~~~
The DPDK makes use of the platform HPET timer by mapping the timer counter into the process address space, and as such,
-requires that the HPET_MMAP kernel configuration option be enabled.
+requires that the ``HPET_MMAP`` kernel configuration option be enabled.
.. warning::
- On Fedora*, and other common distributions such as Ubuntu*, the HPET_MMAP kernel option is not enabled by default.
+ On Fedora, and other common distributions such as Ubuntu, the ``HPET_MMAP`` kernel option is not enabled by default.
To recompile the Linux kernel with this option enabled, please consult the distributions documentation for the relevant instructions.
Enabling HPET in the DPDK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By default, HPET support is disabled in the DPDK build configuration files.
-To use HPET, the CONFIG_RTE_LIBEAL_USE_HPET setting should be changed to “y”, which will enable the HPET settings at compile time.
+To use HPET, the ``CONFIG_RTE_LIBEAL_USE_HPET`` setting should be changed to ``y``, which will enable the HPET settings at compile time.
-For an application to use the rte_get_hpet_cycles() and rte_get_hpet_hz() API calls,
+For an application to use the ``rte_get_hpet_cycles()`` and ``rte_get_hpet_hz()`` API calls,
and optionally to make the HPET the default time source for the rte_timer library,
-the new rte_eal_hpet_init() API call should be called at application initialization.
+the new ``rte_eal_hpet_init()`` API call should be called at application initialization.
This API call will ensure that the HPET is accessible, returning an error to the application if it is not,
-for example, if HPET_MMAP is not enabled in the kernel.
+for example, if ``HPET_MMAP`` is not enabled in the kernel.
The application can then determine what action to take, if any, if the HPET is not available at run-time.
.. note::
For applications that require timing APIs, but not the HPET timer specifically,
- it is recommended that the rte_get_timer_cycles() and rte_get_timer_hz() API calls be used instead of the HPET-specific APIs.
- These generic APIs can work with either TSC or HPET time sources, depending on what is requested by an application call to rte_eal_hpet_init(),
+ it is recommended that the ``rte_get_timer_cycles()`` and ``rte_get_timer_hz()`` API calls be used instead of the HPET-specific APIs.
+ These generic APIs can work with either TSC or HPET time sources, depending on what is requested by an application call to ``rte_eal_hpet_init()``,
if any, and on what is available on the system at runtime.
Running DPDK Applications Without Root Privileges
--------------------------------------------------------
Although applications using the DPDK use network ports and other hardware resources directly,
-with a number of small permission adjustments it is possible to run these applications as a user other than “root”.
+with a number of small permission adjustments it is possible to run these applications as a user other than "root".
To do so, the ownership, or permissions, on the following Linux file system objects should be adjusted to ensure that
the Linux user account being used to run the DPDK application has access to them:
-* All directories which serve as hugepage mount points, for example, /mnt/huge
+* All directories which serve as hugepage mount points, for example, ``/mnt/huge``
+
+* The userspace-io device files in ``/dev``, for example, ``/dev/uio0``, ``/dev/uio1``, and so on
-* The userspace-io device files in /dev, for example, /dev/uio0, /dev/uio1, and so on
+* The userspace-io sysfs config and resource files, for example for ``uio0``::
-* The userspace-io sysfs config and resource files, for example for uio0: /sys/class/uio/uio0/device/config /sys/class/uio/uio0/device/resource*
+ /sys/class/uio/uio0/device/config
+ /sys/class/uio/uio0/device/resource*
-* If the HPET is to be used, /dev/hpet
+* If the HPET is to be used, ``/dev/hpet``
.. note::
- On some Linux installations, /dev/hugepages is also a hugepage mount point created by default.
+ On some Linux installations, ``/dev/hugepages`` is also a hugepage mount point created by default.
Power Management and Power Saving Functionality
-----------------------------------------------
Enhanced Intel SpeedStep® Technology must be enabled in the platform BIOS if the power management feature of DPDK is to be used.
-Otherwise, the sys file folder /sys/devices/system/cpu/cpu0/cpufreq will not exist, and the CPU frequency- based power management cannot be used.
+Otherwise, the sys file folder ``/sys/devices/system/cpu/cpu0/cpufreq`` will not exist, and the CPU frequency- based power management cannot be used.
Consult the relevant BIOS documentation to determine how these settings can be accessed.
-For example, on some Intel reference platform BIOS variants, the path to Enhanced Intel SpeedStep® Technology is:
+For example, on some Intel reference platform BIOS variants, the path to Enhanced Intel SpeedStep® Technology is::
-**Advanced->Processor Configuration->Enhanced Intel SpeedStep® Tech**
+ Advanced
+ -> Processor Configuration
+ -> Enhanced Intel SpeedStep® Tech
-In addition, C3 and C6 should be enabled as well for power management. The path of C3 and C6 on the same platform BIOS is:
+In addition, C3 and C6 should be enabled as well for power management. The path of C3 and C6 on the same platform BIOS is::
-**Advanced->Processor Configuration->Processor C3 Advanced->Processor Configuration-> Processor C6**
+ Advanced
+ -> Processor Configuration
+ -> Processor C3 Advanced
+ -> Processor Configuration
+ -> Processor C6
-Using Linux* Core Isolation to Reduce Context Switches
-------------------------------------------------------
+Using Linux Core Isolation to Reduce Context Switches
+-----------------------------------------------------
While the threads used by an DPDK application are pinned to logical cores on the system,
it is possible for the Linux scheduler to run other tasks on those cores also.
To help prevent additional workloads from running on those cores,
-it is possible to use the isolcpus Linux* kernel parameter to isolate them from the general Linux scheduler.
+it is possible to use the ``isolcpus`` Linux kernel parameter to isolate them from the general Linux scheduler.
For example, if DPDK applications are to run on logical cores 2, 4 and 6,
the following should be added to the kernel parameter list:
@@ -137,38 +144,38 @@ the following should be added to the kernel parameter list:
isolcpus=2,4,6
Loading the DPDK KNI Kernel Module
------------------------------------------
+----------------------------------
To run the DPDK Kernel NIC Interface (KNI) sample application, an extra kernel module (the kni module) must be loaded into the running kernel.
The module is found in the kmod sub-directory of the DPDK target directory.
-Similar to the loading of the igb_uio module, this module should be loaded using the insmod command as shown below
+Similar to the loading of the ``igb_uio`` module, this module should be loaded using the insmod command as shown below
(assuming that the current directory is the DPDK target directory):
.. code-block:: console
- #insmod kmod/rte_kni.ko
+ insmod kmod/rte_kni.ko
.. note::
- See the “Kernel NIC Interface Sample Application” chapter in the *DPDK Sample Applications User Guide* for more details.
+ See the "Kernel NIC Interface Sample Application" chapter in the *DPDK Sample Applications User Guide* for more details.
Using Linux IOMMU Pass-Through to Run DPDK with Intel® VT-d
-----------------------------------------------------------
To enable Intel® VT-d in a Linux kernel, a number of kernel configuration options must be set. These include:
-* IOMMU_SUPPORT
+* ``IOMMU_SUPPORT``
-* IOMMU_API
+* ``IOMMU_API``
-* INTEL_IOMMU
+* ``INTEL_IOMMU``
-In addition, to run the DPDK with Intel® VT-d, the iommu=pt kernel parameter must be used when using igb_uio driver.
+In addition, to run the DPDK with Intel® VT-d, the ``iommu=pt`` kernel parameter must be used when using ``igb_uio`` driver.
This results in pass-through of the DMAR (DMA Remapping) lookup in the host.
-Also, if INTEL_IOMMU_DEFAULT_ON is not set in the kernel, the intel_iommu=on kernel parameter must be used too.
+Also, if ``INTEL_IOMMU_DEFAULT_ON`` is not set in the kernel, the ``intel_iommu=on`` kernel parameter must be used too.
This ensures that the Intel IOMMU is being initialized as expected.
-Please note that while using iommu=pt is compulsory for igb_uio driver, the vfio-pci driver can actually work with both iommu=pt and iommu=on.
+Please note that while using ``iommu=pt`` is compulsory for ``igb_uio driver``, the ``vfio-pci`` driver can actually work with both ``iommu=pt`` and ``iommu=on``.
High Performance of Small Packets on 40G NIC
--------------------------------------------
@@ -182,12 +189,12 @@ DPDK release, so currently the validated firmware version is 4.2.6.
Enabling Extended Tag and Setting Max Read Request Size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-PCI configurations of extended_tag and max _read_requ st_size have big impacts on performance of small packets on 40G NIC.
-Enabling extended_tag and setting max _read_requ st_size to small size such as 128 bytes provide great helps to high performance of small packets.
+PCI configurations of ``extended_tag`` and max _read_requ st_size have big impacts on performance of small packets on 40G NIC.
+Enabling extended_tag and setting ``max_read_request_size`` to small size such as 128 bytes provide great helps to high performance of small packets.
* These can be done in some BIOS implementations.
-* For other BIOS implementations, PCI configurations can be changed by using command of setpci, or special configurations in DPDK config file of common_linux.
+* For other BIOS implementations, PCI configurations can be changed by using command of ``setpci``, or special configurations in DPDK config file of ``common_linux``.
* Bits 7:5 at address of 0xA8 of each PCI device is used for setting the max_read_request_size,
and bit 8 of 0xA8 of each PCI device is used for enabling/disabling the extended_tag.
@@ -195,24 +202,24 @@ Enabling extended_tag and setting max _read_requ st_size to small size such as 1
* In config file of common_linux, below three configurations can be changed for the same purpose.
- CONFIG_RTE_PCI_CONFIG
+ ``CONFIG_RTE_PCI_CONFIG``
- CONFIG_RTE_PCI_EXTENDED_TAG
+ ``CONFIG_RTE_PCI_EXTENDED_TAG``
- CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE
+ ``CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE``
Use 16 Bytes RX Descriptor Size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As i40e PMD supports both 16 and 32 bytes RX descriptor sizes, and 16 bytes size can provide helps to high performance of small packets.
-Configuration of CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC in config files can be changed to use 16 bytes size RX descriptors.
+Configuration of ``CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC`` in config files can be changed to use 16 bytes size RX descriptors.
High Performance and per Packet Latency Tradeoff
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Due to the hardware design, the interrupt signal inside NIC is needed for per
packet descriptor write-back. The minimum interval of interrupts could be set
-at compile time by CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL in configuration files.
+at compile time by ``CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL`` in configuration files.
Though there is a default configuration, the interval could be tuned by the
users with that configuration item depends on what the user cares about more,
performance or per packet latency.
diff --git a/doc/guides/linux_gsg/intro.rst b/doc/guides/linux_gsg/intro.rst
index a6ee188..eef7e83 100644
--- a/doc/guides/linux_gsg/intro.rst
+++ b/doc/guides/linux_gsg/intro.rst
@@ -33,7 +33,7 @@ Introduction
This document contains instructions for installing and configuring the Intel® Data Plane Development Kit (DPDK) software.
It is designed to get customers up and running quickly.
-The document describes how to compile and run a DPDK application in a Linux* application (linuxapp) environment,
+The document describes how to compile and run a DPDK application in a Linux application (linuxapp) environment,
without going deeply into detail.
Documentation Roadmap
@@ -48,7 +48,7 @@ The following is a list of DPDK documents in the suggested reading order:
* Programmer's Guide: Describes:
- * The software architecture and how to use it (through examples), specifically in a Linux* application (linuxapp) environment
+ * The software architecture and how to use it (through examples), specifically in a Linux application (linuxapp) environment
* The content of the DPDK, the build system (including the commands that can be used in the root DPDK Makefile to build the development kit and
an application) and guidelines for porting an application
@@ -61,7 +61,3 @@ The following is a list of DPDK documents in the suggested reading order:
* Sample Applications User Guide: Describes a set of sample applications.
Each chapter describes a sample application that showcases specific functionality and provides instructions on how to compile, run and use the sample application.
-
-.. note::
-
- These documents are available for download as a separate documentation package at the same location as the DPDK code package.
diff --git a/doc/guides/linux_gsg/quick_start.rst b/doc/guides/linux_gsg/quick_start.rst
index b07fc87..1e0f8ff 100644
--- a/doc/guides/linux_gsg/quick_start.rst
+++ b/doc/guides/linux_gsg/quick_start.rst
@@ -28,6 +28,8 @@
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+.. _linux_setup_script:
+
Quick Start Setup Script
========================
@@ -51,7 +53,7 @@ The setup.sh script, found in the tools subdirectory, allows the user to perform
* Look at hugepages in the meminfo
-* List hugepages in /mnt/huge
+* List hugepages in ``/mnt/huge``
* Remove built DPDK libraries
@@ -106,7 +108,7 @@ Some options in the script prompt the user for further data before proceeding.
.. code-block:: console
- user@host:~/rte$ source tools/setup.sh
+ source tools/setup.sh
------------------------------------------------------------------------
@@ -202,7 +204,7 @@ Some options in the script prompt the user for further data before proceeding.
Option:
-The following selection demonstrates the creation of the x86_64-native-linuxapp-gcc DPDK library.
+The following selection demonstrates the creation of the ``x86_64-native-linuxapp-gcc`` DPDK library.
.. code-block:: console
@@ -214,7 +216,7 @@ The following selection demonstrates the creation of the x86_64-native-linuxapp-
== Build lib
...
Build complete
- RTE_TARGET exported as x86_64-native -linuxapp-gcc
+ RTE_TARGET exported as x86_64-native-linuxapp-gcc
The following selection demonstrates the starting of the DPDK UIO driver.
@@ -277,15 +279,16 @@ the logical core layout of the platform should be determined when selecting a co
.. code-block:: console
- rte@rte-desktop:~/rte/examples$ cd helloworld/
- rte@rte-desktop:~/rte/examples/helloworld$ make
- CC main.o
- LD helloworld
- INSTALL-APP helloworld
- INSTALL-MAP helloworld.map
+ cd helloworld/
+ make
+ CC main.o
+ LD helloworld
+ INSTALL-APP helloworld
+ INSTALL-MAP helloworld.map
- rte@rte-desktop:~/rte/examples/helloworld$ sudo ./build/app/helloworld -c 0xf -n 3
+ sudo ./build/app/helloworld -c 0xf -n 3
[sudo] password for rte:
+
EAL: coremask set to f
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 0 on socket 1
diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst
index ef01944..a20a407 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -28,7 +28,6 @@
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
System Requirements
===================
@@ -37,7 +36,7 @@ This chapter describes the packages required to compile the DPDK.
.. note::
If the DPDK is being used on an Intel® Communications Chipset 89xx Series platform,
- please consult the *Intel® Communications Chipset 89xx Series Software for Linux* Getting Started Guide*.
+ please consult the *Intel® Communications Chipset 89xx Series Software for Linux Getting Started Guide*.
BIOS Setting Prerequisite on x86
--------------------------------
@@ -45,7 +44,7 @@ BIOS Setting Prerequisite on x86
For the majority of platforms, no special BIOS settings are needed to use basic DPDK functionality.
However, for additional HPET timer and power management functionality,
and high performance of small packets on 40G NIC, BIOS setting changes may be needed.
-Consult :ref:`Chapter 5. Enabling Additional Functionality <Enabling_Additional_Functionality>`
+Consult the section on :ref:`Enabling Additional Functionality <Enabling_Additional_Functionality>`
for more information on the required changes.
Compilation of the DPDK
@@ -55,17 +54,17 @@ Compilation of the DPDK
.. note::
- Testing has been performed using Fedora* 18. The setup commands and installed packages needed on other systems may be different.
+ Testing has been performed using Fedora 18. The setup commands and installed packages needed on other systems may be different.
For details on other Linux distributions and the versions tested, please consult the DPDK Release Notes.
-* GNU make
+* GNU ``make``.
-* coreutils: cmp, sed, grep, arch
+* coreutils: ``cmp``, ``sed``, ``grep``, ``arch``, etc.
-* gcc: versions 4.5.x or later is recommended for i686/x86_64. versions 4.8.x or later is recommended
- for ppc_64 and x86_x32 ABI. On some distributions, some specific compiler flags and linker flags are enabled by
- default and affect performance (- fstack-protector, for example). Please refer to the documentation
- of your distribution and to gcc -dumpspecs.
+* gcc: versions 4.5.x or later is recommended for ``i686/x86_64``. Versions 4.8.x or later is recommended
+ for ``ppc_64`` and ``x86_x32`` ABI. On some distributions, some specific compiler flags and linker flags are enabled by
+ default and affect performance (``-fstack-protector``, for example). Please refer to the documentation
+ of your distribution and to ``gcc -dumpspecs``.
* libc headers (glibc-devel.i686 / libc6-dev-i386; glibc-devel.x86_64 for 64-bit compilation on Intel
architecture; glibc-devel.ppc64 for 64 bit IBM Power architecture;)
@@ -75,9 +74,9 @@ Compilation of the DPDK
* Additional packages required for 32-bit compilation on 64-bit systems are:
- glibc.i686, libgcc.i686, libstdc++.i686 and glibc-devel.i686 for Intel i686/x86_64;
+ * glibc.i686, libgcc.i686, libstdc++.i686 and glibc-devel.i686 for Intel i686/x86_64;
- glibc.ppc64, libgcc.ppc64, libstdc++.ppc64 and glibc-devel.ppc64 for IBM ppc_64;
+ * glibc.ppc64, libgcc.ppc64, libstdc++.ppc64 and glibc-devel.ppc64 for IBM ppc_64;
.. note::
@@ -86,21 +85,20 @@ Compilation of the DPDK
.. note::
- Python, version 2.6 or 2.7, to use various helper scripts included in the DPDK package
+ Python, version 2.6 or 2.7, to use various helper scripts included in the DPDK package.
**Optional Tools:**
-* Intel® C++ Compiler (icc). For installation, additional libraries may be required.
+* Intel® C++ Compiler (icc). For installation, additional libraries may be required.
See the icc Installation Guide found in the Documentation directory under the compiler installation.
- This release has been tested using version 12.1.
* IBM® Advance ToolChain for Powerlinux. This is a set of open source development tools and runtime libraries
which allows users to take leading edge advantage of IBM's latest POWER hardware features on Linux. To install
it, see the IBM official installation document.
* libpcap headers and libraries (libpcap-devel) to compile and use the libpcap-based poll-mode driver.
- This driver is disabled by default and can be enabled by setting CONFIG_RTE_LIBRTE_PMD_PCAP=y in the build time config file.
+ This driver is disabled by default and can be enabled by setting ``CONFIG_RTE_LIBRTE_PMD_PCAP=y`` in the build time config file.
Running DPDK Applications
-------------------------
@@ -114,29 +112,17 @@ System Software
* Kernel version >= 2.6.34
- The kernel version in use can be checked using the command:
-
- .. code-block:: console
+ The kernel version in use can be checked using the command::
uname -r
* glibc >= 2.7 (for features related to cpuset)
- The version can be checked using the ldd --version command. A sample output is shown below:
-
- .. code-block:: console
-
- # ldd --version
-
- ldd (GNU libc) 2.14.90
- Copyright (C) 2011 Free Software Foundation, Inc.
- This is free software; see the source for copying conditions. There is NO
- warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
- Written by Roland McGrath and Ulrich Drepper.
+ The version can be checked using the ``ldd --version`` command.
* Kernel configuration
- In the Fedora* OS and other common distributions, such as Ubuntu*, or Red Hat Enterprise Linux*,
+ In the Fedora OS and other common distributions, such as Ubuntu, or Red Hat Enterprise Linux,
the vendor supplied kernel configurations can be used to run most DPDK applications.
For other kernel builds, options which should be enabled for DPDK include:
@@ -148,15 +134,15 @@ System Software
* PROC_PAGE_MONITOR support
* HPET and HPET_MMAP configuration options should also be enabled if HPET support is required.
- See :ref:`Section 5.1 High Precision Event Timer (HPET) Functionality <High_Precision_Event_Timer>` for more details.
+ See the section on :ref:`High Precision Event Timer (HPET) Functionality <High_Precision_Event_Timer>` for more details.
.. _linux_gsg_hugepages:
-Use of Hugepages in the Linux* Environment
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Use of Hugepages in the Linux Environment
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hugepage support is required for the large memory pool allocation used for packet buffers
-(the HUGETLBFS option must be enabled in the running kernel as indicated in Section 2.3).
+(the HUGETLBFS option must be enabled in the running kernel as indicated the previous section).
By using hugepage allocations, performance is increased since fewer pages are needed,
and therefore less Translation Lookaside Buffers (TLBs, high speed translation caches),
which reduce the time it takes to translate a virtual page address to a physical page address.
@@ -167,19 +153,15 @@ Reserving Hugepages for DPDK Use
The allocation of hugepages should be done at boot time or as soon as possible after system boot
to prevent memory from being fragmented in physical memory.
-To reserve hugepages at boot time, a parameter is passed to the Linux* kernel on the kernel command line.
-
-For 2 MB pages, just pass the hugepages option to the kernel. For example, to reserve 1024 pages of 2 MB, use:
+To reserve hugepages at boot time, a parameter is passed to the Linux kernel on the kernel command line.
-.. code-block:: console
+For 2 MB pages, just pass the hugepages option to the kernel. For example, to reserve 1024 pages of 2 MB, use::
hugepages=1024
For other hugepage sizes, for example 1G pages, the size must be specified explicitly and
can also be optionally set as the default hugepage size for the system.
-For example, to reserve 4G of hugepage memory in the form of four 1G pages, the following options should be passed to the kernel:
-
-.. code-block:: console
+For example, to reserve 4G of hugepage memory in the form of four 1G pages, the following options should be passed to the kernel::
default_hugepagesz=1G hugepagesz=1G hugepages=4
@@ -197,21 +179,17 @@ In the case of a dual-socket NUMA system,
the number of hugepages reserved at boot time is generally divided equally between the two sockets
(on the assumption that sufficient memory is present on both sockets).
-See the Documentation/kernel-parameters.txt file in your Linux* source tree for further details of these and other kernel options.
+See the Documentation/kernel-parameters.txt file in your Linux source tree for further details of these and other kernel options.
**Alternative:**
For 2 MB pages, there is also the option of allocating hugepages after the system has booted.
-This is done by echoing the number of hugepages required to a nr_hugepages file in the /sys/devices/ directory.
-For a single-node system, the command to use is as follows (assuming that 1024 pages are required):
-
-.. code-block:: console
+This is done by echoing the number of hugepages required to a nr_hugepages file in the ``/sys/devices/`` directory.
+For a single-node system, the command to use is as follows (assuming that 1024 pages are required)::
echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
-On a NUMA machine, pages should be allocated explicitly on separate nodes:
-
-.. code-block:: console
+On a NUMA machine, pages should be allocated explicitly on separate nodes::
echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
echo 1024 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
@@ -223,29 +201,23 @@ On a NUMA machine, pages should be allocated explicitly on separate nodes:
Using Hugepages with the DPDK
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Once the hugepage memory is reserved, to make the memory available for DPDK use, perform the following steps:
-
-.. code-block:: console
+Once the hugepage memory is reserved, to make the memory available for DPDK use, perform the following steps::
mkdir /mnt/huge
mount -t hugetlbfs nodev /mnt/huge
-The mount point can be made permanent across reboots, by adding the following line to the /etc/fstab file:
-
-.. code-block:: console
+The mount point can be made permanent across reboots, by adding the following line to the ``/etc/fstab`` file::
nodev /mnt/huge hugetlbfs defaults 0 0
-For 1GB pages, the page size must be specified as a mount option:
-
-.. code-block:: console
+For 1GB pages, the page size must be specified as a mount option::
nodev /mnt/huge_1GB hugetlbfs pagesize=1GB 0 0
-Xen Domain0 Support in the Linux* Environment
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Xen Domain0 Support in the Linux Environment
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The existing memory management implementation is based on the Linux* kernel hugepage mechanism.
+The existing memory management implementation is based on the Linux kernel hugepage mechanism.
On the Xen hypervisor, hugepage support for DomainU (DomU) Guests means that DPDK applications work as normal for guests.
However, Domain0 (Dom0) does not support hugepages.
@@ -263,11 +235,9 @@ Furthermore, the CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID setting should also be chang
Loading the DPDK rte_dom0_mm Module
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-To run any DPDK application on Xen Dom0, the rte_dom0_mm module must be loaded into the running kernel with rsv_memsize option.
+To run any DPDK application on Xen Dom0, the ``rte_dom0_mm`` module must be loaded into the running kernel with rsv_memsize option.
The module is found in the kmod sub-directory of the DPDK target directory.
-This module should be loaded using the insmod command as shown below (assuming that the current directory is the DPDK target directory):
-
-.. code-block:: console
+This module should be loaded using the insmod command as shown below (assuming that the current directory is the DPDK target directory)::
sudo insmod kmod/rte_dom0_mm.ko rsv_memsize=X
@@ -278,19 +248,15 @@ Configuring Memory for DPDK Use
After the rte_dom0_mm.ko kernel module has been loaded, the user must configure the memory size for DPDK usage.
This is done by echoing the memory size to a memsize file in the /sys/devices/ directory.
-Use the following command (assuming that 2048 MB is required):
-
-.. code-block:: console
+Use the following command (assuming that 2048 MB is required)::
echo 2048 > /sys/kernel/mm/dom0-mm/memsize-mB/memsize
-The user can also check how much memory has already been used:
-
-.. code-block:: console
+The user can also check how much memory has already been used::
cat /sys/kernel/mm/dom0-mm/memsize-mB/memsize_rsvd
-Xen Domain0 does not support NUMA configuration, as a result the --socket-mem command line option is invalid for Xen Domain0.
+Xen Domain0 does not support NUMA configuration, as a result the ``--socket-mem`` command line option is invalid for Xen Domain0.
.. note::
@@ -299,4 +265,4 @@ Xen Domain0 does not support NUMA configuration, as a result the --socket-mem co
Running the DPDK Application on Xen Domain0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-To run the DPDK application on Xen Domain0, an extra command line option --xen-dom0 is required.
+To run the DPDK application on Xen Domain0, an extra command line option ``--xen-dom0`` is required.
--
2.5.0
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support
2015-12-15 8:55 4% ` Thomas Monjalon
@ 2015-12-15 13:51 9% ` Rahul Lakkireddy
2015-12-15 13:57 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Rahul Lakkireddy @ 2015-12-15 13:51 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Felix Marti, Nirranjan Kirubaharan, Kumar A S
Hi Thomas,
On Tuesday, December 12/15/15, 2015 at 00:55:20 -0800, Thomas Monjalon wrote:
> 2015-12-15 14:10, Rahul Lakkireddy:
> > Hi Thomas,
> >
> > I am preparing a v2 of this series where I will be accomodating some
> > more fields to be considered for filtering. However, if the overall
> > approach seems ok to everyone then, should I submit a separate patch
> > for this ABI change announcement ?
>
> Yes, if this announce is not enough:
> http://dpdk.org/browse/dpdk/commit/?id=648e6b3815a35
>
Apart from rte_eth_fdir_flow ABI change mentioned in above link, new
fields will be added to rte_eth_ipv4_flow and rte_eth_ipv6_flow,
which break their ABI.
Also, 4 new flow types will be added, which increases RTE_ETH_FLOW_MAX
from 18 to 22 and breaks the ABI.
Should I send a separate ABI change announce patch for each of them?
Thanks,
Rahul
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH] scripts: fix abi-validator regression when revision is a tag
@ 2015-12-15 13:55 15% Panu Matilainen
2015-12-15 14:16 4% ` Neil Horman
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-15 13:55 UTC (permalink / raw)
To: dev
Commit 9cbae2aa64eb managed to break the only previously supported
case where a tag is used as a revision, due to git show output
differing between tags and other objects. The hash is on the last
line of the output in both cases though so just grab that.
Fixes: 9cbae2aa64eb ("scripts: support any git revisions as ABI validation range")
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
---
scripts/validate-abi.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/validate-abi.sh b/scripts/validate-abi.sh
index 8d7be24..c36ad61 100755
--- a/scripts/validate-abi.sh
+++ b/scripts/validate-abi.sh
@@ -121,8 +121,8 @@ then
cleanup_and_exit 1
fi
-HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null)
-HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null)
+HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null | tail -1)
+HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null | tail -1)
# Make sure our tags exist
res=$(validate_tags)
--
2.5.0
^ permalink raw reply [relevance 15%]
* Re: [dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support
2015-12-15 13:51 9% ` Rahul Lakkireddy
@ 2015-12-15 13:57 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 13:57 UTC (permalink / raw)
To: Rahul Lakkireddy; +Cc: dev, Felix Marti, Nirranjan Kirubaharan, Kumar A S
2015-12-15 19:21, Rahul Lakkireddy:
> Hi Thomas,
>
> On Tuesday, December 12/15/15, 2015 at 00:55:20 -0800, Thomas Monjalon wrote:
> > 2015-12-15 14:10, Rahul Lakkireddy:
> > > Hi Thomas,
> > >
> > > I am preparing a v2 of this series where I will be accomodating some
> > > more fields to be considered for filtering. However, if the overall
> > > approach seems ok to everyone then, should I submit a separate patch
> > > for this ABI change announcement ?
> >
> > Yes, if this announce is not enough:
> > http://dpdk.org/browse/dpdk/commit/?id=648e6b3815a35
> >
>
> Apart from rte_eth_fdir_flow ABI change mentioned in above link, new
> fields will be added to rte_eth_ipv4_flow and rte_eth_ipv6_flow,
> which break their ABI.
>
> Also, 4 new flow types will be added, which increases RTE_ETH_FLOW_MAX
> from 18 to 22 and breaks the ABI.
>
> Should I send a separate ABI change announce patch for each of them?
Yes please send a patch (1 is enough).
You have less than 30 minutes :)
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] doc: announce ABI change for extending filtering support
@ 2015-12-15 14:10 12% Rahul Lakkireddy
2015-12-15 14:27 7% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Rahul Lakkireddy @ 2015-12-15 14:10 UTC (permalink / raw)
To: dev; +Cc: Felix Marti, Kumar Sanghvi, Nirranjan Kirubaharan
Current filtering support will be enhanced to accommodate support
for Chelsio T5 hardware filtering support.
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
---
doc/guides/rel_notes/deprecation.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index f8a41dd..15e766d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -41,3 +41,11 @@ Deprecation Notices
commands (such as RETA update in testpmd). This should impact
CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
It should be integrated in release 2.3.
+
+* ABI changes are planned for rte_eth_ipv4_flow and rte_eth_ipv6_flow to
+ include more fields to be matched against. The release 2.2 does not
+ contain these ABI changes, but release 2.3 will.
+
+* ABI changes are planned for adding four new flow types. This impacts
+ RTE_ETH_FLOW_MAX. The release 2.2 does not contain these ABI changes,
+ but release 2.3 will.
--
2.5.3
^ permalink raw reply [relevance 12%]
* [dpdk-dev] [PATCH] doc: fix ABI announce change for RETA configuration
@ 2015-12-15 14:15 13% Nelio Laranjeiro
2015-12-15 15:58 8% ` Zhang, Helin
0 siblings, 1 reply; 200+ results
From: Nelio Laranjeiro @ 2015-12-15 14:15 UTC (permalink / raw)
To: dev
Replace "entries" by "queues", it clarifies the case.
Fixes: bd3cea78abd8 ("doc: announce ABI change for RETA configuration")
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index f8a41dd..afab2ed 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -16,8 +16,8 @@ Deprecation Notices
must be updated to support 100G link and to have a cleaner link speed API.
* ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
- which handles at most 256 entries (8 bits) while newer NICs support larger
- tables (512 entries).
+ which handles at most 256 queues (8 bits) while newer NICs support larger
+ tables (512 queues).
It should be integrated in release 2.3.
* ABI changes are planned for struct rte_eth_fdir_flow in order to support
--
2.1.4
^ permalink raw reply [relevance 13%]
* Re: [dpdk-dev] [PATCH] scripts: fix abi-validator regression when revision is a tag
2015-12-15 13:55 15% [dpdk-dev] [PATCH] scripts: fix abi-validator regression when revision is a tag Panu Matilainen
@ 2015-12-15 14:16 4% ` Neil Horman
2015-12-15 14:20 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Neil Horman @ 2015-12-15 14:16 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
On Tue, Dec 15, 2015 at 03:55:15PM +0200, Panu Matilainen wrote:
> Commit 9cbae2aa64eb managed to break the only previously supported
> case where a tag is used as a revision, due to git show output
> differing between tags and other objects. The hash is on the last
> line of the output in both cases though so just grab that.
>
> Fixes: 9cbae2aa64eb ("scripts: support any git revisions as ABI validation range")
> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
> ---
> scripts/validate-abi.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/validate-abi.sh b/scripts/validate-abi.sh
> index 8d7be24..c36ad61 100755
> --- a/scripts/validate-abi.sh
> +++ b/scripts/validate-abi.sh
> @@ -121,8 +121,8 @@ then
> cleanup_and_exit 1
> fi
>
> -HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null)
> -HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null)
> +HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null | tail -1)
> +HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null | tail -1)
>
> # Make sure our tags exist
> res=$(validate_tags)
> --
> 2.5.0
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] scripts: fix abi-validator regression when revision is a tag
2015-12-15 14:16 4% ` Neil Horman
@ 2015-12-15 14:20 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 14:20 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
2015-12-15 09:16, Neil Horman:
> On Tue, Dec 15, 2015 at 03:55:15PM +0200, Panu Matilainen wrote:
> > Commit 9cbae2aa64eb managed to break the only previously supported
> > case where a tag is used as a revision, due to git show output
> > differing between tags and other objects. The hash is on the last
> > line of the output in both cases though so just grab that.
> >
> > Fixes: 9cbae2aa64eb ("scripts: support any git revisions as ABI validation range")
> > Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
> > ---
> > scripts/validate-abi.sh | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/scripts/validate-abi.sh b/scripts/validate-abi.sh
> > index 8d7be24..c36ad61 100755
> > --- a/scripts/validate-abi.sh
> > +++ b/scripts/validate-abi.sh
> > @@ -121,8 +121,8 @@ then
> > cleanup_and_exit 1
> > fi
> >
> > -HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null)
> > -HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null)
> > +HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null | tail -1)
> > +HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null | tail -1)
> >
> > # Make sure our tags exist
> > res=$(validate_tags)
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for extending filtering support
2015-12-15 14:10 12% [dpdk-dev] [PATCH] doc: announce ABI change for extending filtering support Rahul Lakkireddy
@ 2015-12-15 14:27 7% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 14:27 UTC (permalink / raw)
To: Rahul Lakkireddy; +Cc: dev, Felix Marti, Nirranjan Kirubaharan, Kumar Sanghvi
2015-12-15 19:40, Rahul Lakkireddy:
> Current filtering support will be enhanced to accommodate support
> for Chelsio T5 hardware filtering support.
>
> Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
> Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index f8a41dd..15e766d 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -41,3 +41,11 @@ Deprecation Notices
> commands (such as RETA update in testpmd). This should impact
> CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
> It should be integrated in release 2.3.
> +
> +* ABI changes are planned for rte_eth_ipv4_flow and rte_eth_ipv6_flow to
> + include more fields to be matched against. The release 2.2 does not
> + contain these ABI changes, but release 2.3 will.
> +
> +* ABI changes are planned for adding four new flow types. This impacts
> + RTE_ETH_FLOW_MAX. The release 2.2 does not contain these ABI changes,
> + but release 2.3 will.
They were already other ABI changes planned for flow director.
So it doesn't hurt to merge this announce, and we'll with the coming patches
if the new flows can be accepted.
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Applied
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH] doc: fix ABI announce change for RETA configuration
2015-12-15 14:15 13% [dpdk-dev] [PATCH] doc: fix ABI announce change for RETA configuration Nelio Laranjeiro
@ 2015-12-15 15:58 8% ` Zhang, Helin
2015-12-15 16:15 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Zhang, Helin @ 2015-12-15 15:58 UTC (permalink / raw)
To: Nelio Laranjeiro, dev
-----Original Message-----
From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
Sent: Tuesday, December 15, 2015 10:15 PM
To: dev@dpdk.org
Cc: Zhang, Helin <helin.zhang@intel.com>; thomas.monjalon@6wind.com; Lu, Wenzhuo <wenzhuo.lu@intel.com>; adrien.mazarguil@6wind.com
Subject: [PATCH] doc: fix ABI announce change for RETA configuration
Replace "entries" by "queues", it clarifies the case.
Fixes: bd3cea78abd8 ("doc: announce ABI change for RETA configuration")
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Acked-by: Helin Zhang <helin.zhang@intel.com>
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH] doc: fix ABI announce change for RETA configuration
2015-12-15 15:58 8% ` Zhang, Helin
@ 2015-12-15 16:15 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 16:15 UTC (permalink / raw)
To: Nelio Laranjeiro; +Cc: dev
> Replace "entries" by "queues", it clarifies the case.
>
> Fixes: bd3cea78abd8 ("doc: announce ABI change for RETA configuration")
>
> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> Acked-by: Helin Zhang <helin.zhang@intel.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 2/2] doc: init next release notes
@ 2015-12-17 11:16 5% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-17 11:16 UTC (permalink / raw)
To: John McNamara; +Cc: dev
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
doc/guides/rel_notes/index.rst | 1 +
doc/guides/rel_notes/release_2_3.rst | 76 ++++++++++++++++++++++++++++++++++++
2 files changed, 77 insertions(+)
create mode 100644 doc/guides/rel_notes/release_2_3.rst
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index e633e13..29013cf 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -36,6 +36,7 @@ Release Notes
:numbered:
rel_description
+ release_2_3
release_2_2
release_2_1
release_2_0
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
new file mode 100644
index 0000000..99de186
--- /dev/null
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -0,0 +1,76 @@
+DPDK Release 2.3
+================
+
+New Features
+------------
+
+
+Resolved Issues
+---------------
+
+EAL
+~~~
+
+
+Drivers
+~~~~~~~
+
+
+Libraries
+~~~~~~~~~
+
+
+Examples
+~~~~~~~~
+
+
+Other
+~~~~~
+
+
+Known Issues
+------------
+
+
+API Changes
+-----------
+
+
+ABI Changes
+-----------
+
+
+Shared Library Versions
+-----------------------
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+ libethdev.so.2
+ librte_acl.so.2
+ librte_cfgfile.so.2
+ librte_cmdline.so.1
+ librte_distributor.so.1
+ librte_eal.so.2
+ librte_hash.so.2
+ librte_ip_frag.so.1
+ librte_ivshmem.so.1
+ librte_jobstats.so.1
+ librte_kni.so.2
+ librte_kvargs.so.1
+ librte_lpm.so.2
+ librte_mbuf.so.2
+ librte_mempool.so.1
+ librte_meter.so.1
+ librte_pipeline.so.2
+ librte_pmd_bond.so.1
+ librte_pmd_ring.so.2
+ librte_port.so.2
+ librte_power.so.1
+ librte_reorder.so.1
+ librte_ring.so.1
+ librte_sched.so.1
+ librte_table.so.2
+ librte_timer.so.1
+ librte_vhost.so.2
--
2.5.2
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf
2015-12-15 8:50 4% ` Ivan Boule
@ 2015-12-18 2:00 4% ` Liu, Jijiang
2015-12-24 13:28 4% ` Ivan Boule
0 siblings, 1 reply; 200+ results
From: Liu, Jijiang @ 2015-12-18 2:00 UTC (permalink / raw)
To: Ivan Boule; +Cc: dev
Hi Boule,
> -----Original Message-----
> From: Ivan Boule [mailto:ivan.boule@6wind.com]
> Sent: Tuesday, December 15, 2015 4:50 PM
> To: Liu, Jijiang
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct
> rte_eth_conf
>
> On 12/14/2015 08:48 AM, Jijiang Liu wrote:
> > In current codes, tunnel configuration information is not stored in a device
> configuration, and it will get nothing if application want to retrieve tunnel
> config, so I think it is necessary to add rte_eth_dev_tunnel_configure()
> function is to do the configurations including flow and classification
> information and store it in a device configuration.
> >
> > And tunneling packet encapsulation operation will benifit from the change.
> >
> > There are more descriptions for the ABI changes below,
> >
> > The struct 'rte_eth_tunnel_conf' is a new, its defination like below,
> > struct rte_eth_tunnel_conf {
> > uint16_t tx_queue;
> > uint16_t filter_type;
> > struct rte_eth_tunnel_flow flow_tnl; };
> >
> > The ABI change announcement of struct 'rte_eth_tunnel_flow' have
> already sent out, refer to [1].
> >
> > [1]http://dpdk.org/ml/archives/dev/2015-December/029837.html.
> >
> > The change of struct 'rte_eth_conf' like below, but it have not finalized yet.
> > struct rte_eth_conf {
> > ...
> > uint32_t dcb_capability_en;
> > struct rte_fdir_conf fdir_conf; /**< FDIR configuration. */
> > struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */
> > struct rte_eth_tunnel_conf
> *tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
> > /**< Tunnel configuration. */
> > };
> >
> > v2 change:
> > Add more description for the change.
> >
> > v3 change:
> > Change ABI announcement description.
> >
> > Signed-off-by: Jijiang Liu <jijiang.liu@intel.com> ---cmdline.c
> > doc/guides/rel_notes/deprecation.rst | 6 ++++++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index 5c458f2..9dbe89e 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -23,3 +23,9 @@ Deprecation Notices
> > * ABI changes are planned for struct rte_eth_tunnel_flow in order to
> extend new fileds to support
> > tunneling packet configuration in unified tunneling APIs. The release 2.2
> does not contain these ABI
> > changes, but release 2.3 will, and no backwards compatibility is planned.
> > +
> > +* ABI changes are planned for the struct rte_eth_conf in order to add
> > +'tunnel_conf' variable
> > + in the struct to store tunnel configuration when using new API
> > +rte_eth_dev_tunnel_configure
> > + (uint8_t port_id, uint16_t rx_queue, struct rte_eth_tunnel_conf *
> > +tunnel_conf) to configure
> > + tunnel flow and classification information. The release 2.2 does
> > +not contain these ABI change,
> > + but release 2.3 will, and no backward compatibility is planned.
> >
> Hi Jijiang,
>
> Can you provide a real use case - I mean an example of a real network
> application - that really needs to save tunnel configurations in a data
> structure associated with a NIC port?
I'm trying to provide a tunneling packet solution in DPDK, which would accelerate de/encapsulation operation of tunneling packet.
It was described at [1],
[1] http://dpdk.org/ml/archives/dev/2015-December/030283.html
Let me provide more details on this, these data structure definition have not fully finalized yet, just for your reference.
We are talking about why tunnel configuration need to be stored.
strucrt rte_eth_tunnel_conf tc;
....
rte_eth_dev_configure(port, ...);
for(...) {rte_eth_rx_queue_setup(port, ...);}
rte_eth_tunnel_config(port, &tc);
Here we need to the configuration when encapsulating tunnel packet.
struct rte_eth_tunnel_conf {
uint16_t rx_queue;
uint16_t tx_queue;
uint16_t filter_type;
struct rte_eth_tunnel_flow flow_tnl;
};
struct rte_eth_tunnel_flow {
enum rte_eth_tunnel_type tunnel_type;
uint64_t tunnel_id; /**< Tunnel ID to match. TNI, VNI... */
uint16_t flags;
struct ether_addr remote_mac;
enum rte_tunnel_iptype ip_type; /**< IP address type. */
union {
struct rte_eth_ipv4_flow outer_ipv4;
struct rte_eth_ipv6_flow outer_ipv6;
} ip_addr;
uint16_t dst_port;
uint16_t src_port;
};
We will do the following configuration,
struct rte_eth_tunnel_conf{
.tunnel_type = VXLAN,
.rx_queue = 1,
.tx_queue = 1,
. filter_type = 'src ip + dst ip + src port + dst port + tunnel id'
.flow_tnl {
. tunnel_type = VXLAN,
. tunnel_id = 100,
. ip_type = ipv4,
. outer_ipv4.src_ip = 192.168.10.1
. outer_ipv4.dst_ip = 10.239.129.11
.src_port = 1000,
.dst_port =2000
};
For NIC A RX process,
VM 0--->VTEP A---> VXLAN network--->VTEP B---NIC A (Rx queue 1 with info [1] )--->SW decapsulation--->vSwitch--->VM 0
For NIC A TX process,
VM 0<---VTEP A<---VXLAN network<---VTEP B<---NIC A (TX queue 1)<---SW Encapsulation with info[2]<---vSwitch<---VM 0
The[2] information will be got by retrieving the tunnel configuration, if the tunnel configuration is not stored in 'rt_eth_conf', and how to get it?
Of course, the tunnel configuration is also stored in Application, does it make sense?
[1] outr src ip(192.168.10.1) + outer dst ip(10.239.129.11) + outer src port(1000) + outer dst port(2000) + tunnel id(100)
[2] outer src ip(10.239.129.11) + outer dst ip(192.168.10.1) + outer src port(2000) + outr dst port(1000) + tunnel id(100)
>
> Firstly, if the only usage is to enable applications to retrieve tunnel
> configurations, then you are simply growing the size of the per-port structure
> with tunnel configurations, and imposing it to every DPDK application.
> You impose it to those applications that don't care about tunneling, but also
> to those applications which do care, but which prefer to have their own
> representation of ports where they store everything they need to.
> If the tunnel configuration is also used for other purposes, then it must be
> precisely described what happens with the saved tunnel configuration when
> the application changes the state of a port.
> This is the case for instance when the application reconfigures the number of
> RX queues of a port.
> Who is responsible for checking that some tunnels won't be matched
> anymore?
> Who is responsible for dropping/invalidating the saved tunnel configuration,
> if such operations must be performed?
> This list is likely to be not exhaustive, of course.
About above these question, it is related to design, I will send RFC patch out for review.
>
> More globally, all side-effects of saving the tunnel configuration must be
> considered and addressed in a coherent way and in an easy-to-use approach.
>
> By the way, as far as I know, the Linux kernel does not [need to] save tunnel
> data or ARP entries behind "netdevice" structures.
It is not related ARP entries, I'm talking about tunnel flow.
> PS : in the "rte_eth_tunnel_conf" data structure, I think that the first field
> should be named "rx_queue" instead of "tx_queue".
No, 'rx_queue' id can be as index of tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
It depends on final design.
> Regards,
> Ivan
>
> --
> Ivan Boule
> 6WIND Development Engineer
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 3/3] doc: rename release 2.3 to 16.04
@ 2015-12-21 13:26 8% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2015-12-21 13:26 UTC (permalink / raw)
To: dev
Update documentation to reflect new numbering scheme
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
doc/guides/rel_notes/index.rst | 2 +-
doc/guides/rel_notes/release_16_04.rst | 83 ++++++++++++++++++++++++++++++++++
doc/guides/rel_notes/release_2_3.rst | 76 -------------------------------
3 files changed, 84 insertions(+), 77 deletions(-)
create mode 100644 doc/guides/rel_notes/release_16_04.rst
delete mode 100644 doc/guides/rel_notes/release_2_3.rst
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index 29013cf..84317b8 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -36,7 +36,7 @@ Release Notes
:numbered:
rel_description
- release_2_3
+ release_16_04
release_2_2
release_2_1
release_2_0
diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
new file mode 100644
index 0000000..2c487c5
--- /dev/null
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -0,0 +1,83 @@
+DPDK Release 16.04
+==================
+
+.. note::
+
+ Following on from the DPDK Release 2.2, the numbering scheme for this
+ project has changed. Releases are now being numbered based off the year
+ and month of release. What would have been DPDK Release 2.3 is now called
+ Release 16.04, as its release date is April 2016.
+
+New Features
+------------
+
+
+Resolved Issues
+---------------
+
+EAL
+~~~
+
+
+Drivers
+~~~~~~~
+
+
+Libraries
+~~~~~~~~~
+
+
+Examples
+~~~~~~~~
+
+
+Other
+~~~~~
+
+
+Known Issues
+------------
+
+
+API Changes
+-----------
+
+
+ABI Changes
+-----------
+
+
+Shared Library Versions
+-----------------------
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+ libethdev.so.2
+ librte_acl.so.2
+ librte_cfgfile.so.2
+ librte_cmdline.so.1
+ librte_distributor.so.1
+ librte_eal.so.2
+ librte_hash.so.2
+ librte_ip_frag.so.1
+ librte_ivshmem.so.1
+ librte_jobstats.so.1
+ librte_kni.so.2
+ librte_kvargs.so.1
+ librte_lpm.so.2
+ librte_mbuf.so.2
+ librte_mempool.so.1
+ librte_meter.so.1
+ librte_pipeline.so.2
+ librte_pmd_bond.so.1
+ librte_pmd_ring.so.2
+ librte_port.so.2
+ librte_power.so.1
+ librte_reorder.so.1
+ librte_ring.so.1
+ librte_sched.so.1
+ librte_table.so.2
+ librte_timer.so.1
+ librte_vhost.so.2
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
deleted file mode 100644
index 99de186..0000000
--- a/doc/guides/rel_notes/release_2_3.rst
+++ /dev/null
@@ -1,76 +0,0 @@
-DPDK Release 2.3
-================
-
-New Features
-------------
-
-
-Resolved Issues
----------------
-
-EAL
-~~~
-
-
-Drivers
-~~~~~~~
-
-
-Libraries
-~~~~~~~~~
-
-
-Examples
-~~~~~~~~
-
-
-Other
-~~~~~
-
-
-Known Issues
-------------
-
-
-API Changes
------------
-
-
-ABI Changes
------------
-
-
-Shared Library Versions
------------------------
-
-The libraries prepended with a plus sign were incremented in this version.
-
-.. code-block:: diff
-
- libethdev.so.2
- librte_acl.so.2
- librte_cfgfile.so.2
- librte_cmdline.so.1
- librte_distributor.so.1
- librte_eal.so.2
- librte_hash.so.2
- librte_ip_frag.so.1
- librte_ivshmem.so.1
- librte_jobstats.so.1
- librte_kni.so.2
- librte_kvargs.so.1
- librte_lpm.so.2
- librte_mbuf.so.2
- librte_mempool.so.1
- librte_meter.so.1
- librte_pipeline.so.2
- librte_pmd_bond.so.1
- librte_pmd_ring.so.2
- librte_port.so.2
- librte_power.so.1
- librte_reorder.so.1
- librte_ring.so.1
- librte_sched.so.1
- librte_table.so.2
- librte_timer.so.1
- librte_vhost.so.2
--
2.5.0
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [RFC v2 0/2] ethdev: Enhancements to flow director filter
2015-12-10 14:01 4% [dpdk-dev] [RFC 0/3] ethdev: Enhancements to flow director filter Rahul Lakkireddy
2015-12-10 14:01 4% ` [dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support Rahul Lakkireddy
@ 2015-12-23 12:41 3% ` Rahul Lakkireddy
2016-01-11 13:50 0% ` Rahul Lakkireddy
2 siblings, 1 reply; 200+ results
From: Rahul Lakkireddy @ 2015-12-23 12:41 UTC (permalink / raw)
To: dev; +Cc: Felix Marti, Kumar Sanghvi, Nirranjan Kirubaharan
This RFC series of patches attempt to extend the flow director filter to
add support for Chelsio T5 hardware filtering capabilities.
Chelsio T5 supports carrying out filtering in hardware which supports 3
actions to carry out on a packet which hit a filter viz.
1. Action Pass - Packets hitting a filter rule can be directed to a
particular RXQ.
2. Action Drop - Packets hitting a filter rule are dropped in h/w.
3. Action Switch - Packets hitting a filter rule can be switched in h/w
from one port to another, without involvement of host. Also, the
action Switch also supports rewrite of src-mac/dst-mac headers as
well as rewrite of vlan headers. It also supports rewrite of IP
headers and thereby, supports NAT (Network Address Translation)
in h/w.
Also, each filter rule can optionally support specifying a mask value
i.e. it's possible to create a filter rule for an entire subnet of IP
addresses or a range of tcp/udp ports, etc.
Patch 1 does the following:
- Adds an additional flow rte_eth_pkt_filter_flow which encapsulates
ingress ports, l2 payload, vlan and ntuples.
- Adds an additional mask for the flow to allow range of values to be
matched.
- Adds an ability to set both filters with masks (Maskfull) and
without masks (Maskless). Also allow prioritizing one of these
filter types over the other when a packet matches several types.
- Adds a new behavior 'switch'.
- Adds behavior arguments that can be passed when a particular behavior
is taken. For ex: in case of action 'switch', pass additional 4-tuple
to allow rewriting src/dst ip and port addresses to support NAT'ing.
Patch 2 shows testpmd command line example to support packet filter
flow.
The patch series has been compile tested on all x86 gcc targets and the
current fdir filter supported drivers seem to return appropriate error
codes when this new flow type and the new action are not supported and
hence are not affected.
Posting this series mainly for discussion on API change. Once this is
agreeable then, I will post the cxgbe PMD changes to use the new API.
---
v2:
1. Added ttl to rte_eth_ipv4_flow and tc, flow_label, next_header,
and hop_limit to rte_eth_ipv6_flow.
2. Added new field type to rte_eth_pkt_filter_flow to differentiate
between maskfull and maskless filter types.
3. Added new field prio to rte_eth_pkt_filter_flow to allow setting
priority over maskfull or maskless when packet matches multiple
filter types.
4. Added new behavior sub op RTE_FDIR_BEHAVIOR_SUB_OP_SWAP to allow
swapping fields in matched flows. For ex, useful when swapping mac
addresses in hardware before switching.
5. Updated the testpmd example to reflect the above new changes.
6. Dropped Patch 3 since the ABI announcement has already been merged.
Rahul Lakkireddy (2):
ethdev: add packet filter flow and new behavior switch to fdir
testpmd: add an example to show packet filter flow
app/test-pmd/cmdline.c | 528 +++++++++++++++++++++++++++++++++++++++-
lib/librte_ether/rte_eth_ctrl.h | 127 +++++++++-
2 files changed, 646 insertions(+), 9 deletions(-)
--
2.5.3
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf
2015-12-18 2:00 4% ` Liu, Jijiang
@ 2015-12-24 13:28 4% ` Ivan Boule
0 siblings, 0 replies; 200+ results
From: Ivan Boule @ 2015-12-24 13:28 UTC (permalink / raw)
To: Liu, Jijiang; +Cc: dev
Hi Jijiang,
See my comments inline below prefixewd with IB>
Ivan
On 12/18/2015 03:00 AM, Liu, Jijiang wrote:
> Hi Boule,
>
>> -----Original Message-----
>> From: Ivan Boule [mailto:ivan.boule@6wind.com]
>> Sent: Tuesday, December 15, 2015 4:50 PM
>> To: Liu, Jijiang
>> Cc: dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct
>> rte_eth_conf
>>
>> On 12/14/2015 08:48 AM, Jijiang Liu wrote:
>>> In current codes, tunnel configuration information is not stored in a device
>> configuration, and it will get nothing if application want to retrieve tunnel
>> config, so I think it is necessary to add rte_eth_dev_tunnel_configure()
>> function is to do the configurations including flow and classification
>> information and store it in a device configuration.
>>>
>>> And tunneling packet encapsulation operation will benifit from the change.
>>>
>>> There are more descriptions for the ABI changes below,
>>>
>>> The struct 'rte_eth_tunnel_conf' is a new, its defination like below,
>>> struct rte_eth_tunnel_conf {
>>> uint16_t tx_queue;
>>> uint16_t filter_type;
>>> struct rte_eth_tunnel_flow flow_tnl; };
>>>
>>> The ABI change announcement of struct 'rte_eth_tunnel_flow' have
>> already sent out, refer to [1].
>>>
>>> [1]http://dpdk.org/ml/archives/dev/2015-December/029837.html.
>>>
>>> The change of struct 'rte_eth_conf' like below, but it have not finalized yet.
>>> struct rte_eth_conf {
>>> ...
>>> uint32_t dcb_capability_en;
>>> struct rte_fdir_conf fdir_conf; /**< FDIR configuration. */
>>> struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */
>>> struct rte_eth_tunnel_conf
>> *tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
>>> /**< Tunnel configuration. */
>>> };
>>>
>>> v2 change:
>>> Add more description for the change.
>>>
>>> v3 change:
>>> Change ABI announcement description.
>>>
>>> Signed-off-by: Jijiang Liu <jijiang.liu@intel.com> ---cmdline.c
>>> doc/guides/rel_notes/deprecation.rst | 6 ++++++
>>> 1 files changed, 6 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>> b/doc/guides/rel_notes/deprecation.rst
>>> index 5c458f2..9dbe89e 100644
>>> --- a/doc/guides/rel_notes/deprecation.rst
>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>> @@ -23,3 +23,9 @@ Deprecation Notices
>>> * ABI changes are planned for struct rte_eth_tunnel_flow in order to
>> extend new fileds to support
>>> tunneling packet configuration in unified tunneling APIs. The release 2.2
>> does not contain these ABI
>>> changes, but release 2.3 will, and no backwards compatibility is planned.
>>> +
>>> +* ABI changes are planned for the struct rte_eth_conf in order to add
>>> +'tunnel_conf' variable
>>> + in the struct to store tunnel configuration when using new API
>>> +rte_eth_dev_tunnel_configure
>>> + (uint8_t port_id, uint16_t rx_queue, struct rte_eth_tunnel_conf *
>>> +tunnel_conf) to configure
>>> + tunnel flow and classification information. The release 2.2 does
>>> +not contain these ABI change,
>>> + but release 2.3 will, and no backward compatibility is planned.
>>>
>> Hi Jijiang,
>>
>> Can you provide a real use case - I mean an example of a real network
>> application - that really needs to save tunnel configurations in a data
>> structure associated with a NIC port?
>
> I'm trying to provide a tunneling packet solution in DPDK, which would accelerate de/encapsulation operation of tunneling packet.
IB> I was asking for an example of an application that needs to SAVE in
the DPDK structure associated with a port a tunnel configuration that it
applies to that port.
Where does that saved tunnel configuration will participate to the
acceleration of decap/encap ops?
>
> It was described at [1],
> [1] http://dpdk.org/ml/archives/dev/2015-December/030283.html
>
>
> Let me provide more details on this, these data structure definition have not fully finalized yet, just for your reference.
> We are talking about why tunnel configuration need to be stored.
IB? yes :-)
>
> For NIC A RX process,
> VM 0--->VTEP A---> VXLAN network--->VTEP B---NIC A (Rx queue 1 with info [1] )--->SW decapsulation--->vSwitch--->VM 0
>
> For NIC A TX process,
> VM 0<---VTEP A<---VXLAN network<---VTEP B<---NIC A (TX queue 1)<---SW Encapsulation with info[2]<---vSwitch<---VM 0
>
> The[2] information will be got by retrieving the tunnel configuration, if the tunnel configuration is not stored in 'rt_eth_conf', and how to get it?
IB> it is assumed that the encapsulation acceleration relies on having
this operation done in hardware. Am I wrong?
If I am right, then can you tell me which PMD function accesses the
saved tunnel configuration?
>
> Of course, the tunnel configuration is also stored in Application, does it make sense?
IB> No. Why store it twice? Are you considering that memory if available
for free?
>
> [1] outr src ip(192.168.10.1) + outer dst ip(10.239.129.11) + outer src port(1000) + outer dst port(2000) + tunnel id(100)
> [2] outer src ip(10.239.129.11) + outer dst ip(192.168.10.1) + outer src port(2000) + outr dst port(1000) + tunnel id(100)
>
>>
>> Firstly, if the only usage is to enable applications to retrieve tunnel
>> configurations, then you are simply growing the size of the per-port structure
>> with tunnel configurations, and imposing it to every DPDK application.
>> You impose it to those applications that don't care about tunneling, but also
>> to those applications which do care, but which prefer to have their own
>> representation of ports where they store everything they need to.
>> If the tunnel configuration is also used for other purposes, then it must be
>> precisely described what happens with the saved tunnel configuration when
>> the application changes the state of a port.
>> This is the case for instance when the application reconfigures the number of
>> RX queues of a port.
>> Who is responsible for checking that some tunnels won't be matched
>> anymore?
>> Who is responsible for dropping/invalidating the saved tunnel configuration,
>> if such operations must be performed?
>> This list is likely to be not exhaustive, of course.
>
> About above these question, it is related to design, I will send RFC patch out for review.
IB> Do you mean that I will find EXPLICIT answers to those questions in
your RFC patch? If so, why not supply them inline ?
>
>>
>> More globally, all side-effects of saving the tunnel configuration must be
>> considered and addressed in a coherent way and in an easy-to-use approach.
>>
>> By the way, as far as I know, the Linux kernel does not [need to] save tunnel
>> data or ARP entries behind "netdevice" structures.
>
> It is not related ARP entries, I'm talking about tunnel flow.
IB> Really? I did not notice :-)
IB> More seriously, what I meant is that it is a good programming
practice for an application to have its private representation of
low-level objects (a DPDK port here) it uses, and to maintain into it
whatever informations it need to.
I referred to ARP entries as an example of such informations that can be
associated with a port, and thus that might also be saved
in a data structure of the DPDK port. Just to outline that there is no
end to such approach...
>
>> PS : in the "rte_eth_tunnel_conf" data structure, I think that the first field
>> should be named "rx_queue" instead of "tx_queue".
>
> No, 'rx_queue' id can be as index of tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
IB> then, what does the tx_index refer to in in the
"rte_eth_tunnel_conf" data structure, and how is it used, and by which
DPDK code ?
Please, note that by design, the default DPDK rule for the usage of TX
queues consists in having DPDK applications assigning each TX queue of a
port to a different [paquet processing] core, so that each core can
safely transmit paquets through a port in a lockless fashion.
Can you guarantee that your tunneling spec. still comply with this rule?
Regards,
Ivan
--
Ivan Boule
6WIND Development Engineer
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
@ 2015-12-31 17:12 3% ` Stephen Hemminger
2016-01-13 11:55 3% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2015-12-31 17:12 UTC (permalink / raw)
To: Ziye Yang; +Cc: dev
On Tue, 29 Dec 2015 10:53:26 +0800
Ziye Yang <ziye.yang@intel.com> wrote:
> This patch is used to add the class_id support
> for pci_probe since some devices need the class_info
> (class_code, subclass_code, programming_interface)
>
> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
Since rte_pci is exposed to application this breaks the ABI.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface
@ 2016-01-02 18:45 4% ` Jan Viktorin
1 sibling, 0 replies; 200+ results
From: Jan Viktorin @ 2016-01-02 18:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Sat, 2 Jan 2016 10:01:44 -0800
Stephen Hemminger <stephen@networkplumber.org> wrote:
> On Fri, 1 Jan 2016 22:05:20 +0100
> Jan Viktorin <viktorin@rehivetech.com> wrote:
>
> > Introduce the interface to SoC device infrastructure. A SoC device
> > here means a device integrated on the chip via a (simple) bus
> > that lacks of auto-discovery and other properties which are common
> > for PCI. A counterpart in the Linux Kernel would be a platform_device
> > (but this is not necessarily 1:1 mapping).
> >
> > Systems without auto-discovery properties are described by a (Flat)
> > Device Tree. Device Tree is usually available on embedded systems
> > in /proc/device-tree. Every device has a unique path in the Device
> > Tree and so it identifies every such device. This path is used
> > to identify a device in rte_soc_addr.
> >
> > Binding of drivers to devices in the Linux Kernel is often done
> > by matching the compatible entry in the Device Tree. As there is
> > no standard/generic way to read information like vendor, model, etc.
> > from each SoC device, we match devices by the compatible entry too.
> > The rte_soc_id contains an array of compatible strings telling what
> > each device is compatible with.
> >
> > There are no DPDK-specific OS drivers for SoC devices at the moment
> > and unfortunately we cannot use the PCI-related ones as they contain
> > too much PCI-specific logic.
> >
> > Whitelisting and blacklisting of devices is based on the Device Tree
> > identifier (rte_soc_addr) to mimic the PCI behaviour.
> >
> > Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
>
> Yes, DPDK needs to work in embedded environments with device tree.
> Would it be possible reimplement device tree parsing in user space?
This is possible, I've already done a simple library for this few years
ago [1]. However, I don't think it is suitable for DPDK.
> Ideally with a shared code from kernel??
I have no idea what kernel code do you mean to share with... the
drivers/of/*? In userspace, the device-tree is accessible via the
filesystem (/proc/device-tree). So, I cannot see any overlap with
the kernel code.
>
> On a pratical level, the new SoC support must be optional
> (via DPDK config infrastructure), since most architectures won't be using it.
> In most cases, it is better from usability if everything is runtime based,
> but with SoC this is a platform/architecture configuration.
I agree. In this RFC, it is not optional yet. On the EAL level, it's a
matter of the right ifdefs and Makefile conditionals (I think) - it does
not look to be an issue from my point of view.
The problem will arise with the lib/* stuff as eg. librte_ether depends
on pci-specific data structures very deeply. I've just finished a quick
raw librte_ether extension of the SoC devices support trying to preserve
API/ABI. Although, it is hopefully possible to preserve ABI (with SoC
disabled), the code becomes a little bit spagetti-like...
>
> Do you consider this will break binary compatibility since
> sizeof (rte_soc_addr) is PATH_MAX (1024) and the other elements of the
> union inside rte_devargs are much smaller (like 32 bytes).
>
I had a bad feeling about this... Originally, I started with a pointer
'const char *' so it can be done that way... However, this brings
compilator mad as it does not allow to cast char * -> const char *
because of the strict DPDK compilation settings. I didn't find any
workaround yet. I think I can make it just 'char *' for the next version
of the patch set.
[1] https://github.com/jviki/dtree
--
Jan Viktorin E-mail: Viktorin@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface
@ 2016-01-02 18:52 3% ` Jan Viktorin
2016-01-02 19:13 0% ` Wiles, Keith
2016-01-02 19:14 0% ` Stephen Hemminger
0 siblings, 2 replies; 200+ results
From: Jan Viktorin @ 2016-01-02 18:52 UTC (permalink / raw)
To: Wiles, Keith; +Cc: dev
On Sat, 2 Jan 2016 18:35:08 +0000
"Wiles, Keith" <keith.wiles@intel.com> wrote:
> >Yes, DPDK needs to work in embedded environments with device tree.
> >Would it be possible reimplement device tree parsing in user space?
> >Ideally with a shared code from kernel??
>
> Stephen, Do you mean we have to add kernel code to support DPDK on SoC Platforms? If that is the case I would like to not require code be added to the kernel to support DPDK.
We will need a kernel module. But this is not necessarily related to the
device-tree parsing.
> >
> >On a pratical level, the new SoC support must be optional
> >(via DPDK config infrastructure), since most architectures won't be using it.
> >In most cases, it is better from usability if everything is runtime based,
> >but with SoC this is a platform/architecture configuration.
>
> I am not sure I agree with the optional support, as it could be stated that PCI support is optional on SoC platforms. It would be best to not treat SoC support as special compared to PCI support. Other then extra footprint it does not seem reasonable to require SoC support to be ifdef’ed in the code. Plus adding more ifdefs is not a good testing solution.
This is a matter of preserving ABI. Turning PCI-support to be optional
seems to be a difficult step at the moment.
>
> Can we detect somehow we are on a system with SoC support or even a system that supports PCI for that matter?
IMO, we can detect two things: "PCI is present on the system" and
"Device tree is accessible in /proc/device-tree". Is this acceptable?
--
Jan Viktorin E-mail: Viktorin@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface
2016-01-02 18:52 3% ` Jan Viktorin
@ 2016-01-02 19:13 0% ` Wiles, Keith
2016-01-02 19:14 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Wiles, Keith @ 2016-01-02 19:13 UTC (permalink / raw)
To: Jan Viktorin; +Cc: dev
On 1/2/16, 12:52 PM, "Jan Viktorin" <viktorin@rehivetech.com> wrote:
>On Sat, 2 Jan 2016 18:35:08 +0000
>"Wiles, Keith" <keith.wiles@intel.com> wrote:
>
>> >Yes, DPDK needs to work in embedded environments with device tree.
>> >Would it be possible reimplement device tree parsing in user space?
>> >Ideally with a shared code from kernel??
>>
>> Stephen, Do you mean we have to add kernel code to support DPDK on SoC Platforms? If that is the case I would like to not require code be added to the kernel to support DPDK.
>
>We will need a kernel module. But this is not necessarily related to the
>device-tree parsing.
>
>> >
>> >On a pratical level, the new SoC support must be optional
>> >(via DPDK config infrastructure), since most architectures won't be using it.
>> >In most cases, it is better from usability if everything is runtime based,
>> >but with SoC this is a platform/architecture configuration.
>>
>> I am not sure I agree with the optional support, as it could be stated that PCI support is optional on SoC platforms. It would be best to not treat SoC support as special compared to PCI support. Other then extra footprint it does not seem reasonable to require SoC support to be ifdef’ed in the code. Plus adding more ifdefs is not a good testing solution.
>
>This is a matter of preserving ABI. Turning PCI-support to be optional
>seems to be a difficult step at the moment.
Turning off PCI support is bit hard to do as well, I was looking for a way to execute the PCI or SoC code during startup. I think having both compiled into the DPDK , but figure out how to detect if that code needs to be run is the better solution as you have pointed out later.
>
>>
>> Can we detect somehow we are on a system with SoC support or even a system that supports PCI for that matter?
>
>IMO, we can detect two things: "PCI is present on the system" and
>"Device tree is accessible in /proc/device-tree". Is this acceptable?
I guess this would be fine with me, as I do not like us to add ifdefs.
>
>--
> Jan Viktorin E-mail: Viktorin@RehiveTech.com
> System Architect Web: www.RehiveTech.com
> RehiveTech
> Brno, Czech Republic
>
Regards,
Keith
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface
2016-01-02 18:52 3% ` Jan Viktorin
2016-01-02 19:13 0% ` Wiles, Keith
@ 2016-01-02 19:14 0% ` Stephen Hemminger
2016-01-02 19:22 0% ` Wiles, Keith
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2016-01-02 19:14 UTC (permalink / raw)
To: Jan Viktorin; +Cc: dev
On Sat, 2 Jan 2016 19:52:16 +0100
Jan Viktorin <viktorin@rehivetech.com> wrote:
> On Sat, 2 Jan 2016 18:35:08 +0000
> "Wiles, Keith" <keith.wiles@intel.com> wrote:
>
> > >Yes, DPDK needs to work in embedded environments with device tree.
> > >Would it be possible reimplement device tree parsing in user space?
> > >Ideally with a shared code from kernel??
> >
> > Stephen, Do you mean we have to add kernel code to support DPDK on SoC Platforms? If that is the case I would like to not require code be added to the kernel to support DPDK.
>
> We will need a kernel module. But this is not necessarily related to the
> device-tree parsing.
>
> > >
> > >On a pratical level, the new SoC support must be optional
> > >(via DPDK config infrastructure), since most architectures won't be using it.
> > >In most cases, it is better from usability if everything is runtime based,
> > >but with SoC this is a platform/architecture configuration.
> >
> > I am not sure I agree with the optional support, as it could be stated that PCI support is optional on SoC platforms. It would be best to not treat SoC support as special compared to PCI support. Other then extra footprint it does not seem reasonable to require SoC support to be ifdef’ed in the code. Plus adding more ifdefs is not a good testing solution.
>
> This is a matter of preserving ABI. Turning PCI-support to be optional
> seems to be a difficult step at the moment.
>
> >
> > Can we detect somehow we are on a system with SoC support or even a system that supports PCI for that matter?
>
> IMO, we can detect two things: "PCI is present on the system" and
> "Device tree is accessible in /proc/device-tree". Is this acceptable?
>
I am just as concerned with building and having useless code.
For now most environments can just use PCI, and having to carry around
dead code seems wasteful and potential for some security abuse as well.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface
2016-01-02 19:14 0% ` Stephen Hemminger
@ 2016-01-02 19:22 0% ` Wiles, Keith
0 siblings, 0 replies; 200+ results
From: Wiles, Keith @ 2016-01-02 19:22 UTC (permalink / raw)
To: Stephen Hemminger, Jan Viktorin; +Cc: dev
On 1/2/16, 1:14 PM, "Stephen Hemminger" <stephen@networkplumber.org> wrote:
>On Sat, 2 Jan 2016 19:52:16 +0100
>Jan Viktorin <viktorin@rehivetech.com> wrote:
>
>> On Sat, 2 Jan 2016 18:35:08 +0000
>> "Wiles, Keith" <keith.wiles@intel.com> wrote:
>>
>> > >Yes, DPDK needs to work in embedded environments with device tree.
>> > >Would it be possible reimplement device tree parsing in user space?
>> > >Ideally with a shared code from kernel??
>> >
>> > Stephen, Do you mean we have to add kernel code to support DPDK on SoC Platforms? If that is the case I would like to not require code be added to the kernel to support DPDK.
>>
>> We will need a kernel module. But this is not necessarily related to the
>> device-tree parsing.
>>
>> > >
>> > >On a pratical level, the new SoC support must be optional
>> > >(via DPDK config infrastructure), since most architectures won't be using it.
>> > >In most cases, it is better from usability if everything is runtime based,
>> > >but with SoC this is a platform/architecture configuration.
>> >
>> > I am not sure I agree with the optional support, as it could be stated that PCI support is optional on SoC platforms. It would be best to not treat SoC support as special compared to PCI support. Other then extra footprint it does not seem reasonable to require SoC support to be ifdef’ed in the code. Plus adding more ifdefs is not a good testing solution.
>>
>> This is a matter of preserving ABI. Turning PCI-support to be optional
>> seems to be a difficult step at the moment.
>>
>> >
>> > Can we detect somehow we are on a system with SoC support or even a system that supports PCI for that matter?
>>
>> IMO, we can detect two things: "PCI is present on the system" and
>> "Device tree is accessible in /proc/device-tree". Is this acceptable?
>>
>
>I am just as concerned with building and having useless code.
>For now most environments can just use PCI, and having to carry around
>dead code seems wasteful and potential for some security abuse as well.
Hi Stephen,
With including every archive with the include whole archive option means we already have a huge amount of dead code in a DPDK image :-( Adding a bit more is not going to make a difference IMO. Also a system without PCI could be a security abuse too.
I think we just figure out how not to call the PCI or SoC code at runtime if not supported and compile it in always.
>
Regards,
Keith
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH 00/14] Step towards PCI independency
@ 2016-01-04 20:08 2% Jan Viktorin
[not found] ` <CALwxeUtxE5Gd+UvZOHz+fyHSjLi9Tjkc=99QHpag62KV+UP+NA@mail.gmail.com>
0 siblings, 1 reply; 200+ results
From: Jan Viktorin @ 2016-01-04 20:08 UTC (permalink / raw)
To: dev; +Cc: Jan Viktorin
Hello DPDK community,
A few days ago, I've proposed an RFC of a new infrastructure that allows to
detect non-PCI devices present on SoC systems. It is, however, the easier part
of the story. To bring support of non-PCI devices, it is necessary to do much
deeper changes in DPDK. In this patch series, I am proposing changes that shows
a possible way how to do it.
I extended the rte_pci_{device,driver} with a member .magic. This member holds
a magic number unique to the PCI-infra. Another one (SoC-infra) would get a
different set of magics. This allows to define unions of bus-specific devices
and drivers while not loosing information about the original data type. It can
also add some type-safety into the system. It solves the problem of a missing
'type' member in the eth_driver structure.
Those extensions are then used to generalize the librte_ether library that
seems (to me) to be independent on the PCI now. What is important, the API
stays backwards compatible at the moment. From the point of ABI, I am afraid
that the .magic member breaks it anyway...
The code builds successfully for both x86_64 and ARMv7. I didn't test it in
runtime as the tests are not very suitable for this.
This patch set is independent on the previous one (which was adding the SoC
infra), however, if it is approved I expect them to be joined or to make them
dependent on each other in some way.
Regards
Jan
---
Jan Viktorin (14):
eal/common: introduce RTE_PCI_DRV_MAGIC
eal/common: introduce RTE_PCI_DEVICE_MAGIC
eal/common: introduce union rte_device and related
eal/common: introduce function to_pci_driver
eal/common: introduce function to_pci_device
Include rte_dev.h instead of rte_pci.h
lib/ether: generalize rte_eth_dev_init/uninit
eal/common: introduce rte_bus_addr
lib/ether: generalize attach/detach of devices
lib/ether: copy the rte_device union instead of rte_pci_device
lib/ether: extract function rte_device_get_intr_handle
lib/ether: check magic before naming a zone
lib/ether: check magic in rte_eth_copy_pci_info
lib/ether: introduce rte_eth_copy_dev_info
app/test-pipeline/config.c | 2 +-
app/test-pipeline/init.c | 2 +-
app/test-pipeline/main.c | 2 +-
app/test-pipeline/runtime.c | 2 +-
app/test-pmd/cmdline.c | 2 +-
app/test-pmd/config.c | 2 +-
app/test-pmd/csumonly.c | 2 +-
app/test-pmd/flowgen.c | 2 +-
app/test-pmd/iofwd.c | 2 +-
app/test-pmd/macfwd-retry.c | 2 +-
app/test-pmd/macfwd.c | 2 +-
app/test-pmd/macswap.c | 2 +-
app/test-pmd/parameters.c | 2 +-
app/test-pmd/rxonly.c | 2 +-
app/test-pmd/testpmd.c | 2 +-
app/test-pmd/txonly.c | 2 +-
app/test/test_pci.c | 2 +-
drivers/net/bnx2x/bnx2x_ethdev.c | 2 +
drivers/net/bnx2x/bnx2x_ethdev.h | 2 +-
drivers/net/cxgbe/base/t4_hw.c | 2 +-
drivers/net/cxgbe/cxgbe_ethdev.c | 3 +-
drivers/net/cxgbe/cxgbe_main.c | 2 +-
drivers/net/cxgbe/sge.c | 2 +-
drivers/net/e1000/em_ethdev.c | 3 +-
drivers/net/e1000/em_rxtx.c | 2 +-
drivers/net/e1000/igb_ethdev.c | 4 +-
drivers/net/e1000/igb_rxtx.c | 2 +-
drivers/net/enic/base/vnic_dev.h | 2 +-
drivers/net/enic/enic_ethdev.c | 2 +-
drivers/net/enic/enic_main.c | 2 +-
drivers/net/fm10k/fm10k_ethdev.c | 1 +
drivers/net/i40e/i40e_ethdev.c | 3 +-
drivers/net/i40e/i40e_ethdev_vf.c | 3 +-
drivers/net/i40e/i40e_pf.c | 2 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 4 +-
drivers/net/ixgbe/ixgbe_fdir.c | 2 +-
drivers/net/ixgbe/ixgbe_rxtx.c | 2 +-
drivers/net/mlx4/mlx4.c | 1 +
drivers/net/mlx5/mlx5.c | 3 +-
drivers/net/virtio/virtio_ethdev.c | 3 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c | 3 +-
drivers/net/vmxnet3/vmxnet3_rxtx.c | 2 +-
examples/bond/main.c | 2 +-
examples/dpdk_qat/main.c | 2 +-
examples/exception_path/main.c | 2 +-
examples/ip_fragmentation/main.c | 2 +-
examples/ip_reassembly/main.c | 2 +-
examples/ipv4_multicast/main.c | 2 +-
examples/kni/main.c | 2 +-
examples/l2fwd-crypto/main.c | 2 +-
examples/l2fwd-ivshmem/guest/guest.c | 2 +-
examples/l2fwd-jobstats/main.c | 2 +-
examples/l2fwd-keepalive/main.c | 2 +-
examples/l2fwd/main.c | 2 +-
examples/l3fwd-acl/main.c | 2 +-
examples/l3fwd-power/main.c | 2 +-
examples/l3fwd-vf/main.c | 2 +-
examples/l3fwd/main.c | 2 +-
examples/link_status_interrupt/main.c | 2 +-
examples/load_balancer/config.c | 2 +-
examples/load_balancer/init.c | 2 +-
examples/load_balancer/main.c | 2 +-
examples/load_balancer/runtime.c | 2 +-
.../client_server_mp/mp_client/client.c | 2 +-
.../client_server_mp/mp_server/init.c | 2 +-
.../client_server_mp/mp_server/main.c | 2 +-
examples/multi_process/l2fwd_fork/flib.c | 2 +-
examples/multi_process/l2fwd_fork/main.c | 2 +-
examples/multi_process/symmetric_mp/main.c | 2 +-
examples/performance-thread/l3fwd-thread/main.c | 2 +-
examples/vmdq/main.c | 2 +-
examples/vmdq_dcb/main.c | 2 +-
lib/librte_cryptodev/rte_cryptodev.c | 4 +-
lib/librte_cryptodev/rte_cryptodev_pmd.h | 1 -
lib/librte_eal/bsdapp/eal/eal.c | 1 -
lib/librte_eal/bsdapp/eal/eal_pci.c | 2 +-
lib/librte_eal/common/eal_common_devargs.c | 2 +-
lib/librte_eal/common/eal_common_pci.c | 2 +-
lib/librte_eal/common/eal_private.h | 2 +-
lib/librte_eal/common/include/rte_dev.h | 44 ++++
lib/librte_eal/common/include/rte_devargs.h | 2 +-
lib/librte_eal/common/include/rte_pci.h | 27 +++
lib/librte_eal/linuxapp/eal/eal.c | 2 +-
lib/librte_eal/linuxapp/eal/eal_interrupts.c | 2 +-
lib/librte_eal/linuxapp/eal/eal_ivshmem.c | 2 +-
lib/librte_ether/rte_ethdev.c | 224 +++++++++++++++------
lib/librte_ether/rte_ethdev.h | 25 ++-
87 files changed, 351 insertions(+), 144 deletions(-)
--
2.6.3
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH] vhost: remove lockless enqueue to the virtio ring
@ 2016-01-05 7:16 4% ` Xie, Huawei
0 siblings, 0 replies; 200+ results
From: Xie, Huawei @ 2016-01-05 7:16 UTC (permalink / raw)
To: dev; +Cc: ann.zhuangyanying
On 1/5/2016 2:42 PM, Xie, Huawei wrote:
> This patch removes the internal lockless enqueue implmentation.
> DPDK doesn't support receiving/transmitting packets from/to the same
> queue. Vhost PMD wraps vhost device as normal DPDK port. DPDK
> applications normally have their own lock implmentation when enqueue
> packets to the same queue of a port.
>
> The atomic cmpset is a costly operation. This patch should help
> performance a bit.
>
> Signed-off-by: Huawei Xie <huawei.xie@intel.com>
This patch modifies the API's behavior, which is also a trivial ABI
change. In my opinion, application shouldn't rely on previous behavior.
Anyway, i am checking how to declare the ABI change.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
@ 2016-01-06 14:29 4% ` Ananyev, Konstantin
2016-01-06 15:44 3% ` Adrien Mazarguil
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2016-01-06 14:29 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: dev
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Wednesday, January 06, 2016 10:01 AM
> To: Ananyev, Konstantin
> Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
>
> On Tue, Jan 05, 2016 at 04:50:31PM +0000, Ananyev, Konstantin wrote:
> [...]
> > > -----Original Message-----
> > > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> [...]
> > > I think we miss a comment here in how those 2/6/4 values are chosen
> > > because, according to the mask, I expect 16 possibilities but I get
> > > less. It will help a lot anyone who needs to add a new type.
> > >
> > > Extending the snprintf behavior above, it is best to remove the mask
> > > argument altogether and have rte_eth_dev_get_ptype_info() return the
> > > entire list every time. Applications need to iterate on the result in
> > > any case.
> >
> > I think we'd better keep mask argument.
> > In many cases upper layer only interested in some particular subset of
> > all packet types that HW can recognise.
> > Let say l3fwd only cares about RTE_PTYPE_L3_MASK, it is not interested in L4,
> > tunnelling packet types, etc.
> > If caller needs to know all recognised ptypes, he can set mask==-1,
> > In that case all supported packet types will be returned.
>
> There are other drawbacks to the mask argument in my opinion. The API will
> have to be updated again as soon as 32 bits aren't enough to represent all
> possible masks. We can't predict it will be large enough forever but on the
> other hand, using uint64_t seems overkill at this point.
Inside rte_mbuf packet_type itself is a 32 bit value.
These 32 bits are divided into several fields to mark packet types,
i.e: bits [0-3] are for all possible L2 types, bits [4-7] for L3 types, etc.
As long as packet_type itself is 32bits, 32bit mask is sufficient.
If we'll ever run out of 32 bits in packet_type itself, it will be ABI change anyway.
>
> I think this use for masks should be avoided when performance does not
> matter much, as in this case, user application cannot know the number of
> entries in advance and must rely on the returned value to iterate.
User doesn't know numbers of entries in advance anyway (with and without the mask).
That's why this function was introduced at first place.
With mask it just a bit more handy, in case user cares only about particular subset of supported
packet types (only L2 let say).
>
> A helper function can be added to convert a RTE_PTYPE_* value to the layer
> it belongs to (using enum to define possible values).
Not sure what for?
>
> If we absolutely want a mean to filter returned values, I suggest we use
> this enum instead of the mask argument.
> Since it won't be a mask, it won't
> have to be updated every time a new protocol requires extending one.
Number of bits PTYPE_L2/L3/L4,... layers are already defined.
So let say RTE_PTYPE_L2_MASK shouldn't change if you'll add new L2 ptype -
there are few reserved values right now.
if one day we'll run out bits in let say RTE_PTYPE_L2_MASK and will have to increase its size -
it would mean change of the packet_type layout and possible ABI breakage anyway.
Konstantin
>
> > > rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptypes[],
> > > size_t max_entries)
> > >
> > >
> > >
> > > Another point, I have read the example patch (l3fwd) but I don't
> > > understand why the PMD is not responsible for filling the packet type in
> > > the MBUF (packet parsing is done by parse_packet_type()). Why the extra
> > > computation?
> >
> > As I understand there are 3 possibilities now:
> > 1. HW supports ptype recognition and SW ptype parsing is never done
> > (--parse-ptype is not specified).
> > 2. HW supports ptype recognition, but and SW ptype parsing is done anyway
> > (--parse-ptype is specified).
> > 3. HW doesn't support and ptype recognition, and and SW ptype parsing is done
> > (--parse-ptype is specified).
> >
> > I suppose the question is what for introduce '--parse-ptype' at all?
> > My thought because of #2, so people can easily check what will be the performance impact of SW parsing.
> >
> > Konstantin
> >
> > >
> > > I see it more like an offload request (as checksum, etc...) and if the
> > > NIC does not support it then the application does the necessary overload.
> > >
> > > Best regards,
> > >
> > > --
> > > Nélio Laranjeiro
> > > 6WIND
>
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 0/3] ABI changes (RETA, cmdline)
@ 2016-01-06 14:32 4% Nelio Laranjeiro
2016-01-06 14:32 11% ` [dpdk-dev] [PATCH 1/3] ethdev: change RETA type in rte_eth_rss_reta_entry64 Nelio Laranjeiro
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Nelio Laranjeiro @ 2016-01-06 14:32 UTC (permalink / raw)
To: dev
Change ABIs as announced:
* rte_eth_rss_reta_entry64.reta field to handle large number of
queues (above 256).
* Increase cmdline buffers to support long command lines, include long
RETA update commands.
Nelio Laranjeiro (3):
ethdev: change RETA type in rte_eth_rss_reta_entry64
cmdline: increase command line buffer
mlx5: increase RETA table size
app/test-pmd/cmdline.c | 4 ++--
doc/guides/rel_notes/deprecation.rst | 10 ----------
drivers/net/mlx5/mlx5_defs.h | 2 +-
lib/librte_cmdline/cmdline_parse.h | 2 +-
lib/librte_cmdline/cmdline_parse_string.h | 2 +-
lib/librte_cmdline/cmdline_rdline.h | 2 +-
lib/librte_ether/rte_ethdev.c | 2 +-
lib/librte_ether/rte_ethdev.h | 2 +-
8 files changed, 8 insertions(+), 18 deletions(-)
--
2.1.4
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 1/3] ethdev: change RETA type in rte_eth_rss_reta_entry64
2016-01-06 14:32 4% [dpdk-dev] [PATCH 0/3] ABI changes (RETA, cmdline) Nelio Laranjeiro
@ 2016-01-06 14:32 11% ` Nelio Laranjeiro
2016-01-06 14:32 5% ` [dpdk-dev] [PATCH 2/3] cmdline: increase command line buffer Nelio Laranjeiro
2016-01-12 10:49 4% ` [dpdk-dev] [PATCH v2 0/3] ABI change for RETA, cmdline Nelio Laranjeiro
2 siblings, 0 replies; 200+ results
From: Nelio Laranjeiro @ 2016-01-06 14:32 UTC (permalink / raw)
To: dev
Several NICs can handle 512 entries/queues in their RETA table, an 8 bit field
is not large enough for them.
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
app/test-pmd/cmdline.c | 4 ++--
doc/guides/rel_notes/deprecation.rst | 5 -----
lib/librte_ether/rte_ethdev.c | 2 +-
lib/librte_ether/rte_ethdev.h | 2 +-
4 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..9c7cda0 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1767,7 +1767,7 @@ parse_reta_config(const char *str,
int i;
unsigned size;
uint16_t hash_index, idx, shift;
- uint8_t nb_queue;
+ uint16_t nb_queue;
char s[256];
const char *p, *p0 = str;
char *end;
@@ -1800,7 +1800,7 @@ parse_reta_config(const char *str,
}
hash_index = (uint16_t)int_fld[FLD_HASH_INDEX];
- nb_queue = (uint8_t)int_fld[FLD_QUEUE];
+ nb_queue = (uint16_t)int_fld[FLD_QUEUE];
if (hash_index >= nb_entries) {
printf("Invalid RETA hash index=%d\n", hash_index);
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..e8a3ed6 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -15,11 +15,6 @@ Deprecation Notices
* The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
must be updated to support 100G link and to have a cleaner link speed API.
-* ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
- which handles at most 256 queues (8 bits) while newer NICs support larger
- tables (512 queues).
- It should be integrated in release 2.3.
-
* ABI changes are planned for struct rte_eth_fdir_flow in order to support
extend flow director's input set. The release 2.2 does not contain these ABI
changes, but release 2.3 will, and no backwards compatibility is planned.
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index ed971b4..b0aa94d 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1857,7 +1857,7 @@ rte_eth_check_reta_mask(struct rte_eth_rss_reta_entry64 *reta_conf,
static int
rte_eth_check_reta_entry(struct rte_eth_rss_reta_entry64 *reta_conf,
uint16_t reta_size,
- uint8_t max_rxq)
+ uint16_t max_rxq)
{
uint16_t i, idx, shift;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index bada8ad..8302a2d 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -520,7 +520,7 @@ struct rte_eth_mirror_conf {
struct rte_eth_rss_reta_entry64 {
uint64_t mask;
/**< Mask bits indicate which entries need to be updated/queried. */
- uint8_t reta[RTE_RETA_GROUP_SIZE];
+ uint16_t reta[RTE_RETA_GROUP_SIZE];
/**< Group of 64 redirection table entries. */
};
--
2.1.4
^ permalink raw reply [relevance 11%]
* [dpdk-dev] [PATCH 2/3] cmdline: increase command line buffer
2016-01-06 14:32 4% [dpdk-dev] [PATCH 0/3] ABI changes (RETA, cmdline) Nelio Laranjeiro
2016-01-06 14:32 11% ` [dpdk-dev] [PATCH 1/3] ethdev: change RETA type in rte_eth_rss_reta_entry64 Nelio Laranjeiro
@ 2016-01-06 14:32 5% ` Nelio Laranjeiro
2016-01-12 10:49 4% ` [dpdk-dev] [PATCH v2 0/3] ABI change for RETA, cmdline Nelio Laranjeiro
2 siblings, 0 replies; 200+ results
From: Nelio Laranjeiro @ 2016-01-06 14:32 UTC (permalink / raw)
To: dev
For RETA query/update with a table of 512 entries, buffers are too small to
handle the request.
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
doc/guides/rel_notes/deprecation.rst | 5 -----
lib/librte_cmdline/cmdline_parse.h | 2 +-
lib/librte_cmdline/cmdline_parse_string.h | 2 +-
lib/librte_cmdline/cmdline_rdline.h | 2 +-
4 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e8a3ed6..9930b5a 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -39,8 +39,3 @@ Deprecation Notices
and table action handlers will be updated:
the pipeline parameter will be added, the packets mask parameter will be
either removed (for input port action handler) or made input-only.
-
-* ABI changes are planned in cmdline buffer size to allow the use of long
- commands (such as RETA update in testpmd). This should impact
- CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
- It should be integrated in release 2.3.
diff --git a/lib/librte_cmdline/cmdline_parse.h b/lib/librte_cmdline/cmdline_parse.h
index 4b25c45..89b28b1 100644
--- a/lib/librte_cmdline/cmdline_parse.h
+++ b/lib/librte_cmdline/cmdline_parse.h
@@ -81,7 +81,7 @@ extern "C" {
#define CMDLINE_PARSE_COMPLETED_BUFFER 2
/* maximum buffer size for parsed result */
-#define CMDLINE_PARSE_RESULT_BUFSIZE 8192
+#define CMDLINE_PARSE_RESULT_BUFSIZE 65536
/**
* Stores a pointer to the ops struct, and the offset: the place to
diff --git a/lib/librte_cmdline/cmdline_parse_string.h b/lib/librte_cmdline/cmdline_parse_string.h
index c205622..61e0627 100644
--- a/lib/librte_cmdline/cmdline_parse_string.h
+++ b/lib/librte_cmdline/cmdline_parse_string.h
@@ -66,7 +66,7 @@ extern "C" {
#endif
/* size of a parsed string */
-#define STR_TOKEN_SIZE 128
+#define STR_TOKEN_SIZE 8192
typedef char cmdline_fixed_string_t[STR_TOKEN_SIZE];
diff --git a/lib/librte_cmdline/cmdline_rdline.h b/lib/librte_cmdline/cmdline_rdline.h
index b9aad9b..07f8faa 100644
--- a/lib/librte_cmdline/cmdline_rdline.h
+++ b/lib/librte_cmdline/cmdline_rdline.h
@@ -93,7 +93,7 @@ extern "C" {
#endif
/* configuration */
-#define RDLINE_BUF_SIZE 256
+#define RDLINE_BUF_SIZE 16384
#define RDLINE_PROMPT_SIZE 32
#define RDLINE_VT100_BUF_SIZE 8
#define RDLINE_HISTORY_BUF_SIZE BUFSIZ
--
2.1.4
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
2016-01-06 14:29 4% ` Ananyev, Konstantin
@ 2016-01-06 15:44 3% ` Adrien Mazarguil
2016-01-06 16:44 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Adrien Mazarguil @ 2016-01-06 15:44 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev
On Wed, Jan 06, 2016 at 02:29:07PM +0000, Ananyev, Konstantin wrote:
>
>
> > -----Original Message-----
> > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > Sent: Wednesday, January 06, 2016 10:01 AM
> > To: Ananyev, Konstantin
> > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> >
> > On Tue, Jan 05, 2016 at 04:50:31PM +0000, Ananyev, Konstantin wrote:
> > [...]
> > > > -----Original Message-----
> > > > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > [...]
> > > > I think we miss a comment here in how those 2/6/4 values are chosen
> > > > because, according to the mask, I expect 16 possibilities but I get
> > > > less. It will help a lot anyone who needs to add a new type.
> > > >
> > > > Extending the snprintf behavior above, it is best to remove the mask
> > > > argument altogether and have rte_eth_dev_get_ptype_info() return the
> > > > entire list every time. Applications need to iterate on the result in
> > > > any case.
> > >
> > > I think we'd better keep mask argument.
> > > In many cases upper layer only interested in some particular subset of
> > > all packet types that HW can recognise.
> > > Let say l3fwd only cares about RTE_PTYPE_L3_MASK, it is not interested in L4,
> > > tunnelling packet types, etc.
> > > If caller needs to know all recognised ptypes, he can set mask==-1,
> > > In that case all supported packet types will be returned.
> >
> > There are other drawbacks to the mask argument in my opinion. The API will
> > have to be updated again as soon as 32 bits aren't enough to represent all
> > possible masks. We can't predict it will be large enough forever but on the
> > other hand, using uint64_t seems overkill at this point.
>
> Inside rte_mbuf packet_type itself is a 32 bit value.
> These 32 bits are divided into several fields to mark packet types,
> i.e: bits [0-3] are for all possible L2 types, bits [4-7] for L3 types, etc.
> As long as packet_type itself is 32bits, 32bit mask is sufficient.
> If we'll ever run out of 32 bits in packet_type itself, it will be ABI change anyway.
Sure, however why not do it now this issue has been raised so this function
doesn't need updating the day it breaks? I know there's a million other
places with a similar problem but I'm all for making new code future proof.
Perhaps in this particular case there is no way to hit the limit (although
there are only four unused bits left to extend RTE_PTYPE masks) but we've
seen this happen too many times with subsequent ABI breakage.
> > I think this use for masks should be avoided when performance does not
> > matter much, as in this case, user application cannot know the number of
> > entries in advance and must rely on the returned value to iterate.
>
> User doesn't know numbers of entries in advance anyway (with and without the mask).
> That's why this function was introduced at first place.
>
> With mask it just a bit more handy, in case user cares only about particular subset of supported
> packet types (only L2 let say).
OK, so we definitely need something to let applications know the layer a
given packet type belongs to, I'm sure it can be done in a convenient way
that won't be limited to the underlying type of the mask.
> > A helper function can be added to convert a RTE_PTYPE_* value to the layer
> > it belongs to (using enum to define possible values).
>
> Not sure what for?
This is assuming rte_eth_dev_get_ptype_info() doesn't filter anything (no
"mask" argument). In that case a separate function must be added to convert
RTE_PTYPE_* values to a layer, so applications can look for interesting
packet types while parsing plist[] on their own.
This layer information could be defined as an enum, i.e.:
enum rte_ptype_info {
RTE_PTYPE_UNKNOWN,
RTE_PTYPE_L2,
RTE_PTYPE_L3,
...
};
Or even an int value (2 standing for for "layer 2" etc. Tunnel encapsulation
wouldn't be described easily that way though). It's just an idea.
> > If we absolutely want a mean to filter returned values, I suggest we use
> > this enum instead of the mask argument.
> > Since it won't be a mask, it won't
> > have to be updated every time a new protocol requires extending one.
>
> Number of bits PTYPE_L2/L3/L4,... layers are already defined.
> So let say RTE_PTYPE_L2_MASK shouldn't change if you'll add new L2 ptype -
> there are few reserved values right now.
> if one day we'll run out bits in let say RTE_PTYPE_L2_MASK and will have to increase its size -
> it would mean change of the packet_type layout and possible ABI breakage anyway.
I'm aware of this, only pointing out we tend to rely on masks and type
boundaries a bit too much when there are other methods that are as (if not
more) convenient.
Perhaps some sort of tunneled packet types beyond inner L4 consuming the
four remaining bits will be added? That could happen soon.
> Konstantin
>
> >
> > > > rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptypes[],
> > > > size_t max_entries)
> > > >
> > > >
> > > >
> > > > Another point, I have read the example patch (l3fwd) but I don't
> > > > understand why the PMD is not responsible for filling the packet type in
> > > > the MBUF (packet parsing is done by parse_packet_type()). Why the extra
> > > > computation?
> > >
> > > As I understand there are 3 possibilities now:
> > > 1. HW supports ptype recognition and SW ptype parsing is never done
> > > (--parse-ptype is not specified).
> > > 2. HW supports ptype recognition, but and SW ptype parsing is done anyway
> > > (--parse-ptype is specified).
> > > 3. HW doesn't support and ptype recognition, and and SW ptype parsing is done
> > > (--parse-ptype is specified).
> > >
> > > I suppose the question is what for introduce '--parse-ptype' at all?
> > > My thought because of #2, so people can easily check what will be the performance impact of SW parsing.
> > >
> > > Konstantin
> > >
> > > >
> > > > I see it more like an offload request (as checksum, etc...) and if the
> > > > NIC does not support it then the application does the necessary overload.
> > > >
> > > > Best regards,
> > > >
> > > > --
> > > > Nélio Laranjeiro
> > > > 6WIND
> >
> > --
> > Adrien Mazarguil
> > 6WIND
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
2016-01-06 15:44 3% ` Adrien Mazarguil
@ 2016-01-06 16:44 0% ` Ananyev, Konstantin
2016-01-06 17:22 0% ` Adrien Mazarguil
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2016-01-06 16:44 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: dev
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Wednesday, January 06, 2016 3:45 PM
> To: Ananyev, Konstantin
> Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
>
> On Wed, Jan 06, 2016 at 02:29:07PM +0000, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > Sent: Wednesday, January 06, 2016 10:01 AM
> > > To: Ananyev, Konstantin
> > > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> > >
> > > On Tue, Jan 05, 2016 at 04:50:31PM +0000, Ananyev, Konstantin wrote:
> > > [...]
> > > > > -----Original Message-----
> > > > > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > > [...]
> > > > > I think we miss a comment here in how those 2/6/4 values are chosen
> > > > > because, according to the mask, I expect 16 possibilities but I get
> > > > > less. It will help a lot anyone who needs to add a new type.
> > > > >
> > > > > Extending the snprintf behavior above, it is best to remove the mask
> > > > > argument altogether and have rte_eth_dev_get_ptype_info() return the
> > > > > entire list every time. Applications need to iterate on the result in
> > > > > any case.
> > > >
> > > > I think we'd better keep mask argument.
> > > > In many cases upper layer only interested in some particular subset of
> > > > all packet types that HW can recognise.
> > > > Let say l3fwd only cares about RTE_PTYPE_L3_MASK, it is not interested in L4,
> > > > tunnelling packet types, etc.
> > > > If caller needs to know all recognised ptypes, he can set mask==-1,
> > > > In that case all supported packet types will be returned.
> > >
> > > There are other drawbacks to the mask argument in my opinion. The API will
> > > have to be updated again as soon as 32 bits aren't enough to represent all
> > > possible masks. We can't predict it will be large enough forever but on the
> > > other hand, using uint64_t seems overkill at this point.
> >
> > Inside rte_mbuf packet_type itself is a 32 bit value.
> > These 32 bits are divided into several fields to mark packet types,
> > i.e: bits [0-3] are for all possible L2 types, bits [4-7] for L3 types, etc.
> > As long as packet_type itself is 32bits, 32bit mask is sufficient.
> > If we'll ever run out of 32 bits in packet_type itself, it will be ABI change anyway.
>
> Sure, however why not do it now this issue has been raised so this function
> doesn't need updating the day it breaks? I know there's a million other
> places with a similar problem but I'm all for making new code future proof.
If rte_mbuf packet_type will have to be increased to 64bit long, then
this function will have to change anyway (with or without mask parameter).
It will have to become:
rte_eth_dev_get_ptype_info(uint8_t portid, uint64_t ptypes[], ...)
So I think we don't have to worry about mask parameter itself.
>
> Perhaps in this particular case there is no way to hit the limit (although
> there are only four unused bits left to extend RTE_PTYPE masks) but we've
> seen this happen too many times with subsequent ABI breakage.
When ptype was introduced we tried to reserve some free space for each layer (L2/L3/L4/...),
so it wouldn't be overrun immediately.
But of course if there would be a new HW that can recognise dozen new packet types - it is possible.
Do you have any particular use-case in mind?
>
> > > I think this use for masks should be avoided when performance does not
> > > matter much, as in this case, user application cannot know the number of
> > > entries in advance and must rely on the returned value to iterate.
> >
> > User doesn't know numbers of entries in advance anyway (with and without the mask).
> > That's why this function was introduced at first place.
> >
> > With mask it just a bit more handy, in case user cares only about particular subset of supported
> > packet types (only L2 let say).
>
> OK, so we definitely need something to let applications know the layer a
> given packet type belongs to, I'm sure it can be done in a convenient way
> that won't be limited to the underlying type of the mask.
>
> > > A helper function can be added to convert a RTE_PTYPE_* value to the layer
> > > it belongs to (using enum to define possible values).
> >
> > Not sure what for?
>
> This is assuming rte_eth_dev_get_ptype_info() doesn't filter anything (no
> "mask" argument). In that case a separate function must be added to convert
> RTE_PTYPE_* values to a layer, so applications can look for interesting
> packet types while parsing plist[] on their own.
Honestly, I don't see why do you need that.
You already do know that let say RTE_PTYPE_L3_IPV4 belongs to L3.
Why do you need some extra enum here?
From my thought - the only purpose of mask parameter was to limit number of elements in the ptypes[] at return.
So let say user would need to iterate over 10 elements, instead of 100 to find
the ones he is interested in.
>
> This layer information could be defined as an enum, i.e.:
>
> enum rte_ptype_info {
> RTE_PTYPE_UNKNOWN,
> RTE_PTYPE_L2,
> RTE_PTYPE_L3,
> ...
> };
>
> Or even an int value (2 standing for for "layer 2" etc. Tunnel encapsulation
> wouldn't be described easily that way though). It's just an idea.
>
> > > If we absolutely want a mean to filter returned values, I suggest we use
> > > this enum instead of the mask argument.
> > > Since it won't be a mask, it won't
> > > have to be updated every time a new protocol requires extending one.
> >
> > Number of bits PTYPE_L2/L3/L4,... layers are already defined.
> > So let say RTE_PTYPE_L2_MASK shouldn't change if you'll add new L2 ptype -
> > there are few reserved values right now.
> > if one day we'll run out bits in let say RTE_PTYPE_L2_MASK and will have to increase its size -
> > it would mean change of the packet_type layout and possible ABI breakage anyway.
>
> I'm aware of this, only pointing out we tend to rely on masks and type
> boundaries a bit too much when there are other methods that are as (if not
> more) convenient.
Yes, we do rely on masks in ptype.
That's how ptype was defined.
Let say to check that incoming packet is Ether/IPv4(no extentions)/UDP,
you probably would do:
if (mbuf->packet_type & (RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK | RTE_PTYPE_L4_MASK) ==
(RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4 | RTE_PTYPE_L4_UDP)) {...}
>
> Perhaps some sort of tunneled packet types beyond inner L4 consuming the
> four remaining bits will be added? That could happen soon.
As I said above: do you have particular scenario in mind when 32bits for packet_type
might be not enough?
If yes, then it is probably a good idea to submit an RFC for extending it to 64 bit,
or introduce packet_type2, or whatever would be your preferred way to deal with it.
Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
2016-01-06 16:44 0% ` Ananyev, Konstantin
@ 2016-01-06 17:22 0% ` Adrien Mazarguil
2016-01-07 10:24 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Adrien Mazarguil @ 2016-01-06 17:22 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev
On Wed, Jan 06, 2016 at 04:44:43PM +0000, Ananyev, Konstantin wrote:
>
>
> > -----Original Message-----
> > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > Sent: Wednesday, January 06, 2016 3:45 PM
> > To: Ananyev, Konstantin
> > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> >
> > On Wed, Jan 06, 2016 at 02:29:07PM +0000, Ananyev, Konstantin wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > > Sent: Wednesday, January 06, 2016 10:01 AM
> > > > To: Ananyev, Konstantin
> > > > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> > > >
> > > > On Tue, Jan 05, 2016 at 04:50:31PM +0000, Ananyev, Konstantin wrote:
> > > > [...]
> > > > > > -----Original Message-----
> > > > > > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > > > [...]
> > > > > > I think we miss a comment here in how those 2/6/4 values are chosen
> > > > > > because, according to the mask, I expect 16 possibilities but I get
> > > > > > less. It will help a lot anyone who needs to add a new type.
> > > > > >
> > > > > > Extending the snprintf behavior above, it is best to remove the mask
> > > > > > argument altogether and have rte_eth_dev_get_ptype_info() return the
> > > > > > entire list every time. Applications need to iterate on the result in
> > > > > > any case.
> > > > >
> > > > > I think we'd better keep mask argument.
> > > > > In many cases upper layer only interested in some particular subset of
> > > > > all packet types that HW can recognise.
> > > > > Let say l3fwd only cares about RTE_PTYPE_L3_MASK, it is not interested in L4,
> > > > > tunnelling packet types, etc.
> > > > > If caller needs to know all recognised ptypes, he can set mask==-1,
> > > > > In that case all supported packet types will be returned.
> > > >
> > > > There are other drawbacks to the mask argument in my opinion. The API will
> > > > have to be updated again as soon as 32 bits aren't enough to represent all
> > > > possible masks. We can't predict it will be large enough forever but on the
> > > > other hand, using uint64_t seems overkill at this point.
> > >
> > > Inside rte_mbuf packet_type itself is a 32 bit value.
> > > These 32 bits are divided into several fields to mark packet types,
> > > i.e: bits [0-3] are for all possible L2 types, bits [4-7] for L3 types, etc.
> > > As long as packet_type itself is 32bits, 32bit mask is sufficient.
> > > If we'll ever run out of 32 bits in packet_type itself, it will be ABI change anyway.
> >
> > Sure, however why not do it now this issue has been raised so this function
> > doesn't need updating the day it breaks? I know there's a million other
> > places with a similar problem but I'm all for making new code future proof.
>
> If rte_mbuf packet_type will have to be increased to 64bit long, then
> this function will have to change anyway (with or without mask parameter).
> It will have to become:
>
> rte_eth_dev_get_ptype_info(uint8_t portid, uint64_t ptypes[], ...)
>
> So I think we don't have to worry about mask parameter itself.
Well, yes, besides I overlooked ptypes[] itself is 32 bit, working around
the type width of the mask wouldn't help much.
> > Perhaps in this particular case there is no way to hit the limit (although
> > there are only four unused bits left to extend RTE_PTYPE masks) but we've
> > seen this happen too many times with subsequent ABI breakage.
>
> When ptype was introduced we tried to reserve some free space for each layer (L2/L3/L4/...),
> so it wouldn't be overrun immediately.
> But of course if there would be a new HW that can recognise dozen new packet types - it is possible.
> Do you have any particular use-case in mind?
No, that was just to illustrate my point.
> > > > I think this use for masks should be avoided when performance does not
> > > > matter much, as in this case, user application cannot know the number of
> > > > entries in advance and must rely on the returned value to iterate.
> > >
> > > User doesn't know numbers of entries in advance anyway (with and without the mask).
> > > That's why this function was introduced at first place.
> > >
> > > With mask it just a bit more handy, in case user cares only about particular subset of supported
> > > packet types (only L2 let say).
> >
> > OK, so we definitely need something to let applications know the layer a
> > given packet type belongs to, I'm sure it can be done in a convenient way
> > that won't be limited to the underlying type of the mask.
> >
> > > > A helper function can be added to convert a RTE_PTYPE_* value to the layer
> > > > it belongs to (using enum to define possible values).
> > >
> > > Not sure what for?
> >
> > This is assuming rte_eth_dev_get_ptype_info() doesn't filter anything (no
> > "mask" argument). In that case a separate function must be added to convert
> > RTE_PTYPE_* values to a layer, so applications can look for interesting
> > packet types while parsing plist[] on their own.
>
> Honestly, I don't see why do you need that.
> You already do know that let say RTE_PTYPE_L3_IPV4 belongs to L3.
> Why do you need some extra enum here?
> From my thought - the only purpose of mask parameter was to limit number of elements in the ptypes[] at return.
> So let say user would need to iterate over 10 elements, instead of 100 to find
> the ones he is interested in.
Since this is already a slow manner for retrieving types, 10 or 100 doesn't
make much difference. Such a function shouldn't be used in the data path
directly.
My point is, since we're dealing with a slow function, let's keep its API as
simple as possible. By having a mask to match, a large number of checks are
added in all PMDs while they could just fill the array without
bothering. The filtering logic is an application requirement that could be
useful in its own function as well (converting any random value to its
related layer or mask).
> > This layer information could be defined as an enum, i.e.:
> >
> > enum rte_ptype_info {
> > RTE_PTYPE_UNKNOWN,
> > RTE_PTYPE_L2,
> > RTE_PTYPE_L3,
> > ...
> > };
> >
> > Or even an int value (2 standing for for "layer 2" etc. Tunnel encapsulation
> > wouldn't be described easily that way though). It's just an idea.
> >
> > > > If we absolutely want a mean to filter returned values, I suggest we use
> > > > this enum instead of the mask argument.
> > > > Since it won't be a mask, it won't
> > > > have to be updated every time a new protocol requires extending one.
> > >
> > > Number of bits PTYPE_L2/L3/L4,... layers are already defined.
> > > So let say RTE_PTYPE_L2_MASK shouldn't change if you'll add new L2 ptype -
> > > there are few reserved values right now.
> > > if one day we'll run out bits in let say RTE_PTYPE_L2_MASK and will have to increase its size -
> > > it would mean change of the packet_type layout and possible ABI breakage anyway.
> >
> > I'm aware of this, only pointing out we tend to rely on masks and type
> > boundaries a bit too much when there are other methods that are as (if not
> > more) convenient.
>
> Yes, we do rely on masks in ptype.
> That's how ptype was defined.
> Let say to check that incoming packet is Ether/IPv4(no extentions)/UDP,
> you probably would do:
>
> if (mbuf->packet_type & (RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK | RTE_PTYPE_L4_MASK) ==
> (RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4 | RTE_PTYPE_L4_UDP)) {...}
All right, let's not use a different method to filter packet types.
> > Perhaps some sort of tunneled packet types beyond inner L4 consuming the
> > four remaining bits will be added? That could happen soon.
>
> As I said above: do you have particular scenario in mind when 32bits for packet_type
> might be not enough?
> If yes, then it is probably a good idea to submit an RFC for extending it to 64 bit,
> or introduce packet_type2, or whatever would be your preferred way to deal with it.
No, really, I guess we'll extend ptype to 64 bit when necessary. My point on
filtering separately still stands.
> Konstantin
>
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] vhost: fix leak of fds and mmaps
@ 2016-01-07 2:31 3% ` Yuanhan Liu
2016-01-07 6:50 0% ` Xie, Huawei
0 siblings, 1 reply; 200+ results
From: Yuanhan Liu @ 2016-01-07 2:31 UTC (permalink / raw)
To: Rich Lane; +Cc: dev
On Tue, Jan 05, 2016 at 02:14:09PM -0800, Rich Lane wrote:
> The common vhost code only supported a single mmap per device. vhost-user
> worked around this by saving the address/length/fd of each mmap after the end
> of the rte_virtio_memory struct. This only works if the vhost-user code frees
> dev->mem, since the common code is unaware of the extra info. The
> VHOST_USER_RESET_OWNER message is one situation where the common code frees
> dev->mem and leaks the fds and mappings. This happens every time I shut down a
> VM.
That is a good catch! But I don't think it needs the complexity your
patch has to fix it. Besides that, your patch has ABI change, which
is not acceptable at this stage.
Back to the issue, the thing is that, mmap/unmap is vhost-user/vhost-cuse
specific, thus we'd better to handle them inside vhost-user/vhost-cuse
differently, but not in the common path, virtio-net.c: let the common
path handle common things only. That would make the logic clear, and
hence less error prone.
Note that we have already handled the mmap inside vhost-user/vhost-cuse,
thinking of that way, there is no reason to handle unmap at virtio-net.c:
it should be a historic issue while we added vhost-cuse first, which will
not be an issue until we added vhost-user.
Another note is that you should not name an internal function with "rte_"
prefix; it should be reserved for public functions.
--yliu
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] vhost: fix leak of fds and mmaps
2016-01-07 2:31 3% ` Yuanhan Liu
@ 2016-01-07 6:50 0% ` Xie, Huawei
0 siblings, 0 replies; 200+ results
From: Xie, Huawei @ 2016-01-07 6:50 UTC (permalink / raw)
To: Yuanhan Liu, Rich Lane; +Cc: dev
On 1/7/2016 10:27 AM, Yuanhan Liu wrote:
> On Tue, Jan 05, 2016 at 02:14:09PM -0800, Rich Lane wrote:
>> The common vhost code only supported a single mmap per device. vhost-user
>> worked around this by saving the address/length/fd of each mmap after the end
>> of the rte_virtio_memory struct. This only works if the vhost-user code frees
>> dev->mem, since the common code is unaware of the extra info. The
>> VHOST_USER_RESET_OWNER message is one situation where the common code frees
>> dev->mem and leaks the fds and mappings. This happens every time I shut down a
>> VM.
> That is a good catch! But I don't think it needs the complexity your
> patch has to fix it. Besides that, your patch has ABI change, which
> is not acceptable at this stage.
>
> Back to the issue, the thing is that, mmap/unmap is vhost-user/vhost-cuse
> specific, thus we'd better to handle them inside vhost-user/vhost-cuse
> differently, but not in the common path, virtio-net.c: let the common
> path handle common things only. That would make the logic clear, and
> hence less error prone.
>
> Note that we have already handled the mmap inside vhost-user/vhost-cuse,
> thinking of that way, there is no reason to handle unmap at virtio-net.c:
> it should be a historic issue while we added vhost-cuse first, which will
> not be an issue until we added vhost-user.
Agree. Let vhost-user part handle its specific cleanup and let the
virtio-net.c handle the common logic.
>
> Another note is that you should not name an internal function with "rte_"
> prefix; it should be reserved for public functions.
>
> --yliu
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
2016-01-06 17:22 0% ` Adrien Mazarguil
@ 2016-01-07 10:24 0% ` Ananyev, Konstantin
2016-01-07 13:32 0% ` Adrien Mazarguil
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2016-01-07 10:24 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: dev
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Wednesday, January 06, 2016 5:23 PM
> To: Ananyev, Konstantin
> Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
>
> On Wed, Jan 06, 2016 at 04:44:43PM +0000, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > Sent: Wednesday, January 06, 2016 3:45 PM
> > > To: Ananyev, Konstantin
> > > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> > >
> > > On Wed, Jan 06, 2016 at 02:29:07PM +0000, Ananyev, Konstantin wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > > > Sent: Wednesday, January 06, 2016 10:01 AM
> > > > > To: Ananyev, Konstantin
> > > > > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> > > > >
> > > > > On Tue, Jan 05, 2016 at 04:50:31PM +0000, Ananyev, Konstantin wrote:
> > > > > [...]
> > > > > > > -----Original Message-----
> > > > > > > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > > > > [...]
> > > > > > > I think we miss a comment here in how those 2/6/4 values are chosen
> > > > > > > because, according to the mask, I expect 16 possibilities but I get
> > > > > > > less. It will help a lot anyone who needs to add a new type.
> > > > > > >
> > > > > > > Extending the snprintf behavior above, it is best to remove the mask
> > > > > > > argument altogether and have rte_eth_dev_get_ptype_info() return the
> > > > > > > entire list every time. Applications need to iterate on the result in
> > > > > > > any case.
> > > > > >
> > > > > > I think we'd better keep mask argument.
> > > > > > In many cases upper layer only interested in some particular subset of
> > > > > > all packet types that HW can recognise.
> > > > > > Let say l3fwd only cares about RTE_PTYPE_L3_MASK, it is not interested in L4,
> > > > > > tunnelling packet types, etc.
> > > > > > If caller needs to know all recognised ptypes, he can set mask==-1,
> > > > > > In that case all supported packet types will be returned.
> > > > >
> > > > > There are other drawbacks to the mask argument in my opinion. The API will
> > > > > have to be updated again as soon as 32 bits aren't enough to represent all
> > > > > possible masks. We can't predict it will be large enough forever but on the
> > > > > other hand, using uint64_t seems overkill at this point.
> > > >
> > > > Inside rte_mbuf packet_type itself is a 32 bit value.
> > > > These 32 bits are divided into several fields to mark packet types,
> > > > i.e: bits [0-3] are for all possible L2 types, bits [4-7] for L3 types, etc.
> > > > As long as packet_type itself is 32bits, 32bit mask is sufficient.
> > > > If we'll ever run out of 32 bits in packet_type itself, it will be ABI change anyway.
> > >
> > > Sure, however why not do it now this issue has been raised so this function
> > > doesn't need updating the day it breaks? I know there's a million other
> > > places with a similar problem but I'm all for making new code future proof.
> >
> > If rte_mbuf packet_type will have to be increased to 64bit long, then
> > this function will have to change anyway (with or without mask parameter).
> > It will have to become:
> >
> > rte_eth_dev_get_ptype_info(uint8_t portid, uint64_t ptypes[], ...)
> >
> > So I think we don't have to worry about mask parameter itself.
>
> Well, yes, besides I overlooked ptypes[] itself is 32 bit, working around
> the type width of the mask wouldn't help much.
>
> > > Perhaps in this particular case there is no way to hit the limit (although
> > > there are only four unused bits left to extend RTE_PTYPE masks) but we've
> > > seen this happen too many times with subsequent ABI breakage.
> >
> > When ptype was introduced we tried to reserve some free space for each layer (L2/L3/L4/...),
> > so it wouldn't be overrun immediately.
> > But of course if there would be a new HW that can recognise dozen new packet types - it is possible.
> > Do you have any particular use-case in mind?
>
> No, that was just to illustrate my point.
>
> > > > > I think this use for masks should be avoided when performance does not
> > > > > matter much, as in this case, user application cannot know the number of
> > > > > entries in advance and must rely on the returned value to iterate.
> > > >
> > > > User doesn't know numbers of entries in advance anyway (with and without the mask).
> > > > That's why this function was introduced at first place.
> > > >
> > > > With mask it just a bit more handy, in case user cares only about particular subset of supported
> > > > packet types (only L2 let say).
> > >
> > > OK, so we definitely need something to let applications know the layer a
> > > given packet type belongs to, I'm sure it can be done in a convenient way
> > > that won't be limited to the underlying type of the mask.
> > >
> > > > > A helper function can be added to convert a RTE_PTYPE_* value to the layer
> > > > > it belongs to (using enum to define possible values).
> > > >
> > > > Not sure what for?
> > >
> > > This is assuming rte_eth_dev_get_ptype_info() doesn't filter anything (no
> > > "mask" argument). In that case a separate function must be added to convert
> > > RTE_PTYPE_* values to a layer, so applications can look for interesting
> > > packet types while parsing plist[] on their own.
> >
> > Honestly, I don't see why do you need that.
> > You already do know that let say RTE_PTYPE_L3_IPV4 belongs to L3.
> > Why do you need some extra enum here?
> > From my thought - the only purpose of mask parameter was to limit number of elements in the ptypes[] at return.
> > So let say user would need to iterate over 10 elements, instead of 100 to find
> > the ones he is interested in.
>
> Since this is already a slow manner for retrieving types, 10 or 100 doesn't
> make much difference. Such a function shouldn't be used in the data path
> directly.
Yes, it is not supposed to be called from data-path.
> My point is, since we're dealing with a slow function, let's keep its API as
> simple as possible.
Well, API should be simple, but from other side it has to be flexible and convenient
for the user.
As I user, I would prefer to have an ability to select the layers here - that's
why I suggested to add the mask parameter.
>By having a mask to match, a large number of checks are
> added in all PMDs while they could just fill the array without
> bothering.
That's a valid point.
We could move filter point into rte_ethdev layer.
So PMD would always return an array of all supported ptypes, and
then rte_ethdev layer will filter it based on mask parameter.
Does it sound reasonable to you?
Konstantin
>The filtering logic is an application requirement that could be
> useful in its own function as well (converting any random value to its
> related layer or mask).
>
> > > This layer information could be defined as an enum, i.e.:
> > >
> > > enum rte_ptype_info {
> > > RTE_PTYPE_UNKNOWN,
> > > RTE_PTYPE_L2,
> > > RTE_PTYPE_L3,
> > > ...
> > > };
> > >
> > > Or even an int value (2 standing for for "layer 2" etc. Tunnel encapsulation
> > > wouldn't be described easily that way though). It's just an idea.
> > >
> > > > > If we absolutely want a mean to filter returned values, I suggest we use
> > > > > this enum instead of the mask argument.
> > > > > Since it won't be a mask, it won't
> > > > > have to be updated every time a new protocol requires extending one.
> > > >
> > > > Number of bits PTYPE_L2/L3/L4,... layers are already defined.
> > > > So let say RTE_PTYPE_L2_MASK shouldn't change if you'll add new L2 ptype -
> > > > there are few reserved values right now.
> > > > if one day we'll run out bits in let say RTE_PTYPE_L2_MASK and will have to increase its size -
> > > > it would mean change of the packet_type layout and possible ABI breakage anyway.
> > >
> > > I'm aware of this, only pointing out we tend to rely on masks and type
> > > boundaries a bit too much when there are other methods that are as (if not
> > > more) convenient.
> >
> > Yes, we do rely on masks in ptype.
> > That's how ptype was defined.
> > Let say to check that incoming packet is Ether/IPv4(no extentions)/UDP,
> > you probably would do:
> >
> > if (mbuf->packet_type & (RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK | RTE_PTYPE_L4_MASK) ==
> > (RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4 | RTE_PTYPE_L4_UDP)) {...}
>
> All right, let's not use a different method to filter packet types.
>
> > > Perhaps some sort of tunneled packet types beyond inner L4 consuming the
> > > four remaining bits will be added? That could happen soon.
> >
> > As I said above: do you have particular scenario in mind when 32bits for packet_type
> > might be not enough?
> > If yes, then it is probably a good idea to submit an RFC for extending it to 64 bit,
> > or introduce packet_type2, or whatever would be your preferred way to deal with it.
>
> No, really, I guess we'll extend ptype to 64 bit when necessary. My point on
> filtering separately still stands.
>
> > Konstantin
> >
>
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
2016-01-07 10:24 0% ` Ananyev, Konstantin
@ 2016-01-07 13:32 0% ` Adrien Mazarguil
0 siblings, 0 replies; 200+ results
From: Adrien Mazarguil @ 2016-01-07 13:32 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev
On Thu, Jan 07, 2016 at 10:24:19AM +0000, Ananyev, Konstantin wrote:
>
>
> > -----Original Message-----
> > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > Sent: Wednesday, January 06, 2016 5:23 PM
> > To: Ananyev, Konstantin
> > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> >
> > On Wed, Jan 06, 2016 at 04:44:43PM +0000, Ananyev, Konstantin wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > > Sent: Wednesday, January 06, 2016 3:45 PM
> > > > To: Ananyev, Konstantin
> > > > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> > > >
> > > > On Wed, Jan 06, 2016 at 02:29:07PM +0000, Ananyev, Konstantin wrote:
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > > > > Sent: Wednesday, January 06, 2016 10:01 AM
> > > > > > To: Ananyev, Konstantin
> > > > > > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> > > > > >
> > > > > > On Tue, Jan 05, 2016 at 04:50:31PM +0000, Ananyev, Konstantin wrote:
> > > > > > [...]
> > > > > > > > -----Original Message-----
> > > > > > > > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > > > > > [...]
> > > > > > > > I think we miss a comment here in how those 2/6/4 values are chosen
> > > > > > > > because, according to the mask, I expect 16 possibilities but I get
> > > > > > > > less. It will help a lot anyone who needs to add a new type.
> > > > > > > >
> > > > > > > > Extending the snprintf behavior above, it is best to remove the mask
> > > > > > > > argument altogether and have rte_eth_dev_get_ptype_info() return the
> > > > > > > > entire list every time. Applications need to iterate on the result in
> > > > > > > > any case.
> > > > > > >
> > > > > > > I think we'd better keep mask argument.
> > > > > > > In many cases upper layer only interested in some particular subset of
> > > > > > > all packet types that HW can recognise.
> > > > > > > Let say l3fwd only cares about RTE_PTYPE_L3_MASK, it is not interested in L4,
> > > > > > > tunnelling packet types, etc.
> > > > > > > If caller needs to know all recognised ptypes, he can set mask==-1,
> > > > > > > In that case all supported packet types will be returned.
> > > > > >
> > > > > > There are other drawbacks to the mask argument in my opinion. The API will
> > > > > > have to be updated again as soon as 32 bits aren't enough to represent all
> > > > > > possible masks. We can't predict it will be large enough forever but on the
> > > > > > other hand, using uint64_t seems overkill at this point.
> > > > >
> > > > > Inside rte_mbuf packet_type itself is a 32 bit value.
> > > > > These 32 bits are divided into several fields to mark packet types,
> > > > > i.e: bits [0-3] are for all possible L2 types, bits [4-7] for L3 types, etc.
> > > > > As long as packet_type itself is 32bits, 32bit mask is sufficient.
> > > > > If we'll ever run out of 32 bits in packet_type itself, it will be ABI change anyway.
> > > >
> > > > Sure, however why not do it now this issue has been raised so this function
> > > > doesn't need updating the day it breaks? I know there's a million other
> > > > places with a similar problem but I'm all for making new code future proof.
> > >
> > > If rte_mbuf packet_type will have to be increased to 64bit long, then
> > > this function will have to change anyway (with or without mask parameter).
> > > It will have to become:
> > >
> > > rte_eth_dev_get_ptype_info(uint8_t portid, uint64_t ptypes[], ...)
> > >
> > > So I think we don't have to worry about mask parameter itself.
> >
> > Well, yes, besides I overlooked ptypes[] itself is 32 bit, working around
> > the type width of the mask wouldn't help much.
> >
> > > > Perhaps in this particular case there is no way to hit the limit (although
> > > > there are only four unused bits left to extend RTE_PTYPE masks) but we've
> > > > seen this happen too many times with subsequent ABI breakage.
> > >
> > > When ptype was introduced we tried to reserve some free space for each layer (L2/L3/L4/...),
> > > so it wouldn't be overrun immediately.
> > > But of course if there would be a new HW that can recognise dozen new packet types - it is possible.
> > > Do you have any particular use-case in mind?
> >
> > No, that was just to illustrate my point.
> >
> > > > > > I think this use for masks should be avoided when performance does not
> > > > > > matter much, as in this case, user application cannot know the number of
> > > > > > entries in advance and must rely on the returned value to iterate.
> > > > >
> > > > > User doesn't know numbers of entries in advance anyway (with and without the mask).
> > > > > That's why this function was introduced at first place.
> > > > >
> > > > > With mask it just a bit more handy, in case user cares only about particular subset of supported
> > > > > packet types (only L2 let say).
> > > >
> > > > OK, so we definitely need something to let applications know the layer a
> > > > given packet type belongs to, I'm sure it can be done in a convenient way
> > > > that won't be limited to the underlying type of the mask.
> > > >
> > > > > > A helper function can be added to convert a RTE_PTYPE_* value to the layer
> > > > > > it belongs to (using enum to define possible values).
> > > > >
> > > > > Not sure what for?
> > > >
> > > > This is assuming rte_eth_dev_get_ptype_info() doesn't filter anything (no
> > > > "mask" argument). In that case a separate function must be added to convert
> > > > RTE_PTYPE_* values to a layer, so applications can look for interesting
> > > > packet types while parsing plist[] on their own.
> > >
> > > Honestly, I don't see why do you need that.
> > > You already do know that let say RTE_PTYPE_L3_IPV4 belongs to L3.
> > > Why do you need some extra enum here?
> > > From my thought - the only purpose of mask parameter was to limit number of elements in the ptypes[] at return.
> > > So let say user would need to iterate over 10 elements, instead of 100 to find
> > > the ones he is interested in.
> >
> > Since this is already a slow manner for retrieving types, 10 or 100 doesn't
> > make much difference. Such a function shouldn't be used in the data path
> > directly.
>
> Yes, it is not supposed to be called from data-path.
>
> > My point is, since we're dealing with a slow function, let's keep its API as
> > simple as possible.
>
> Well, API should be simple, but from other side it has to be flexible and convenient
> for the user.
> As I user, I would prefer to have an ability to select the layers here - that's
> why I suggested to add the mask parameter.
>
> >By having a mask to match, a large number of checks are
> > added in all PMDs while they could just fill the array without
> > bothering.
>
> That's a valid point.
> We could move filter point into rte_ethdev layer.
> So PMD would always return an array of all supported ptypes, and
> then rte_ethdev layer will filter it based on mask parameter.
> Does it sound reasonable to you?
Yes, I think it's fine that way, thanks.
> >The filtering logic is an application requirement that could be
> > useful in its own function as well (converting any random value to its
> > related layer or mask).
> >
> > > > This layer information could be defined as an enum, i.e.:
> > > >
> > > > enum rte_ptype_info {
> > > > RTE_PTYPE_UNKNOWN,
> > > > RTE_PTYPE_L2,
> > > > RTE_PTYPE_L3,
> > > > ...
> > > > };
> > > >
> > > > Or even an int value (2 standing for for "layer 2" etc. Tunnel encapsulation
> > > > wouldn't be described easily that way though). It's just an idea.
> > > >
> > > > > > If we absolutely want a mean to filter returned values, I suggest we use
> > > > > > this enum instead of the mask argument.
> > > > > > Since it won't be a mask, it won't
> > > > > > have to be updated every time a new protocol requires extending one.
> > > > >
> > > > > Number of bits PTYPE_L2/L3/L4,... layers are already defined.
> > > > > So let say RTE_PTYPE_L2_MASK shouldn't change if you'll add new L2 ptype -
> > > > > there are few reserved values right now.
> > > > > if one day we'll run out bits in let say RTE_PTYPE_L2_MASK and will have to increase its size -
> > > > > it would mean change of the packet_type layout and possible ABI breakage anyway.
> > > >
> > > > I'm aware of this, only pointing out we tend to rely on masks and type
> > > > boundaries a bit too much when there are other methods that are as (if not
> > > > more) convenient.
> > >
> > > Yes, we do rely on masks in ptype.
> > > That's how ptype was defined.
> > > Let say to check that incoming packet is Ether/IPv4(no extentions)/UDP,
> > > you probably would do:
> > >
> > > if (mbuf->packet_type & (RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK | RTE_PTYPE_L4_MASK) ==
> > > (RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4 | RTE_PTYPE_L4_UDP)) {...}
> >
> > All right, let's not use a different method to filter packet types.
> >
> > > > Perhaps some sort of tunneled packet types beyond inner L4 consuming the
> > > > four remaining bits will be added? That could happen soon.
> > >
> > > As I said above: do you have particular scenario in mind when 32bits for packet_type
> > > might be not enough?
> > > If yes, then it is probably a good idea to submit an RFC for extending it to 64 bit,
> > > or introduce packet_type2, or whatever would be your preferred way to deal with it.
> >
> > No, really, I guess we'll extend ptype to 64 bit when necessary. My point on
> > filtering separately still stands.
> >
> > > Konstantin
> > >
> >
> > --
> > Adrien Mazarguil
> > 6WIND
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH 1/4] mem: add --single-file to create single mem-backed file
@ 2016-01-10 11:42 2% ` Jianfeng Tan
1 sibling, 0 replies; 200+ results
From: Jianfeng Tan @ 2016-01-10 11:42 UTC (permalink / raw)
To: dev; +Cc: nakajima.yoshihiro, mst, ann.zhuangyanying
Originally, there're two cons in using hugepage: a. needs root
privilege to touch /proc/self/pagemap, which is a premise to
alllocate physically contiguous memseg; b. possibly too many
hugepage file are created, especially used with 2M hugepage.
For virtual devices, they don't care about physical-contiguity
of allocated hugepages at all. Option --single-file is to
provide a way to allocate all hugepages into single mem-backed
file.
Known issue:
a. single-file option relys on kernel to allocate numa-affinitive
memory.
b. possible ABI break, originally, --no-huge uses anonymous memory
instead of file-backed way to create memory.
Signed-off-by: Huawei Xie <huawei.xie@intel.com>
Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
---
lib/librte_eal/common/eal_common_options.c | 17 +++++++++++
lib/librte_eal/common/eal_internal_cfg.h | 1 +
lib/librte_eal/common/eal_options.h | 2 ++
lib/librte_eal/linuxapp/eal/eal_memory.c | 45 ++++++++++++++++++++++++++----
4 files changed, 60 insertions(+), 5 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c
index 29942ea..65bccbd 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -95,6 +95,7 @@ eal_long_options[] = {
{OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM },
{OPT_VMWARE_TSC_MAP, 0, NULL, OPT_VMWARE_TSC_MAP_NUM },
{OPT_XEN_DOM0, 0, NULL, OPT_XEN_DOM0_NUM },
+ {OPT_SINGLE_FILE, 0, NULL, OPT_SINGLE_FILE_NUM },
{0, 0, NULL, 0 }
};
@@ -897,6 +898,10 @@ eal_parse_common_option(int opt, const char *optarg,
}
break;
+ case OPT_SINGLE_FILE_NUM:
+ conf->single_file = 1;
+ break;
+
/* don't know what to do, leave this to caller */
default:
return 1;
@@ -956,6 +961,16 @@ eal_check_common_options(struct internal_config *internal_cfg)
"be specified together with --"OPT_NO_HUGE"\n");
return -1;
}
+ if (internal_cfg->single_file && internal_cfg->force_sockets == 1) {
+ RTE_LOG(ERR, EAL, "Option --"OPT_SINGLE_FILE" cannot "
+ "be specified together with --"OPT_SOCKET_MEM"\n");
+ return -1;
+ }
+ if (internal_cfg->single_file && internal_cfg->hugepage_unlink) {
+ RTE_LOG(ERR, EAL, "Option --"OPT_HUGE_UNLINK" cannot "
+ "be specified together with --"OPT_SINGLE_FILE"\n");
+ return -1;
+ }
if (internal_cfg->no_hugetlbfs && internal_cfg->hugepage_unlink) {
RTE_LOG(ERR, EAL, "Option --"OPT_HUGE_UNLINK" cannot "
@@ -994,6 +1009,8 @@ eal_common_usage(void)
" -n CHANNELS Number of memory channels\n"
" -m MB Memory to allocate (see also --"OPT_SOCKET_MEM")\n"
" -r RANKS Force number of memory ranks (don't detect)\n"
+ " --"OPT_SINGLE_FILE" Create just single file for shared memory, and \n"
+ " do not promise physical contiguity of memseg\n"
" -b, --"OPT_PCI_BLACKLIST" Add a PCI device in black list.\n"
" Prevent EAL from using this PCI device. The argument\n"
" format is <domain:bus:devid.func>.\n"
diff --git a/lib/librte_eal/common/eal_internal_cfg.h b/lib/librte_eal/common/eal_internal_cfg.h
index 5f1367e..9117ed9 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -61,6 +61,7 @@ struct hugepage_info {
*/
struct internal_config {
volatile size_t memory; /**< amount of asked memory */
+ volatile unsigned single_file; /**< mmap all hugepages in single file */
volatile unsigned force_nchannel; /**< force number of channels */
volatile unsigned force_nrank; /**< force number of ranks */
volatile unsigned no_hugetlbfs; /**< true to disable hugetlbfs */
diff --git a/lib/librte_eal/common/eal_options.h b/lib/librte_eal/common/eal_options.h
index a881c62..e5da14a 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -83,6 +83,8 @@ enum {
OPT_VMWARE_TSC_MAP_NUM,
#define OPT_XEN_DOM0 "xen-dom0"
OPT_XEN_DOM0_NUM,
+#define OPT_SINGLE_FILE "single-file"
+ OPT_SINGLE_FILE_NUM,
OPT_LONG_MAX_NUM
};
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 846fd31..2bb1163 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -80,6 +80,10 @@
#include <errno.h>
#include <sys/ioctl.h>
#include <sys/time.h>
+#include <mntent.h>
+#include <sys/mman.h>
+#include <sys/file.h>
+#include <sys/vfs.h>
#include <rte_log.h>
#include <rte_memory.h>
@@ -92,6 +96,9 @@
#include <rte_common.h>
#include <rte_string_fns.h>
+#define _GNU_SOURCE
+#include <sys/syscall.h>
+
#include "eal_private.h"
#include "eal_internal_cfg.h"
#include "eal_filesystem.h"
@@ -768,6 +775,7 @@ create_shared_memory(const char *filename, const size_t mem_size)
}
retval = mmap(NULL, mem_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
close(fd);
+
return retval;
}
@@ -1110,10 +1118,34 @@ rte_eal_hugepage_init(void)
/* get pointer to global configuration */
mcfg = rte_eal_get_configuration()->mem_config;
- /* hugetlbfs can be disabled */
- if (internal_config.no_hugetlbfs) {
+ /* when hugetlbfs is disabled or single-file option is specified */
+ if (internal_config.no_hugetlbfs || internal_config.single_file) {
+ int fd;
+ uint64_t pagesize;
+ unsigned socket_id;
+ char filepath[MAX_HUGEPAGE_PATH];
+
+ syscall(SYS_getcpu, NULL, &socket_id, NULL);
+
+ if (internal_config.no_hugetlbfs) {
+ eal_get_hugefile_path(filepath, sizeof(filepath),
+ "/dev/shm", 0);
+ pagesize = RTE_PGSIZE_4K;
+ } else {
+ struct hugepage_info *hpi = &internal_config.hugepage_info[0];
+ eal_get_hugefile_path(filepath, sizeof(filepath),
+ hpi->hugedir, 0);
+ pagesize = hpi->hugepage_sz;
+ }
+ fd = open(filepath, O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
+ if (fd < 0) {
+ RTE_LOG(ERR, EAL, "%s: open %s failed: %s\n", __func__,
+ filepath, strerror(errno));
+ return -1;
+ }
+
addr = mmap(NULL, internal_config.memory, PROT_READ | PROT_WRITE,
- MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+ MAP_SHARED | MAP_POPULATE, fd, 0);
if (addr == MAP_FAILED) {
RTE_LOG(ERR, EAL, "%s: mmap() failed: %s\n", __func__,
strerror(errno));
@@ -1121,9 +1153,12 @@ rte_eal_hugepage_init(void)
}
mcfg->memseg[0].phys_addr = (phys_addr_t)(uintptr_t)addr;
mcfg->memseg[0].addr = addr;
- mcfg->memseg[0].hugepage_sz = RTE_PGSIZE_4K;
+ mcfg->memseg[0].hugepage_sz = pagesize;
mcfg->memseg[0].len = internal_config.memory;
- mcfg->memseg[0].socket_id = 0;
+ mcfg->memseg[0].socket_id = socket_id;
+
+ close(fd);
+
return 0;
}
--
2.1.4
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del
@ 2016-01-11 8:28 3% ` Lu, Wenzhuo
2016-01-11 8:41 3% ` Vincent JARDIN
2016-01-12 12:37 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Lu, Wenzhuo @ 2016-01-11 8:28 UTC (permalink / raw)
To: Vincent JARDIN; +Cc: dev
Hi Vincent,
From: Vincent JARDIN [mailto:vincent.jardin@6wind.com]
Sent: Monday, January 11, 2016 3:41 PM
To: Lu, Wenzhuo <wenzhuo.lu@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del
see inline
Le 11 janv. 2016 08:08, "Wenzhuo Lu" <wenzhuo.lu@intel.com<mailto:wenzhuo.lu@intel.com>> a écrit :
>
> Add UDP tunnel add/del support on ixgbe. Now it only support
> VxLAN port configuration.
> Although the VxLAN port has a default value 4789, it can be
> changed. We support VxLAN port configuration to meet the
> change.
> Note, the default value of VxLAN port in ixgbe NICs is 0. So
> please set it when using VxLAN off-load.
>
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com<mailto:wenzhuo.lu@intel.com>>
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 93 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 93 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 4c4c6df..381cbad 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -337,6 +337,10 @@ static int ixgbe_timesync_read_time(struct rte_eth_dev *dev,
> struct timespec *timestamp);
> static int ixgbe_timesync_write_time(struct rte_eth_dev *dev,
> const struct timespec *timestamp);
> +static int ixgbe_dev_udp_tunnel_add(struct rte_eth_dev *dev,
> + struct rte_eth_udp_tunnel *udp_tunnel);
> +static int ixgbe_dev_udp_tunnel_del(struct rte_eth_dev *dev,
> + struct rte_eth_udp_tunnel *udp_tunnel);
>
> /*
> * Define VF Stats MACRO for Non "cleared on read" register
> @@ -495,6 +499,8 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
> .timesync_adjust_time = ixgbe_timesync_adjust_time,
> .timesync_read_time = ixgbe_timesync_read_time,
> .timesync_write_time = ixgbe_timesync_write_time,
> + .udp_tunnel_add = ixgbe_dev_udp_tunnel_add,
> + .udp_tunnel_del = ixgbe_dev_udp_tunnel_del,
> };
>
Your patch is not adding HW tunnel support but port management.
> /*
> @@ -6191,6 +6197,93 @@ ixgbe_dev_get_dcb_info(struct rte_eth_dev *dev,
> return 0;
> }
>
> +#define DEFAULT_VXLAN_PORT 4789
> +
> +/* on x550, there's only one register for VxLAN UDP port.
> + * So, we cannot add or del the port. We only update it.
> + */
> +static int
> +ixgbe_update_vxlan_port(struct ixgbe_hw *hw,
> + uint16_t port)
> +{
> + IXGBE_WRITE_REG(hw, IXGBE_VXLANCTRL, port);
> + IXGBE_WRITE_FLUSH(hw);
> +
> + return 0;
> +}
> +
> +/* Add UDP tunneling port */
> +static int
> +ixgbe_dev_udp_tunnel_add(struct rte_eth_dev *dev,
> + struct rte_eth_udp_tunnel *udp_tunnel)
> +{
> + int ret = 0;
> + struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> + if (hw->mac.type != ixgbe_mac_X550 &&
> + hw->mac.type != ixgbe_mac_X550EM_x) {
> + return -ENOTSUP;
> + }
> +
> + if (udp_tunnel == NULL)
> + return -EINVAL;
> +
> + switch (udp_tunnel->prot_type) {
> + case RTE_TUNNEL_TYPE_VXLAN:
> + /* cannot add a port, update the port value */
> + ret = ixgbe_update_vxlan_port(hw, udp_tunnel->udp_port);
> + break;
> +
> + case RTE_TUNNEL_TYPE_GENEVE:
> + case RTE_TUNNEL_TYPE_TEREDO:
> + PMD_DRV_LOG(ERR, "Tunnel type is not supported now.");
> + ret = -1;
> + break;
> +
> + default:
> + PMD_DRV_LOG(ERR, "Invalid tunnel type");
> + ret = -1;
> + break;
> + }
> +
> + return ret;
> +}
Is tunnel_add a proper naming? We need to keep flexibility for NICs that will support full HW tunneling support.
Here it is about setting registers.
> +
> +/* Remove UDP tunneling port */
> +static int
> +ixgbe_dev_udp_tunnel_del(struct rte_eth_dev *dev,
> + struct rte_eth_udp_tunnel *udp_tunnel)
> +{
> + int ret = 0;
> + struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> + if (hw->mac.type != ixgbe_mac_X550 &&
> + hw->mac.type != ixgbe_mac_X550EM_x) {
> + return -ENOTSUP;
> + }
> +
> + if (udp_tunnel == NULL)
> + return -EINVAL;
> +
> + switch (udp_tunnel->prot_type) {
> + case RTE_TUNNEL_TYPE_VXLAN:
> + /* cannot del the port, reset it to default */
> + ret = ixgbe_update_vxlan_port(hw, DEFAULT_VXLAN_PORT);
> + break;
> + case RTE_TUNNEL_TYPE_GENEVE:
> + case RTE_TUNNEL_TYPE_TEREDO:
> + PMD_DRV_LOG(ERR, "Tunnel type is not supported now.");
> + ret = -1;
> + break;
> + default:
> + PMD_DRV_LOG(ERR, "Invalid tunnel type");
> + ret = -1;
> + break;
> + }
> +
> + return ret;
> +}
> +
> static struct rte_driver rte_ixgbe_driver = {
> .type = PMD_PDEV,
> .init = rte_ixgbe_pmd_init,
> --
> 1.9.3
>
I think the semantic of this serie should be revisited. It is about adding the support of inner/outer checksum for encapsulated packets but not the support of HW encap/decap (tunnel?).
[Wenzhuo] The udp_tunnel_add and udp_tunnel_del have already existed. I just use them. Honestly I agree with you they are not accurate name. Better change them to udp_tunnel_port_add and udp_tunnel_port_del. But it should be a ABI change if I’m not wrong. I think we can announce it this release and change them in the next release. Would you agree? Thanks.
Thank you,
Vincent
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del
2016-01-11 8:28 3% ` Lu, Wenzhuo
@ 2016-01-11 8:41 3% ` Vincent JARDIN
2016-01-12 12:37 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Vincent JARDIN @ 2016-01-11 8:41 UTC (permalink / raw)
To: Lu, Wenzhuo; +Cc: dev
> [Wenzhuo] The udp_tunnel_add and udp_tunnel_del have already existed. I
just use them. Honestly I agree with you they are not accurate name. Better
change them to udp_tunnel_port_add and udp_tunnel_port_del. But it should
be a ABI change if I’m not wrong. I think we can announce it this release
and change them in the next release. Would you agree? Thanks.
Yes you are right.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC v2 0/2] ethdev: Enhancements to flow director filter
2015-12-23 12:41 3% ` [dpdk-dev] [RFC v2 0/2] ethdev: Enhancements to flow director filter Rahul Lakkireddy
@ 2016-01-11 13:50 0% ` Rahul Lakkireddy
0 siblings, 0 replies; 200+ results
From: Rahul Lakkireddy @ 2016-01-11 13:50 UTC (permalink / raw)
To: dev; +Cc: Kumar Sanghvi, Felix Marti, Nirranjan Kirubaharan
Hi All,
On Wednesday, December 12/23/15, 2015 at 18:11:19 +0530, Rahul Lakkireddy wrote:
> This RFC series of patches attempt to extend the flow director filter to
> add support for Chelsio T5 hardware filtering capabilities.
>
> Chelsio T5 supports carrying out filtering in hardware which supports 3
> actions to carry out on a packet which hit a filter viz.
>
> 1. Action Pass - Packets hitting a filter rule can be directed to a
> particular RXQ.
>
> 2. Action Drop - Packets hitting a filter rule are dropped in h/w.
>
> 3. Action Switch - Packets hitting a filter rule can be switched in h/w
> from one port to another, without involvement of host. Also, the
> action Switch also supports rewrite of src-mac/dst-mac headers as
> well as rewrite of vlan headers. It also supports rewrite of IP
> headers and thereby, supports NAT (Network Address Translation)
> in h/w.
>
> Also, each filter rule can optionally support specifying a mask value
> i.e. it's possible to create a filter rule for an entire subnet of IP
> addresses or a range of tcp/udp ports, etc.
>
> Patch 1 does the following:
> - Adds an additional flow rte_eth_pkt_filter_flow which encapsulates
> ingress ports, l2 payload, vlan and ntuples.
> - Adds an additional mask for the flow to allow range of values to be
> matched.
> - Adds an ability to set both filters with masks (Maskfull) and
> without masks (Maskless). Also allow prioritizing one of these
> filter types over the other when a packet matches several types.
> - Adds a new behavior 'switch'.
> - Adds behavior arguments that can be passed when a particular behavior
> is taken. For ex: in case of action 'switch', pass additional 4-tuple
> to allow rewriting src/dst ip and port addresses to support NAT'ing.
>
> Patch 2 shows testpmd command line example to support packet filter
> flow.
>
> The patch series has been compile tested on all x86 gcc targets and the
> current fdir filter supported drivers seem to return appropriate error
> codes when this new flow type and the new action are not supported and
> hence are not affected.
>
> Posting this series mainly for discussion on API change. Once this is
> agreeable then, I will post the cxgbe PMD changes to use the new API.
>
> ---
> v2:
> 1. Added ttl to rte_eth_ipv4_flow and tc, flow_label, next_header,
> and hop_limit to rte_eth_ipv6_flow.
>
> 2. Added new field type to rte_eth_pkt_filter_flow to differentiate
> between maskfull and maskless filter types.
>
> 3. Added new field prio to rte_eth_pkt_filter_flow to allow setting
> priority over maskfull or maskless when packet matches multiple
> filter types.
>
> 4. Added new behavior sub op RTE_FDIR_BEHAVIOR_SUB_OP_SWAP to allow
> swapping fields in matched flows. For ex, useful when swapping mac
> addresses in hardware before switching.
>
> 5. Updated the testpmd example to reflect the above new changes.
>
> 6. Dropped Patch 3 since the ABI announcement has already been merged.
>
> Rahul Lakkireddy (2):
> ethdev: add packet filter flow and new behavior switch to fdir
> testpmd: add an example to show packet filter flow
>
> app/test-pmd/cmdline.c | 528 +++++++++++++++++++++++++++++++++++++++-
> lib/librte_ether/rte_eth_ctrl.h | 127 +++++++++-
> 2 files changed, 646 insertions(+), 9 deletions(-)
>
> --
> 2.5.3
>
Any comments on this RFC series? If the overall approach is fine then,
I'll re-submit it as a PATCH series along with the CXGBE PMD driver
changes.
Thanks,
Rahul
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
@ 2016-01-12 10:04 3% ` Pavel Fedin
2016-01-12 10:48 0% ` Tan, Jianfeng
0 siblings, 1 reply; 200+ results
From: Pavel Fedin @ 2016-01-12 10:04 UTC (permalink / raw)
To: 'Tan, Jianfeng', 'Rich Lane'
Cc: nakajima.yoshihiro, 'Michael S. Tsirkin', dev, ann.zhuangyanying
Hello!
>> Should this be "hugepage->size = internal_config.memory"? Otherwise the vhost-user
>> memtable entry has a size of only 2MB.
> I don't think so. See the definition:
> 47 struct hugepage_file {
> 48 void *orig_va; /**< virtual addr of first mmap() */
> 49 void *final_va; /**< virtual addr of 2nd mmap() */
> 50 uint64_t physaddr; /**< physical addr */
> 51 size_t size; /**< the page size */
> 52 int socket_id; /**< NUMA socket ID */
> 53 int file_id; /**< the '%d' in HUGEFILE_FMT */
> 54 int memseg_id; /**< the memory segment to which page belongs */
> 55 #ifdef RTE_EAL_SINGLE_FILE_SEGMENTS
> 56 int repeated; /**< number of times the page size is repeated */
> 57 #endif
> 58 char filepath[MAX_HUGEPAGE_PATH]; /**< path to backing file on filesystem */
> 59 };
> size stands for the page size instead of total size.
But in this case host gets this page size for total region size, therefore qva_to_vva() fails.
I haven't worked with hugepages, but i guess that with real hugepages we get one file per page, therefore page size == mapping size. With newly introduced --single-file we now have something that pretends to be a single "uber-huge-page", so we need to specify total size of the mapping here.
BTW, i'm still unhappy about ABI breakage here. I think we could easily add --shared-mem option, which would simply change mapping mode to SHARED. So, we could use it with both hugepages (default) and plain mmap (with --no-hugepages).
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
2016-01-12 10:04 3% ` Pavel Fedin
@ 2016-01-12 10:48 0% ` Tan, Jianfeng
2016-01-12 11:00 0% ` Pavel Fedin
0 siblings, 1 reply; 200+ results
From: Tan, Jianfeng @ 2016-01-12 10:48 UTC (permalink / raw)
To: Pavel Fedin, 'Rich Lane'
Cc: nakajima.yoshihiro, 'Michael S. Tsirkin', dev, ann.zhuangyanying
Hello!
> But in this case host gets this page size for total region size, therefore qva_to_vva() fails.
> I haven't worked with hugepages, but i guess that with real hugepages we get one file per page, therefore page size == mapping size. With newly introduced --single-file we now have something that pretends to be a single "uber-huge-page", so we need to specify total size of the mapping here.
Oh I get it and recognize the problem here. The actual problem lies in
the API rte_eal_get_backfile_info().
backfiles[i].size = hugepage_files[i].size;
Should use statfs or hugepage_files[i].size * hugepage_files[i].repeated
to calculate the total size.
>
> BTW, i'm still unhappy about ABI breakage here. I think we could easily add --shared-mem option, which would simply change mapping mode to SHARED. So, we could use it with both hugepages (default) and plain mmap (with --no-hugepages).
You mean, use "--no-hugepages --shared-mem" together, right?
That makes sense to me.
Thanks,
Jianfeng
>
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
>
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 0/3] ABI change for RETA, cmdline
2016-01-06 14:32 4% [dpdk-dev] [PATCH 0/3] ABI changes (RETA, cmdline) Nelio Laranjeiro
2016-01-06 14:32 11% ` [dpdk-dev] [PATCH 1/3] ethdev: change RETA type in rte_eth_rss_reta_entry64 Nelio Laranjeiro
2016-01-06 14:32 5% ` [dpdk-dev] [PATCH 2/3] cmdline: increase command line buffer Nelio Laranjeiro
@ 2016-01-12 10:49 4% ` Nelio Laranjeiro
2016-01-12 10:49 5% ` [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer Nelio Laranjeiro
2016-01-12 10:49 11% ` [dpdk-dev] [PATCH v2 2/3] ethdev: change RETA type in rte_eth_rss_reta_entry64 Nelio Laranjeiro
2 siblings, 2 replies; 200+ results
From: Nelio Laranjeiro @ 2016-01-12 10:49 UTC (permalink / raw)
To: dev
Previous version of commit
"cmdline: increase command line buffer", had side effects and was breaking
some commands.
In this version, I only applied John McNamara's solution which consists in
increasing only RDLINE_BUF_SIZE define from 256 to 512 bytes [1].
[1] http://dpdk.org/ml/archives/dev/2015-November/027643.html
Nelio Laranjeiro (3):
cmdline: increase command line buffer
ethdev: change RETA type in rte_eth_rss_reta_entry64
mlx5: increase RETA table size
app/test-pmd/cmdline.c | 4 ++--
doc/guides/rel_notes/deprecation.rst | 10 ----------
drivers/net/mlx5/mlx5_defs.h | 2 +-
lib/librte_cmdline/cmdline_rdline.h | 2 +-
lib/librte_ether/rte_ethdev.c | 2 +-
lib/librte_ether/rte_ethdev.h | 2 +-
6 files changed, 6 insertions(+), 16 deletions(-)
--
2.1.4
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer
2016-01-12 10:49 4% ` [dpdk-dev] [PATCH v2 0/3] ABI change for RETA, cmdline Nelio Laranjeiro
@ 2016-01-12 10:49 5% ` Nelio Laranjeiro
2016-01-12 12:46 3% ` Panu Matilainen
2016-01-12 10:49 11% ` [dpdk-dev] [PATCH v2 2/3] ethdev: change RETA type in rte_eth_rss_reta_entry64 Nelio Laranjeiro
1 sibling, 1 reply; 200+ results
From: Nelio Laranjeiro @ 2016-01-12 10:49 UTC (permalink / raw)
To: dev
Allow long command lines in testpmd (like flow director with IPv6, ...).
Signed-off-by: John McNamara <john.mcnamara@intel.com>
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
doc/guides/rel_notes/deprecation.rst | 5 -----
lib/librte_cmdline/cmdline_rdline.h | 2 +-
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..9cb288c 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -44,8 +44,3 @@ Deprecation Notices
and table action handlers will be updated:
the pipeline parameter will be added, the packets mask parameter will be
either removed (for input port action handler) or made input-only.
-
-* ABI changes are planned in cmdline buffer size to allow the use of long
- commands (such as RETA update in testpmd). This should impact
- CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
- It should be integrated in release 2.3.
diff --git a/lib/librte_cmdline/cmdline_rdline.h b/lib/librte_cmdline/cmdline_rdline.h
index b9aad9b..72e2dad 100644
--- a/lib/librte_cmdline/cmdline_rdline.h
+++ b/lib/librte_cmdline/cmdline_rdline.h
@@ -93,7 +93,7 @@ extern "C" {
#endif
/* configuration */
-#define RDLINE_BUF_SIZE 256
+#define RDLINE_BUF_SIZE 512
#define RDLINE_PROMPT_SIZE 32
#define RDLINE_VT100_BUF_SIZE 8
#define RDLINE_HISTORY_BUF_SIZE BUFSIZ
--
2.1.4
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v2 2/3] ethdev: change RETA type in rte_eth_rss_reta_entry64
2016-01-12 10:49 4% ` [dpdk-dev] [PATCH v2 0/3] ABI change for RETA, cmdline Nelio Laranjeiro
2016-01-12 10:49 5% ` [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer Nelio Laranjeiro
@ 2016-01-12 10:49 11% ` Nelio Laranjeiro
1 sibling, 0 replies; 200+ results
From: Nelio Laranjeiro @ 2016-01-12 10:49 UTC (permalink / raw)
To: dev
Several NICs can handle 512 entries/queues in their RETA table, an 8 bit field
is not large enough for them.
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
app/test-pmd/cmdline.c | 4 ++--
doc/guides/rel_notes/deprecation.rst | 5 -----
lib/librte_ether/rte_ethdev.c | 2 +-
lib/librte_ether/rte_ethdev.h | 2 +-
4 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..9c7cda0 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1767,7 +1767,7 @@ parse_reta_config(const char *str,
int i;
unsigned size;
uint16_t hash_index, idx, shift;
- uint8_t nb_queue;
+ uint16_t nb_queue;
char s[256];
const char *p, *p0 = str;
char *end;
@@ -1800,7 +1800,7 @@ parse_reta_config(const char *str,
}
hash_index = (uint16_t)int_fld[FLD_HASH_INDEX];
- nb_queue = (uint8_t)int_fld[FLD_QUEUE];
+ nb_queue = (uint16_t)int_fld[FLD_QUEUE];
if (hash_index >= nb_entries) {
printf("Invalid RETA hash index=%d\n", hash_index);
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 9cb288c..9930b5a 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -15,11 +15,6 @@ Deprecation Notices
* The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
must be updated to support 100G link and to have a cleaner link speed API.
-* ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
- which handles at most 256 queues (8 bits) while newer NICs support larger
- tables (512 queues).
- It should be integrated in release 2.3.
-
* ABI changes are planned for struct rte_eth_fdir_flow in order to support
extend flow director's input set. The release 2.2 does not contain these ABI
changes, but release 2.3 will, and no backwards compatibility is planned.
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index ed971b4..b0aa94d 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1857,7 +1857,7 @@ rte_eth_check_reta_mask(struct rte_eth_rss_reta_entry64 *reta_conf,
static int
rte_eth_check_reta_entry(struct rte_eth_rss_reta_entry64 *reta_conf,
uint16_t reta_size,
- uint8_t max_rxq)
+ uint16_t max_rxq)
{
uint16_t i, idx, shift;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index bada8ad..8302a2d 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -520,7 +520,7 @@ struct rte_eth_mirror_conf {
struct rte_eth_rss_reta_entry64 {
uint64_t mask;
/**< Mask bits indicate which entries need to be updated/queried. */
- uint8_t reta[RTE_RETA_GROUP_SIZE];
+ uint16_t reta[RTE_RETA_GROUP_SIZE];
/**< Group of 64 redirection table entries. */
};
--
2.1.4
^ permalink raw reply [relevance 11%]
* Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
2016-01-12 10:48 0% ` Tan, Jianfeng
@ 2016-01-12 11:00 0% ` Pavel Fedin
2016-01-12 11:07 0% ` Sergio Gonzalez Monroy
0 siblings, 1 reply; 200+ results
From: Pavel Fedin @ 2016-01-12 11:00 UTC (permalink / raw)
To: 'Tan, Jianfeng', 'Rich Lane'
Cc: nakajima.yoshihiro, 'Michael S. Tsirkin', dev, ann.zhuangyanying
Hello!
> > BTW, i'm still unhappy about ABI breakage here. I think we could easily add --shared-mem
> option, which would simply change mapping mode to SHARED. So, we could use it with both
> hugepages (default) and plain mmap (with --no-hugepages).
>
> You mean, use "--no-hugepages --shared-mem" together, right?
Yes. This would be perfectly backwards-compatible because.
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
2016-01-12 11:00 0% ` Pavel Fedin
@ 2016-01-12 11:07 0% ` Sergio Gonzalez Monroy
2016-01-12 11:44 3% ` Sergio Gonzalez Monroy
0 siblings, 2 replies; 200+ results
From: Sergio Gonzalez Monroy @ 2016-01-12 11:07 UTC (permalink / raw)
To: Pavel Fedin
Cc: nakajima.yoshihiro, 'Michael S. Tsirkin', dev, ann.zhuangyanying
Hi Pavel,
On 12/01/2016 11:00, Pavel Fedin wrote:
> Hello!
>
>>> BTW, i'm still unhappy about ABI breakage here. I think we could easily add --shared-mem
>> option, which would simply change mapping mode to SHARED. So, we could use it with both
>> hugepages (default) and plain mmap (with --no-hugepages).
>>
>> You mean, use "--no-hugepages --shared-mem" together, right?
> Yes. This would be perfectly backwards-compatible because.
So are you suggesting to not introduce --single-file option but instead
--shared-mem?
AFAIK --single-file was trying to workaround the limitation of just
being able to map 8 fds.
Sergio
> Kind regards,
> Pavel Fedin
> Senior Engineer
> Samsung Electronics Research center Russia
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
2016-01-12 11:07 0% ` Sergio Gonzalez Monroy
@ 2016-01-12 11:44 3% ` Sergio Gonzalez Monroy
1 sibling, 0 replies; 200+ results
From: Sergio Gonzalez Monroy @ 2016-01-12 11:44 UTC (permalink / raw)
To: Pavel Fedin
Cc: dev, nakajima.yoshihiro, ann.zhuangyanying, 'Michael S. Tsirkin'
On 12/01/2016 11:07, Sergio Gonzalez Monroy wrote:
> Hi Pavel,
>
> On 12/01/2016 11:00, Pavel Fedin wrote:
>> Hello!
>>
>>>> BTW, i'm still unhappy about ABI breakage here. I think we could
>>>> easily add --shared-mem
Could you elaborate a bit more on your concerns regarding ABI breakage ?
>>> option, which would simply change mapping mode to SHARED. So, we
>>> could use it with both
>>> hugepages (default) and plain mmap (with --no-hugepages).
>>>
>>> You mean, use "--no-hugepages --shared-mem" together, right?
>> Yes. This would be perfectly backwards-compatible because.
>
> So are you suggesting to not introduce --single-file option but
> instead --shared-mem?
> AFAIK --single-file was trying to workaround the limitation of just
> being able to map 8 fds.
>
My bad, I misread the posts.
Jianfeng pointed out that you are suggesting to have --shared-mem to
have same functionality
with or without hugepages.
Sergio
> Sergio
>> Kind regards,
>> Pavel Fedin
>> Senior Engineer
>> Samsung Electronics Research center Russia
>>
>>
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del
2016-01-11 8:28 3% ` Lu, Wenzhuo
2016-01-11 8:41 3% ` Vincent JARDIN
@ 2016-01-12 12:37 0% ` Thomas Monjalon
2016-01-13 2:50 0% ` Lu, Wenzhuo
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2016-01-12 12:37 UTC (permalink / raw)
To: Lu, Wenzhuo; +Cc: dev
Hi,
2016-01-11 08:28, Lu, Wenzhuo:
> [Wenzhuo] The udp_tunnel_add and udp_tunnel_del have already existed. I just use them. Honestly I agree with you they are not accurate name. Better change them to udp_tunnel_port_add and udp_tunnel_port_del. But it should be a ABI change if I’m not wrong. I think we can announce it this release and change them in the next release. Would you agree? Thanks.
You can introduce the new name and keep the old one for backward compat
while announcing its deprecation.
Thanks
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer
2016-01-12 10:49 5% ` [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer Nelio Laranjeiro
@ 2016-01-12 12:46 3% ` Panu Matilainen
2016-01-15 8:44 3% ` Nélio Laranjeiro
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-12 12:46 UTC (permalink / raw)
To: Nelio Laranjeiro, dev
On 01/12/2016 12:49 PM, Nelio Laranjeiro wrote:
> Allow long command lines in testpmd (like flow director with IPv6, ...).
>
> Signed-off-by: John McNamara <john.mcnamara@intel.com>
> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 5 -----
> lib/librte_cmdline/cmdline_rdline.h | 2 +-
> 2 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index e94d4a2..9cb288c 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -44,8 +44,3 @@ Deprecation Notices
> and table action handlers will be updated:
> the pipeline parameter will be added, the packets mask parameter will be
> either removed (for input port action handler) or made input-only.
> -
> -* ABI changes are planned in cmdline buffer size to allow the use of long
> - commands (such as RETA update in testpmd). This should impact
> - CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
> - It should be integrated in release 2.3.
> diff --git a/lib/librte_cmdline/cmdline_rdline.h b/lib/librte_cmdline/cmdline_rdline.h
> index b9aad9b..72e2dad 100644
> --- a/lib/librte_cmdline/cmdline_rdline.h
> +++ b/lib/librte_cmdline/cmdline_rdline.h
> @@ -93,7 +93,7 @@ extern "C" {
> #endif
>
> /* configuration */
> -#define RDLINE_BUF_SIZE 256
> +#define RDLINE_BUF_SIZE 512
> #define RDLINE_PROMPT_SIZE 32
> #define RDLINE_VT100_BUF_SIZE 8
> #define RDLINE_HISTORY_BUF_SIZE BUFSIZ
Having to break a library ABI for a change like this is a bit ridiculous.
I didn't try it so could be wrong, but based on a quick look, struct
rdline could easily be made opaque to consumers by just adding functions
for allocating and freeing it.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
@ 2016-01-12 13:57 3% ` Pavel Fedin
2016-01-12 14:13 4% ` Sergio Gonzalez Monroy
0 siblings, 1 reply; 200+ results
From: Pavel Fedin @ 2016-01-12 13:57 UTC (permalink / raw)
To: 'Sergio Gonzalez Monroy'
Cc: nakajima.yoshihiro, 'Michael S. Tsirkin', dev, ann.zhuangyanying
Hello!
> I might be missing something obvious here but, aside from having memory
> SHARED which most DPDK apps using hugepages will have anyway, what is
> the backward compatibility issues that you see here?
Heh, sorry once again for confusing. Indeed, with hugepages we always get MAP_SHARED. I missed that. So, we indeed need
--shared-mem only in addition to --no-huge.
Backwards compatibility issue is stated in the description of PATCH 1/4:
--- cut ---
b. possible ABI break, originally, --no-huge uses anonymous memory
instead of file-backed way to create memory.
--- cut ---
The patch unconditionally changes that to SHARED. That's all.
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
2016-01-12 13:57 3% ` Pavel Fedin
@ 2016-01-12 14:13 4% ` Sergio Gonzalez Monroy
0 siblings, 0 replies; 200+ results
From: Sergio Gonzalez Monroy @ 2016-01-12 14:13 UTC (permalink / raw)
To: Pavel Fedin
Cc: nakajima.yoshihiro, 'Michael S. Tsirkin', dev, ann.zhuangyanying
On 12/01/2016 13:57, Pavel Fedin wrote:
> Hello!
>
>> I might be missing something obvious here but, aside from having memory
>> SHARED which most DPDK apps using hugepages will have anyway, what is
>> the backward compatibility issues that you see here?
> Heh, sorry once again for confusing. Indeed, with hugepages we always get MAP_SHARED. I missed that. So, we indeed need
> --shared-mem only in addition to --no-huge.
>
> Backwards compatibility issue is stated in the description of PATCH 1/4:
> --- cut ---
> b. possible ABI break, originally, --no-huge uses anonymous memory
> instead of file-backed way to create memory.
> --- cut ---
> The patch unconditionally changes that to SHARED. That's all.
I should read more carefully!
Sorry about that, I thought you were the one with the ABI concerns.
Regarding ABI, I don't think there is any ABI issue with the change, we
just have our memory file-backed and SHARED but we do that when using
hugepages so I don't think it would be a huge issue.
But if folks have concerns about it, we could always keep old behavior
by default and, as you suggest, introduce another option for changing
the flag.
Sergio
> Kind regards,
> Pavel Fedin
> Senior Engineer
> Samsung Electronics Research center Russia
>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del
2016-01-12 12:37 0% ` Thomas Monjalon
@ 2016-01-13 2:50 0% ` Lu, Wenzhuo
0 siblings, 0 replies; 200+ results
From: Lu, Wenzhuo @ 2016-01-13 2:50 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, January 12, 2016 8:37 PM
> To: Lu, Wenzhuo <wenzhuo.lu@intel.com>
> Cc: dev@dpdk.org; Vincent JARDIN <vincent.jardin@6wind.com>
> Subject: Re: [dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del
>
> Hi,
>
> 2016-01-11 08:28, Lu, Wenzhuo:
> > [Wenzhuo] The udp_tunnel_add and udp_tunnel_del have already existed.
> I just use them. Honestly I agree with you they are not accurate name. Better
> change them to udp_tunnel_port_add and udp_tunnel_port_del. But it
> should be a ABI change if I’m not wrong. I think we can announce it this
> release and change them in the next release. Would you agree? Thanks.
>
> You can introduce the new name and keep the old one for backward compat
> while announcing its deprecation.
Good suggestion, I'll send a new patch set for this change. Thanks.
> Thanks
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
2015-12-31 17:12 3% ` Stephen Hemminger
@ 2016-01-13 11:55 3% ` Bruce Richardson
2016-01-13 12:22 3% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2016-01-13 11:55 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Ziye Yang, dev
On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
> On Tue, 29 Dec 2015 10:53:26 +0800
> Ziye Yang <ziye.yang@intel.com> wrote:
>
> > This patch is used to add the class_id support
> > for pci_probe since some devices need the class_info
> > (class_code, subclass_code, programming_interface)
> >
> > Signed-off-by: Ziye Yang <ziye.yang@intel.com>
>
> Since rte_pci is exposed to application this breaks the ABI.
But applications are not going to be defining rte_pci_ids values internally, are
they? That is for drivers to use. Is this really an ABI breakage for applications that we
need to be concerned about?
/Bruce
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
2016-01-13 11:55 3% ` Bruce Richardson
@ 2016-01-13 12:22 3% ` Panu Matilainen
2016-01-28 21:38 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-13 12:22 UTC (permalink / raw)
To: Bruce Richardson, Stephen Hemminger; +Cc: Ziye Yang, dev
On 01/13/2016 01:55 PM, Bruce Richardson wrote:
> On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
>> On Tue, 29 Dec 2015 10:53:26 +0800
>> Ziye Yang <ziye.yang@intel.com> wrote:
>>
>>> This patch is used to add the class_id support
>>> for pci_probe since some devices need the class_info
>>> (class_code, subclass_code, programming_interface)
>>>
>>> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
>>
>> Since rte_pci is exposed to application this breaks the ABI.
>
> But applications are not going to be defining rte_pci_ids values internally, are
> they? That is for drivers to use. Is this really an ABI breakage for applications that we
> need to be concerned about?
There might not be applications using it but drivers are ABI consumers
too - think of 3rd party drivers and such.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 00/14] Step towards PCI independency
@ 2016-01-13 14:07 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2016-01-13 14:07 UTC (permalink / raw)
To: Jan Viktorin; +Cc: dev
Hello Jan,
On Mon, Jan 11, 2016 at 6:29 PM, Jan Viktorin <viktorin@rehivetech.com> wrote:
> Hello David,
>
> did you find time to see the patchset? I am working on a PMD on top of
> these so I'd be glad to base on the code close to the (potentially)
> upstreamed one.
I took a quick look but since we still have an abi breakage, I am
trying to put my ideas on paper and will share to you asap.
Regards,
--
David Marchand
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v2 1/6] lib/librte_ether: change function name of tunnel port config
@ 2016-01-14 1:38 4% ` Wenzhuo Lu
0 siblings, 0 replies; 200+ results
From: Wenzhuo Lu @ 2016-01-14 1:38 UTC (permalink / raw)
To: dev
The names of function for tunnel port configuration are not
accurate. They're tunnel_add/del, better change them to
tunnel_port_add/del.
As it may be an ABI change if change the names directly, the
new functions are added but not remove the old ones. The old
ones will be removed in the next release after an ABI change
announcement.
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
---
app/test-pmd/cmdline.c | 6 +++--
examples/tep_termination/vxlan_setup.c | 2 +-
lib/librte_ether/rte_ethdev.c | 45 ++++++++++++++++++++++++++++++++++
lib/librte_ether/rte_ethdev.h | 18 ++++++++++++++
4 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..4e71e90 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6780,9 +6780,11 @@ cmd_tunnel_udp_config_parsed(void *parsed_result,
tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN;
if (!strcmp(res->what, "add"))
- ret = rte_eth_dev_udp_tunnel_add(res->port_id, &tunnel_udp);
+ ret = rte_eth_dev_udp_tunnel_port_add(res->port_id,
+ &tunnel_udp);
else
- ret = rte_eth_dev_udp_tunnel_delete(res->port_id, &tunnel_udp);
+ ret = rte_eth_dev_udp_tunnel_port_delete(res->port_id,
+ &tunnel_udp);
if (ret < 0)
printf("udp tunneling add error: (%s)\n", strerror(-ret));
diff --git a/examples/tep_termination/vxlan_setup.c b/examples/tep_termination/vxlan_setup.c
index 51ad133..8836603 100644
--- a/examples/tep_termination/vxlan_setup.c
+++ b/examples/tep_termination/vxlan_setup.c
@@ -191,7 +191,7 @@ vxlan_port_init(uint8_t port, struct rte_mempool *mbuf_pool)
/* Configure UDP port for UDP tunneling */
tunnel_udp.udp_port = udp_port;
tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN;
- retval = rte_eth_dev_udp_tunnel_add(port, &tunnel_udp);
+ retval = rte_eth_dev_udp_tunnel_port_add(port, &tunnel_udp);
if (retval < 0)
return retval;
rte_eth_macaddr_get(port, &ports_eth_addr[port]);
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index ed971b4..74428f4 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1987,6 +1987,28 @@ rte_eth_dev_udp_tunnel_add(uint8_t port_id,
}
int
+rte_eth_dev_udp_tunnel_port_add(uint8_t port_id,
+ struct rte_eth_udp_tunnel *udp_tunnel)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ if (udp_tunnel == NULL) {
+ RTE_PMD_DEBUG_TRACE("Invalid udp_tunnel parameter\n");
+ return -EINVAL;
+ }
+
+ if (udp_tunnel->prot_type >= RTE_TUNNEL_TYPE_MAX) {
+ RTE_PMD_DEBUG_TRACE("Invalid tunnel type\n");
+ return -EINVAL;
+ }
+
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->udp_tunnel_port_add, -ENOTSUP);
+ return (*dev->dev_ops->udp_tunnel_port_add)(dev, udp_tunnel);
+}
+
+int
rte_eth_dev_udp_tunnel_delete(uint8_t port_id,
struct rte_eth_udp_tunnel *udp_tunnel)
{
@@ -2010,6 +2032,29 @@ rte_eth_dev_udp_tunnel_delete(uint8_t port_id,
}
int
+rte_eth_dev_udp_tunnel_port_delete(uint8_t port_id,
+ struct rte_eth_udp_tunnel *udp_tunnel)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ if (udp_tunnel == NULL) {
+ RTE_PMD_DEBUG_TRACE("Invalid udp_tunnel parameter\n");
+ return -EINVAL;
+ }
+
+ if (udp_tunnel->prot_type >= RTE_TUNNEL_TYPE_MAX) {
+ RTE_PMD_DEBUG_TRACE("Invalid tunnel type\n");
+ return -EINVAL;
+ }
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->udp_tunnel_port_del, -ENOTSUP);
+ return (*dev->dev_ops->udp_tunnel_port_del)(dev, udp_tunnel);
+}
+
+int
rte_eth_led_on(uint8_t port_id)
{
struct rte_eth_dev *dev;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index bada8ad..2e064f4 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1261,6 +1261,14 @@ typedef int (*eth_set_eeprom_t)(struct rte_eth_dev *dev,
struct rte_dev_eeprom_info *info);
/**< @internal Program eeprom data */
+typedef int (*eth_udp_tunnel_port_add_t)(struct rte_eth_dev *dev,
+ struct rte_eth_udp_tunnel *tunnel_udp);
+/**< @internal Add tunneling UDP port */
+
+typedef int (*eth_udp_tunnel_port_del_t)(struct rte_eth_dev *dev,
+ struct rte_eth_udp_tunnel *tunnel_udp);
+/**< @internal Delete tunneling UDP port */
+
#ifdef RTE_NIC_BYPASS
enum {
@@ -1443,6 +1451,10 @@ struct eth_dev_ops {
eth_timesync_read_time timesync_read_time;
/** Set the device clock time. */
eth_timesync_write_time timesync_write_time;
+ /** Add UDP tunnel port. */
+ eth_udp_tunnel_port_add_t udp_tunnel_port_add;
+ /** Del UDP tunnel port. */
+ eth_udp_tunnel_port_del_t udp_tunnel_port_del;
};
/**
@@ -3408,6 +3420,9 @@ rte_eth_dev_rss_hash_conf_get(uint8_t port_id,
int
rte_eth_dev_udp_tunnel_add(uint8_t port_id,
struct rte_eth_udp_tunnel *tunnel_udp);
+int
+rte_eth_dev_udp_tunnel_port_add(uint8_t port_id,
+ struct rte_eth_udp_tunnel *tunnel_udp);
/**
* Detete UDP tunneling port configuration of Ethernet device
@@ -3425,6 +3440,9 @@ rte_eth_dev_udp_tunnel_add(uint8_t port_id,
int
rte_eth_dev_udp_tunnel_delete(uint8_t port_id,
struct rte_eth_udp_tunnel *tunnel_udp);
+int
+rte_eth_dev_udp_tunnel_port_delete(uint8_t port_id,
+ struct rte_eth_udp_tunnel *tunnel_udp);
/**
* Check whether the filter type is supported on an Ethernet device.
--
1.9.3
^ permalink raw reply [relevance 4%]
* [dpdk-dev] Proposal for a big eal / ethdev cleanup
@ 2016-01-14 10:38 2% David Marchand
2016-01-14 11:46 4% ` Jan Viktorin
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: David Marchand @ 2016-01-14 10:38 UTC (permalink / raw)
To: dev; +Cc: Jan Viktorin
Hello all,
Here is a proposal of a big cleanup in ethdev (cryptodev would have to
follow) and eal structures.
This is something I wanted to do for quite some time and the arrival of
a new bus makes me think we need it.
This is an alternative to what Jan proposed [1].
ABI is most likely broken with this, but I think this discussion can come later.
First some context on how dpdk is initialized at the moment :
Let's imagine a system with one ixgbe pci device and take some
part of ixgbe driver as an example.
static struct eth_driver rte_ixgbe_pmd = {
.pci_drv = {
.name = "rte_ixgbe_pmd",
.id_table = pci_id_ixgbe_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING |
RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_DETACHABLE,
},
.eth_dev_init = eth_ixgbe_dev_init,
.eth_dev_uninit = eth_ixgbe_dev_uninit,
.dev_private_size = sizeof(struct ixgbe_adapter),
};
static int
rte_ixgbe_pmd_init(const char *name __rte_unused, const char *params
__rte_unused)
{
PMD_INIT_FUNC_TRACE();
rte_eth_driver_register(&rte_ixgbe_pmd);
return 0;
}
static struct rte_driver rte_ixgbe_driver = {
.type = PMD_PDEV,
.init = rte_ixgbe_pmd_init,
};
PMD_REGISTER_DRIVER(rte_ixgbe_driver)
DPDK initialisation goes as follows (focusing on ixgbe driver):
PMD_REGISTER_DRIVER(rte_ixgbe_driver) which adds it to dev_driver_list
rte_eal_init()
-> rte_eal_pci_init()
-> rte_eal_pci_scan() which fills pci_device_list
-> rte_eal_dev_init()
-> for each rte_driver (first vdev, then pdev), call driver->init()
so here rte_ixgbe_pmd_init(NULL, NULL)
-> rte_eth_driver_register(&rte_ixgbe_pmd);
-> fills rte_ixgbe_pmd.pci_drv.devinit = rte_eth_dev_init
-> call rte_eal_pci_register() which adds it to pci_driver_list
-> rte_eal_pci_probe()
-> for each rte_pci_device found in rte_eal_pci_scan(), and for all
rte_pci_driver registered, call devinit(dr, dev),
so here rte_eth_dev_init(dr, dev)
-> creates a new eth_dev (which is a rte_eth_dev), then adds
reference to passed dev pointer (which is a rte_pci_device), to
passed dr pointer (which is a rte_pci_driver cast as a eth_driver)
-> call eth_drv->eth_dev_init(eth_dev)
so here eth_ixgbe_dev_init(eth_dev)
-> fills other parts of eth_dev
-> rte_eth_copy_pci_info(eth_dev, pci_dev)
By the way, when invoking ethdev init, the pci-specific stuff is only
handled in functions called from the drivers themselves, which already
know that they are dealing with pci resources.
Later in the life of the application, ethdev api is called for hotplug.
int rte_eth_dev_attach(const char *devargs, uint8_t *port_id);
A devargs is used to identify a vdev/pdev driver and call it to create a
new rte_eth_dev.
Current code goes as far as parsing devargs to understand if this is a
pci device or a vdev.
This part should be moved to eal since this is where all the "bus" logic
is.
So now, what I had in mind is something like this.
It is far from perfect and I certainly did some shortcuts in my
reasoning.
Generic device/driver
- introduce a rte_device structure,
- a rte_device has a name, that identifies it in a unique way across
all buses, maybe something like pci:0000:00:01.0, and for vdev,
vdev:name
- a rte_device references a rte_driver,
- a rte_device references devargs
- a rte_device embeds a intr_handle
- rte_device objects are created by "buses"
- a function to retrieve rte_device objects based on name is added
- current rte_driver does not need to know about the pmd_type
(pdev/vdev), this is only a way to order drivers init in eal, we could
use the rte_driver names to order them or maybe remove this ordering
- init and uninit functions are changed to take a pointer to a
rte_device
rte_device and rte_driver structures are at the "bus" level.
Those are the basic structures we will build the other objects on.
Impact on PCI device/driver
- rte_pci_device is modified to embed a rte_device (embedding makes it
possible later to cast the rte_device and get the rte_pci_device in pci
specific functions)
- no need for a rte_pci_driver reference in rte_pci_device, since we
have the rte_device driver
- rte_pci_driver is modified to embed a rte_driver
- no more devinit and devuninit functions in rte_pci_driver, they can
be moved as init / uninit functions in rte_driver
- pci scan code creates rte_pci_device objects, associates them to
rte_pci_driver, fills the driver field of the rte_driver then pass
them to rte_driver init function.
rte_pci_device and rte_pci_driver are specific implementation of
rte_device and rte_driver.
There are there to maintain pci private methods, create upper layer
objects (ethdev / crypto) etc..
Impact on vdev
- introduce a rte_vdev_driver structure
- a rte_vdev_driver embeds a rte_driver
- a rte_vdev_driver has a priv size for vdev objects creation
- no need for a vdev device object, this is specific to vdev drivers
- eal init code associates devargs to vdev drivers, creates a
rte_device object (using the priv size), fills the driver field then
pass them to rte_driver init function.
Impact on ethdev
- a rte_eth_dev object references a rte_device in place of
rte_pci_device
- no more information about a driver in rte_eth_dev, this is the
rte_device that has a reference to its rte_driver
- eth_driver can be removed, it is only a wrapper of a rte_pci_driver
at the moment, maybe some init function wrappers can stay in ethdev
with dev_private_size to be handled in the rte_driver
- rte_eth_dev objects are created by rte_drivers during probe (pci
scan, vdev init, hotplug)
- ethdev ops are populated by rte_drivers
Impact on hotplug
- hotplug moves from ethdev to eal
- a notification framework is added to ethdev when hotplugging
- eal uses the name (remember the pci:0000:00:01.0 / vdev:name
example) in devargs to identify the right bus (pci / vdev)
- pci scan code is reused to create a rte_pci_device object etc...
- vdev init code is reused
We end up with something like this.
An arrow means that the structure contains a pointer to an object of the
other struct.
I only wrote the fields I mentioned in this mail, for pci device a lot
of other fields are omitted.
- for ethdev on top of pci devices
+------------------+ +-------------------------------+
| | | |
| rte_pci_device | | rte_pci_driver |
| | | |
+-------------+ | +--------------+ | | +---------------------------+ |
| | | | | | | | | |
| rte_eth_dev +---> rte_device +-----> rte_driver | |
| | | | char name[] | | | | char name[] | |
+-------------+ | | | | | | int init(rte_device *) | |
| +--------------+ | | | int uninit(rte_device *) | |
| | | | | |
+------------------+ | +---------------------------+ |
| |
+-------------------------------+
- for ethdev on top of vdev devices
+------------------+ +-------------------------------+
| | | |
| drv specific | | rte_vdev_driver |
| | | |
+-------------+ | +--------------+ | | +---------------------------+ |
| | | | | | | | | |
| rte_eth_dev +---> rte_device +-----> rte_driver | |
| | | | char name[] | | | | char name[] | |
+-------------+ | | | | | | int init(rte_device *) | |
| +--------------+ | | | int uninit(rte_device *) | |
| | | | | |
+------------------+ | +---------------------------+ |
| |
| int priv_size |
| |
+-------------------------------+
Thanks for reading.
Comments ?
--
David Marchand
[1] http://dpdk.org/ml/archives/dev/2016-January/030975.html
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] Proposal for a big eal / ethdev cleanup
2016-01-14 10:38 2% [dpdk-dev] Proposal for a big eal / ethdev cleanup David Marchand
@ 2016-01-14 11:46 4% ` Jan Viktorin
2016-01-16 15:53 0% ` David Marchand
2016-01-18 14:54 0% ` Declan Doherty
[not found] ` <20160118155834.04cb31f2@pcviktorin.fit.vutbr.cz>
2 siblings, 1 reply; 200+ results
From: Jan Viktorin @ 2016-01-14 11:46 UTC (permalink / raw)
To: David Marchand; +Cc: dev
Hello David,
nice to see that the things are moving...
On Thu, 14 Jan 2016 11:38:16 +0100
David Marchand <david.marchand@6wind.com> wrote:
> Hello all,
>
> Here is a proposal of a big cleanup in ethdev (cryptodev would have to
> follow) and eal structures.
> This is something I wanted to do for quite some time and the arrival of
> a new bus makes me think we need it.
>
> This is an alternative to what Jan proposed [1].
As I need to extend DPDK by a non-PCI bus system, I would prefer any such
working solution :). By [1], you probably mean:
[1] http://comments.gmane.org/gmane.comp.networking.dpdk.devel/30973
(I didn't find it in the e-mail.)
>
> ABI is most likely broken with this, but I think this discussion can come later.
I was trying in my initial approach to stay as much API and ABI backwards
compatible as possible to be acceptable into upstream. As just a few
people have shown their interest in these changes, I consider the ABI
compatibility very important.
I can see, that your approach does not care too much... Otherwise, it looks
good to me. It is closer to the Linux drivers infra, so it seems to be clearer
then the current one.
>
>
> First some context on how dpdk is initialized at the moment :
>
> Let's imagine a system with one ixgbe pci device and take some
> part of ixgbe driver as an example.
>
> static struct eth_driver rte_ixgbe_pmd = {
> .pci_drv = {
> .name = "rte_ixgbe_pmd",
> .id_table = pci_id_ixgbe_map,
> .drv_flags = RTE_PCI_DRV_NEED_MAPPING |
> RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_DETACHABLE,
> },
> .eth_dev_init = eth_ixgbe_dev_init,
> .eth_dev_uninit = eth_ixgbe_dev_uninit,
> .dev_private_size = sizeof(struct ixgbe_adapter),
> };
Note, that the biggest issue here is that the eth_driver has no way to
distinguish among PCI or other subsystem. There is no field that helps
the generic ethdev code (librte_ether) to decide what bus we are on
(and it needs to know it in the current DPDK).
Another point is that the ethdev infra should not know about the
underlying bus infra. The question is whether we do a big clean
up (extract PCI-bus code out) or a small clean up (give the ethdev
infra a hint which bus system it deals with).
>
> static int
> rte_ixgbe_pmd_init(const char *name __rte_unused, const char *params
> __rte_unused)
> {
> PMD_INIT_FUNC_TRACE();
> rte_eth_driver_register(&rte_ixgbe_pmd);
> return 0;
> }
>
> static struct rte_driver rte_ixgbe_driver = {
> .type = PMD_PDEV,
> .init = rte_ixgbe_pmd_init,
> };
>
> PMD_REGISTER_DRIVER(rte_ixgbe_driver)
>
>
> DPDK initialisation goes as follows (focusing on ixgbe driver):
>
> PMD_REGISTER_DRIVER(rte_ixgbe_driver) which adds it to dev_driver_list
>
> rte_eal_init()
> -> rte_eal_pci_init()
> -> rte_eal_pci_scan() which fills pci_device_list
>
> -> rte_eal_dev_init()
> -> for each rte_driver (first vdev, then pdev), call driver->init()
> so here rte_ixgbe_pmd_init(NULL, NULL)
> -> rte_eth_driver_register(&rte_ixgbe_pmd);
> -> fills rte_ixgbe_pmd.pci_drv.devinit = rte_eth_dev_init
> -> call rte_eal_pci_register() which adds it to pci_driver_list
>
> -> rte_eal_pci_probe()
> -> for each rte_pci_device found in rte_eal_pci_scan(), and for all
> rte_pci_driver registered, call devinit(dr, dev),
> so here rte_eth_dev_init(dr, dev)
> -> creates a new eth_dev (which is a rte_eth_dev), then adds
> reference to passed dev pointer (which is a rte_pci_device), to
> passed dr pointer (which is a rte_pci_driver cast as a eth_driver)
> -> call eth_drv->eth_dev_init(eth_dev)
> so here eth_ixgbe_dev_init(eth_dev)
> -> fills other parts of eth_dev
> -> rte_eth_copy_pci_info(eth_dev, pci_dev)
>
>
> By the way, when invoking ethdev init, the pci-specific stuff is only
> handled in functions called from the drivers themselves, which already
> know that they are dealing with pci resources.
This is an important note as it allows to (almost) avoid touching the
current drivers.
>
>
> Later in the life of the application, ethdev api is called for hotplug.
>
> int rte_eth_dev_attach(const char *devargs, uint8_t *port_id);
>
> A devargs is used to identify a vdev/pdev driver and call it to create a
> new rte_eth_dev.
> Current code goes as far as parsing devargs to understand if this is a
> pci device or a vdev.
> This part should be moved to eal since this is where all the "bus" logic
> is.
Parsing of devargs is quite wierd - I mean whitelisting and
blacklisting. At the moment, it guesses whether the given argument is
a PCI device identification or an arbitrary string (vdev). It is not
easy to extend this reliably.
OK, I can see you are addressing this below.
>
>
>
> So now, what I had in mind is something like this.
> It is far from perfect and I certainly did some shortcuts in my
> reasoning.
>
>
> Generic device/driver
>
> - introduce a rte_device structure,
> - a rte_device has a name, that identifies it in a unique way across
> all buses, maybe something like pci:0000:00:01.0, and for vdev,
> vdev:name
Having a prefix is good but would this break the user API? Is the
name exposed to users?
> - a rte_device references a rte_driver,
> - a rte_device references devargs
> - a rte_device embeds a intr_handle
> - rte_device objects are created by "buses"
> - a function to retrieve rte_device objects based on name is added
>
> - current rte_driver does not need to know about the pmd_type
> (pdev/vdev), this is only a way to order drivers init in eal, we could
> use the rte_driver names to order them or maybe remove this ordering
What is the main reason to have pdev/vdev distinction here? After I
register the driver, does eal really need to know the pmd_type?
Moreover, there is no way how to pass arguments to pdevs, only to
vdevs. This was shortly disscussed in [2] for the szedata2 PMD.
[2] http://dpdk.org/ml/archives/dev/2015-October/026285.html
> - init and uninit functions are changed to take a pointer to a
> rte_device
>
> rte_device and rte_driver structures are at the "bus" level.
> Those are the basic structures we will build the other objects on.
>
>
> Impact on PCI device/driver
>
> - rte_pci_device is modified to embed a rte_device (embedding makes it
> possible later to cast the rte_device and get the rte_pci_device in pci
> specific functions)
> - no need for a rte_pci_driver reference in rte_pci_device, since we
> have the rte_device driver
I've noticed that DPDK does not use any kind of the container_of macro
like the Linux Kernel does. Instead, some considerations like the
rte_pci_driver MUST be placed at the beginning of the eth_driver (if I
am not mistaken). Here, it should be considered to do it another way.
>
> - rte_pci_driver is modified to embed a rte_driver
> - no more devinit and devuninit functions in rte_pci_driver, they can
> be moved as init / uninit functions in rte_driver
>
> - pci scan code creates rte_pci_device objects, associates them to
> rte_pci_driver, fills the driver field of the rte_driver then pass
> them to rte_driver init function.
>
> rte_pci_device and rte_pci_driver are specific implementation of
> rte_device and rte_driver.
> There are there to maintain pci private methods, create upper layer
> objects (ethdev / crypto) etc..
>
>
> Impact on vdev
>
> - introduce a rte_vdev_driver structure
> - a rte_vdev_driver embeds a rte_driver
> - a rte_vdev_driver has a priv size for vdev objects creation
>
> - no need for a vdev device object, this is specific to vdev drivers
>
> - eal init code associates devargs to vdev drivers, creates a
> rte_device object (using the priv size), fills the driver field then
> pass them to rte_driver init function.
>
>
> Impact on ethdev
>
> - a rte_eth_dev object references a rte_device in place of
> rte_pci_device
> - no more information about a driver in rte_eth_dev, this is the
> rte_device that has a reference to its rte_driver
> - eth_driver can be removed, it is only a wrapper of a rte_pci_driver
> at the moment, maybe some init function wrappers can stay in ethdev
> with dev_private_size to be handled in the rte_driver
> - rte_eth_dev objects are created by rte_drivers during probe (pci
> scan, vdev init, hotplug)
> - ethdev ops are populated by rte_drivers
>
>
> Impact on hotplug
>
> - hotplug moves from ethdev to eal
> - a notification framework is added to ethdev when hotplugging
This seems to be a good idea. I was suprised to find such code in
librte_ether...
>
> - eal uses the name (remember the pci:0000:00:01.0 / vdev:name
> example) in devargs to identify the right bus (pci / vdev)
> - pci scan code is reused to create a rte_pci_device object etc...
> - vdev init code is reused
>
>
> We end up with something like this.
> An arrow means that the structure contains a pointer to an object of the
> other struct.
> I only wrote the fields I mentioned in this mail, for pci device a lot
> of other fields are omitted.
>
> - for ethdev on top of pci devices
>
> +------------------+ +-------------------------------+
> | | | |
> | rte_pci_device | | rte_pci_driver |
> | | | |
> +-------------+ | +--------------+ | | +---------------------------+ |
> | | | | | | | | | |
> | rte_eth_dev +---> rte_device +-----> rte_driver | |
> | | | | char name[] | | | | char name[] | |
> +-------------+ | | | | | | int init(rte_device *) | |
> | +--------------+ | | | int uninit(rte_device *) | |
> | | | | | |
> +------------------+ | +---------------------------+ |
> | |
> +-------------------------------+
>
> - for ethdev on top of vdev devices
>
> +------------------+ +-------------------------------+
> | | | |
> | drv specific | | rte_vdev_driver |
> | | | |
> +-------------+ | +--------------+ | | +---------------------------+ |
> | | | | | | | | | |
> | rte_eth_dev +---> rte_device +-----> rte_driver | |
> | | | | char name[] | | | | char name[] | |
> +-------------+ | | | | | | int init(rte_device *) | |
> | +--------------+ | | | int uninit(rte_device *) | |
> | | | | | |
> +------------------+ | +---------------------------+ |
> | |
> | int priv_size |
> | |
> +-------------------------------+
>
>
> Thanks for reading.
> Comments ?
>
>
--
Jan Viktorin E-mail: Viktorin@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer
2016-01-12 12:46 3% ` Panu Matilainen
@ 2016-01-15 8:44 3% ` Nélio Laranjeiro
2016-01-15 9:00 3% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Nélio Laranjeiro @ 2016-01-15 8:44 UTC (permalink / raw)
To: Panu Matilainen, john.mcnamara; +Cc: dev
On Tue, Jan 12, 2016 at 02:46:07PM +0200, Panu Matilainen wrote:
> On 01/12/2016 12:49 PM, Nelio Laranjeiro wrote:
> >Allow long command lines in testpmd (like flow director with IPv6, ...).
> >
> >Signed-off-by: John McNamara <john.mcnamara@intel.com>
> >Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> >---
> > doc/guides/rel_notes/deprecation.rst | 5 -----
> > lib/librte_cmdline/cmdline_rdline.h | 2 +-
> > 2 files changed, 1 insertion(+), 6 deletions(-)
> >
> >diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> >index e94d4a2..9cb288c 100644
> >--- a/doc/guides/rel_notes/deprecation.rst
> >+++ b/doc/guides/rel_notes/deprecation.rst
> >@@ -44,8 +44,3 @@ Deprecation Notices
> > and table action handlers will be updated:
> > the pipeline parameter will be added, the packets mask parameter will be
> > either removed (for input port action handler) or made input-only.
> >-
> >-* ABI changes are planned in cmdline buffer size to allow the use of long
> >- commands (such as RETA update in testpmd). This should impact
> >- CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
> >- It should be integrated in release 2.3.
> >diff --git a/lib/librte_cmdline/cmdline_rdline.h b/lib/librte_cmdline/cmdline_rdline.h
> >index b9aad9b..72e2dad 100644
> >--- a/lib/librte_cmdline/cmdline_rdline.h
> >+++ b/lib/librte_cmdline/cmdline_rdline.h
> >@@ -93,7 +93,7 @@ extern "C" {
> > #endif
> >
> > /* configuration */
> >-#define RDLINE_BUF_SIZE 256
> >+#define RDLINE_BUF_SIZE 512
> > #define RDLINE_PROMPT_SIZE 32
> > #define RDLINE_VT100_BUF_SIZE 8
> > #define RDLINE_HISTORY_BUF_SIZE BUFSIZ
>
> Having to break a library ABI for a change like this is a bit ridiculous.
Sure, but John McNamara needed it to handle flow director with IPv6[1].
For my part, I was needing it to manipulate the RETA table, but as I
wrote in the cover letter, it ends by breaking other commands.
Olivier Matz, has proposed another way to handle long commands lines[2],
it could be a good idea to go on this direction.
For RETA situation, we already discussed on a new API, but for now, I
do not have time for it (and as it is another ABI breakage it could only
be done for 16.07 or 2.4)[3].
If this patch is no more needed we can just drop it, for that I would
like to have the point of view from John.
>
> I didn't try it so could be wrong, but based on a quick look, struct rdline
> could easily be made opaque to consumers by just adding functions for
> allocating and freeing it.
>
> - Panu -
>
[1] http://dpdk.org/ml/archives/dev/2015-November/027643.html
[2] http://dpdk.org/ml/archives/dev/2015-November/028557.html
[3] http://dpdk.org/ml/archives/dev/2015-October/025294.html
--
Nélio Laranjeiro
6WIND
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer
2016-01-15 8:44 3% ` Nélio Laranjeiro
@ 2016-01-15 9:00 3% ` Panu Matilainen
2016-01-18 14:38 4% ` Olivier MATZ
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-15 9:00 UTC (permalink / raw)
To: Nélio Laranjeiro, john.mcnamara; +Cc: dev
On 01/15/2016 10:44 AM, Nélio Laranjeiro wrote:
> On Tue, Jan 12, 2016 at 02:46:07PM +0200, Panu Matilainen wrote:
>> On 01/12/2016 12:49 PM, Nelio Laranjeiro wrote:
>>> Allow long command lines in testpmd (like flow director with IPv6, ...).
>>>
>>> Signed-off-by: John McNamara <john.mcnamara@intel.com>
>>> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
>>> ---
>>> doc/guides/rel_notes/deprecation.rst | 5 -----
>>> lib/librte_cmdline/cmdline_rdline.h | 2 +-
>>> 2 files changed, 1 insertion(+), 6 deletions(-)
>>>
>>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
>>> index e94d4a2..9cb288c 100644
>>> --- a/doc/guides/rel_notes/deprecation.rst
>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>> @@ -44,8 +44,3 @@ Deprecation Notices
>>> and table action handlers will be updated:
>>> the pipeline parameter will be added, the packets mask parameter will be
>>> either removed (for input port action handler) or made input-only.
>>> -
>>> -* ABI changes are planned in cmdline buffer size to allow the use of long
>>> - commands (such as RETA update in testpmd). This should impact
>>> - CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
>>> - It should be integrated in release 2.3.
>>> diff --git a/lib/librte_cmdline/cmdline_rdline.h b/lib/librte_cmdline/cmdline_rdline.h
>>> index b9aad9b..72e2dad 100644
>>> --- a/lib/librte_cmdline/cmdline_rdline.h
>>> +++ b/lib/librte_cmdline/cmdline_rdline.h
>>> @@ -93,7 +93,7 @@ extern "C" {
>>> #endif
>>>
>>> /* configuration */
>>> -#define RDLINE_BUF_SIZE 256
>>> +#define RDLINE_BUF_SIZE 512
>>> #define RDLINE_PROMPT_SIZE 32
>>> #define RDLINE_VT100_BUF_SIZE 8
>>> #define RDLINE_HISTORY_BUF_SIZE BUFSIZ
>>
>> Having to break a library ABI for a change like this is a bit ridiculous.
>
> Sure, but John McNamara needed it to handle flow director with IPv6[1].
>
> For my part, I was needing it to manipulate the RETA table, but as I
> wrote in the cover letter, it ends by breaking other commands.
> Olivier Matz, has proposed another way to handle long commands lines[2],
> it could be a good idea to go on this direction.
>
> For RETA situation, we already discussed on a new API, but for now, I
> do not have time for it (and as it is another ABI breakage it could only
> be done for 16.07 or 2.4)[3].
>
> If this patch is no more needed we can just drop it, for that I would
> like to have the point of view from John.
Note that I was not objecting to the patch as such, I can easily see 256
characters not being enough for commandline buffer.
I was merely noting that having to break an ABI to increase an
effectively internal buffer size is a sign of a, um, less-than-optimal
library design.
Apologies if I wasn't clear about that,
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] Proposal for a big eal / ethdev cleanup
2016-01-14 11:46 4% ` Jan Viktorin
@ 2016-01-16 15:53 0% ` David Marchand
2016-01-18 15:49 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2016-01-16 15:53 UTC (permalink / raw)
To: Jan Viktorin; +Cc: dev
Hello Jan,
On Thu, Jan 14, 2016 at 12:46 PM, Jan Viktorin <viktorin@rehivetech.com> wrote:
> On Thu, 14 Jan 2016 11:38:16 +0100
> David Marchand <david.marchand@6wind.com> wrote:
>
>> Hello all,
>>
>> Here is a proposal of a big cleanup in ethdev (cryptodev would have to
>> follow) and eal structures.
>> This is something I wanted to do for quite some time and the arrival of
>> a new bus makes me think we need it.
>>
>> This is an alternative to what Jan proposed [1].
>
> As I need to extend DPDK by a non-PCI bus system, I would prefer any such
> working solution :). By [1], you probably mean:
>
> [1] http://comments.gmane.org/gmane.comp.networking.dpdk.devel/30973
>
> (I didn't find it in the e-mail.)
Thought I put the reference after my signature.
Anyway, yes, I was referring to your thread.
>> ABI is most likely broken with this, but I think this discussion can come later.
>
> I was trying in my initial approach to stay as much API and ABI backwards
> compatible as possible to be acceptable into upstream. As just a few
> people have shown their interest in these changes, I consider the ABI
> compatibility very important.
>
> I can see, that your approach does not care too much... Otherwise, it looks
> good to me. It is closer to the Linux drivers infra, so it seems to be clearer
> then the current one.
I did this on purpose.
>From my point of view, we will have an API/ABI breakage in this code
at one point.
So I sent this mail to show where I'd like us to go, because this
looks saner on the mid/long term.
>> First some context on how dpdk is initialized at the moment :
>>
>> Let's imagine a system with one ixgbe pci device and take some
>> part of ixgbe driver as an example.
>>
>> static struct eth_driver rte_ixgbe_pmd = {
>> .pci_drv = {
>> .name = "rte_ixgbe_pmd",
>> .id_table = pci_id_ixgbe_map,
>> .drv_flags = RTE_PCI_DRV_NEED_MAPPING |
>> RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_DETACHABLE,
>> },
>> .eth_dev_init = eth_ixgbe_dev_init,
>> .eth_dev_uninit = eth_ixgbe_dev_uninit,
>> .dev_private_size = sizeof(struct ixgbe_adapter),
>> };
>
> Note, that the biggest issue here is that the eth_driver has no way to
> distinguish among PCI or other subsystem. There is no field that helps
> the generic ethdev code (librte_ether) to decide what bus we are on
> (and it needs to know it in the current DPDK).
>
> Another point is that the ethdev infra should not know about the
> underlying bus infra. The question is whether we do a big clean
> up (extract PCI-bus code out) or a small clean up (give the ethdev
> infra a hint which bus system it deals with).
Yes, and I think these two choices are reflected by our two respective
proposals :-)
>> So now, what I had in mind is something like this.
>> It is far from perfect and I certainly did some shortcuts in my
>> reasoning.
>>
>>
>> Generic device/driver
>>
>> - introduce a rte_device structure,
>> - a rte_device has a name, that identifies it in a unique way across
>> all buses, maybe something like pci:0000:00:01.0, and for vdev,
>> vdev:name
>
> Having a prefix is good but would this break the user API? Is the
> name exposed to users?
Maybe define new apis, and wrap the old one in it ?
Not too sure, I need to experiment.
>> - current rte_driver does not need to know about the pmd_type
>> (pdev/vdev), this is only a way to order drivers init in eal, we could
>> use the rte_driver names to order them or maybe remove this ordering
>
> What is the main reason to have pdev/vdev distinction here? After I
> register the driver, does eal really need to know the pmd_type?
Already did some cleanup in the past because of pmd_type :
http://dpdk.org/browse/dpdk/commit/?id=78aecefed955917753bfb6f44ae970dde4c652d0
http://dpdk.org/browse/dpdk/commit/?id=6bc2415c3387ae72f2ce3677f0e3540e734583d5
For me, there is no reason but the init ordering (vdevs come before
pdevs), and I am pretty sure we don't need this for ethdev.
> Moreover, there is no way how to pass arguments to pdevs, only to
> vdevs. This was shortly disscussed in [2] for the szedata2 PMD.
>
> [2] http://dpdk.org/ml/archives/dev/2015-October/026285.html
Shorty discussed with Thomas, yes.
But after some experiments, it appears that you can pass devargs after
a whitelist option at init (--pci-whitelist
xxxx:xx:xx.x,whataniceoptionwehavehere=1).
This does not work for hotplug.
This is undocumented and this looks like a workaround, so I would
prefer we come up with a better api for 2.3.
>> Impact on PCI device/driver
>>
>> - rte_pci_device is modified to embed a rte_device (embedding makes it
>> possible later to cast the rte_device and get the rte_pci_device in pci
>> specific functions)
>> - no need for a rte_pci_driver reference in rte_pci_device, since we
>> have the rte_device driver
>
> I've noticed that DPDK does not use any kind of the container_of macro
> like the Linux Kernel does. Instead, some considerations like the
> rte_pci_driver MUST be placed at the beginning of the eth_driver (if I
> am not mistaken). Here, it should be considered to do it another way.
Ah, yes, we could use this.
Just did not think of using it :-)
Regards,
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer
2016-01-15 9:00 3% ` Panu Matilainen
@ 2016-01-18 14:38 4% ` Olivier MATZ
0 siblings, 0 replies; 200+ results
From: Olivier MATZ @ 2016-01-18 14:38 UTC (permalink / raw)
To: Panu Matilainen, Nélio Laranjeiro, john.mcnamara; +Cc: dev
Hi,
On 01/15/2016 10:00 AM, Panu Matilainen wrote:
>>>> diff --git a/lib/librte_cmdline/cmdline_rdline.h
>>>> b/lib/librte_cmdline/cmdline_rdline.h
>>>> index b9aad9b..72e2dad 100644
>>>> --- a/lib/librte_cmdline/cmdline_rdline.h
>>>> +++ b/lib/librte_cmdline/cmdline_rdline.h
>>>> @@ -93,7 +93,7 @@ extern "C" {
>>>> #endif
>>>>
>>>> /* configuration */
>>>> -#define RDLINE_BUF_SIZE 256
>>>> +#define RDLINE_BUF_SIZE 512
>>>> #define RDLINE_PROMPT_SIZE 32
>>>> #define RDLINE_VT100_BUF_SIZE 8
>>>> #define RDLINE_HISTORY_BUF_SIZE BUFSIZ
>>>
>>> Having to break a library ABI for a change like this is a bit
>>> ridiculous.
>>
>> Sure, but John McNamara needed it to handle flow director with IPv6[1].
>>
>> For my part, I was needing it to manipulate the RETA table, but as I
>> wrote in the cover letter, it ends by breaking other commands.
>> Olivier Matz, has proposed another way to handle long commands lines[2],
>> it could be a good idea to go on this direction.
>>
>> For RETA situation, we already discussed on a new API, but for now, I
>> do not have time for it (and as it is another ABI breakage it could only
>> be done for 16.07 or 2.4)[3].
>>
>> If this patch is no more needed we can just drop it, for that I would
>> like to have the point of view from John.
>
> Note that I was not objecting to the patch as such, I can easily see 256
> characters not being enough for commandline buffer.
>
> I was merely noting that having to break an ABI to increase an
> effectively internal buffer size is a sign of a, um, less-than-optimal
> library design.
You are right about the cmdline ABI. Changing this buffer size
should not imply an ABI change. I'll try to find some time to
investigate this issue.
Another question we could raise is: should we export the API of
librte_cmdline to external applications? Now that baremetal dpdk is
not supported, having this library in dpdk is probably useless as
we can surely find standard replacements for it. A first step could
be to mark it as "internal".
About the patch Nélio's patch itself, I'm not so convinced having more
than 256 characters is absolutely required, and I would prefer to see
the commands beeing reworked to be more human-readable. On the other
hand, the ABI breakage was announced so there is no reason to nack
this patch now.
Regards,
Olivier
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] Proposal for a big eal / ethdev cleanup
2016-01-14 10:38 2% [dpdk-dev] Proposal for a big eal / ethdev cleanup David Marchand
2016-01-14 11:46 4% ` Jan Viktorin
@ 2016-01-18 14:54 0% ` Declan Doherty
[not found] ` <20160118155834.04cb31f2@pcviktorin.fit.vutbr.cz>
2 siblings, 0 replies; 200+ results
From: Declan Doherty @ 2016-01-18 14:54 UTC (permalink / raw)
To: David Marchand, dev; +Cc: Jan Viktorin
On 14/01/16 10:38, David Marchand wrote:
> Hello all,
>
> Here is a proposal of a big cleanup in ethdev (cryptodev would have to
> follow) and eal structures.
> This is something I wanted to do for quite some time and the arrival of
> a new bus makes me think we need it.
>
> This is an alternative to what Jan proposed [1].
>
> ABI is most likely broken with this, but I think this discussion can come later.
>
>
> First some context on how dpdk is initialized at the moment :
>
> Let's imagine a system with one ixgbe pci device and take some
> part of ixgbe driver as an example.
>
> static struct eth_driver rte_ixgbe_pmd = {
> .pci_drv = {
> .name = "rte_ixgbe_pmd",
> .id_table = pci_id_ixgbe_map,
> .drv_flags = RTE_PCI_DRV_NEED_MAPPING |
> RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_DETACHABLE,
> },
> .eth_dev_init = eth_ixgbe_dev_init,
> .eth_dev_uninit = eth_ixgbe_dev_uninit,
> .dev_private_size = sizeof(struct ixgbe_adapter),
> };
>
> static int
> rte_ixgbe_pmd_init(const char *name __rte_unused, const char *params
> __rte_unused)
> {
> PMD_INIT_FUNC_TRACE();
> rte_eth_driver_register(&rte_ixgbe_pmd);
> return 0;
> }
>
> static struct rte_driver rte_ixgbe_driver = {
> .type = PMD_PDEV,
> .init = rte_ixgbe_pmd_init,
> };
>
> PMD_REGISTER_DRIVER(rte_ixgbe_driver)
>
>
> DPDK initialisation goes as follows (focusing on ixgbe driver):
>
> PMD_REGISTER_DRIVER(rte_ixgbe_driver) which adds it to dev_driver_list
>
> rte_eal_init()
> -> rte_eal_pci_init()
> -> rte_eal_pci_scan() which fills pci_device_list
>
> -> rte_eal_dev_init()
> -> for each rte_driver (first vdev, then pdev), call driver->init()
> so here rte_ixgbe_pmd_init(NULL, NULL)
> -> rte_eth_driver_register(&rte_ixgbe_pmd);
> -> fills rte_ixgbe_pmd.pci_drv.devinit = rte_eth_dev_init
> -> call rte_eal_pci_register() which adds it to pci_driver_list
>
> -> rte_eal_pci_probe()
> -> for each rte_pci_device found in rte_eal_pci_scan(), and for all
> rte_pci_driver registered, call devinit(dr, dev),
> so here rte_eth_dev_init(dr, dev)
> -> creates a new eth_dev (which is a rte_eth_dev), then adds
> reference to passed dev pointer (which is a rte_pci_device), to
> passed dr pointer (which is a rte_pci_driver cast as a eth_driver)
> -> call eth_drv->eth_dev_init(eth_dev)
> so here eth_ixgbe_dev_init(eth_dev)
> -> fills other parts of eth_dev
> -> rte_eth_copy_pci_info(eth_dev, pci_dev)
>
>
> By the way, when invoking ethdev init, the pci-specific stuff is only
> handled in functions called from the drivers themselves, which already
> know that they are dealing with pci resources.
>
>
> Later in the life of the application, ethdev api is called for hotplug.
>
> int rte_eth_dev_attach(const char *devargs, uint8_t *port_id);
>
> A devargs is used to identify a vdev/pdev driver and call it to create a
> new rte_eth_dev.
> Current code goes as far as parsing devargs to understand if this is a
> pci device or a vdev.
> This part should be moved to eal since this is where all the "bus" logic
> is.
>
>
>
> So now, what I had in mind is something like this.
> It is far from perfect and I certainly did some shortcuts in my
> reasoning.
>
>
> Generic device/driver
>
> - introduce a rte_device structure,
> - a rte_device has a name, that identifies it in a unique way across
> all buses, maybe something like pci:0000:00:01.0, and for vdev,
> vdev:name
> - a rte_device references a rte_driver,
> - a rte_device references devargs
> - a rte_device embeds a intr_handle
> - rte_device objects are created by "buses"
> - a function to retrieve rte_device objects based on name is added
>
> - current rte_driver does not need to know about the pmd_type
> (pdev/vdev), this is only a way to order drivers init in eal, we could
> use the rte_driver names to order them or maybe remove this ordering
> - init and uninit functions are changed to take a pointer to a
> rte_device
>
> rte_device and rte_driver structures are at the "bus" level.
> Those are the basic structures we will build the other objects on.
>
>
> Impact on PCI device/driver
>
> - rte_pci_device is modified to embed a rte_device (embedding makes it
> possible later to cast the rte_device and get the rte_pci_device in pci
> specific functions)
> - no need for a rte_pci_driver reference in rte_pci_device, since we
> have the rte_device driver
>
> - rte_pci_driver is modified to embed a rte_driver
> - no more devinit and devuninit functions in rte_pci_driver, they can
> be moved as init / uninit functions in rte_driver
>
> - pci scan code creates rte_pci_device objects, associates them to
> rte_pci_driver, fills the driver field of the rte_driver then pass
> them to rte_driver init function.
>
> rte_pci_device and rte_pci_driver are specific implementation of
> rte_device and rte_driver.
> There are there to maintain pci private methods, create upper layer
> objects (ethdev / crypto) etc..
>
>
> Impact on vdev
>
> - introduce a rte_vdev_driver structure
> - a rte_vdev_driver embeds a rte_driver
> - a rte_vdev_driver has a priv size for vdev objects creation
>
> - no need for a vdev device object, this is specific to vdev drivers
>
> - eal init code associates devargs to vdev drivers, creates a
> rte_device object (using the priv size), fills the driver field then
> pass them to rte_driver init function.
>
>
> Impact on ethdev
>
> - a rte_eth_dev object references a rte_device in place of
> rte_pci_device
> - no more information about a driver in rte_eth_dev, this is the
> rte_device that has a reference to its rte_driver
> - eth_driver can be removed, it is only a wrapper of a rte_pci_driver
> at the moment, maybe some init function wrappers can stay in ethdev
> with dev_private_size to be handled in the rte_driver
> - rte_eth_dev objects are created by rte_drivers during probe (pci
> scan, vdev init, hotplug)
> - ethdev ops are populated by rte_drivers
>
>
> Impact on hotplug
>
> - hotplug moves from ethdev to eal
> - a notification framework is added to ethdev when hotplugging
>
> - eal uses the name (remember the pci:0000:00:01.0 / vdev:name
> example) in devargs to identify the right bus (pci / vdev)
> - pci scan code is reused to create a rte_pci_device object etc...
> - vdev init code is reused
>
>
> We end up with something like this.
> An arrow means that the structure contains a pointer to an object of the
> other struct.
> I only wrote the fields I mentioned in this mail, for pci device a lot
> of other fields are omitted.
>
> - for ethdev on top of pci devices
>
> +------------------+ +-------------------------------+
> | | | |
> | rte_pci_device | | rte_pci_driver |
> | | | |
> +-------------+ | +--------------+ | | +---------------------------+ |
> | | | | | | | | | |
> | rte_eth_dev +---> rte_device +-----> rte_driver | |
> | | | | char name[] | | | | char name[] | |
> +-------------+ | | | | | | int init(rte_device *) | |
> | +--------------+ | | | int uninit(rte_device *) | |
> | | | | | |
> +------------------+ | +---------------------------+ |
> | |
> +-------------------------------+
>
> - for ethdev on top of vdev devices
>
> +------------------+ +-------------------------------+
> | | | |
> | drv specific | | rte_vdev_driver |
> | | | |
> +-------------+ | +--------------+ | | +---------------------------+ |
> | | | | | | | | | |
> | rte_eth_dev +---> rte_device +-----> rte_driver | |
> | | | | char name[] | | | | char name[] | |
> +-------------+ | | | | | | int init(rte_device *) | |
> | +--------------+ | | | int uninit(rte_device *) | |
> | | | | | |
> +------------------+ | +---------------------------+ |
> | |
> | int priv_size |
> | |
> +-------------------------------+
>
>
> Thanks for reading.
> Comments ?
>
>
Hey David,
form the work we done on the cryptodev I definitely agree this is
something we need to look at. There is some duplication of code between
ethdev and cryptodev which would disappear with a common rte_device
abstraction. I just haven't had time to write anything down and didn't
want to further complicate the cryptodev patches by introducing EAL
changes with it as well.
In your proposal above, having an bus type enumeration in the rte_device
which specifies the bus type might be simpler than having to parse a
specific name formatting.
Moving the hot-plugging infrastructure to the EAL would be great as this
is an element we didn't address in the cryptodev layer as currently we
would need to re-implement a lot of the same logic which is done in
lib_ethdev. Again this was something on our list of things to look at.
One thing that we are working on at the moment and it will affect your
proposed solution above quite a lot is the ability to support devices
with share-able buses in DPDK, we will have a RFC for this proposal in
the next few days but I'll give a quick overview now. The Quick Assist
device which we currently support a symmetric crypto cryptodev PMD for
in DPDK is a mufti-function device, in that it supports symmetric and
asymmetric crypto and compression functionality. These features are
supported from a single device instance through different hardware
queues. We want to provide each service through as a separate dpdk
device but with and underlying shared bus (in our case PCI), this way a
device/queue will only provide 1 service type. What we are going to
propose is to allow a rte_pci_device to be shared my multiple pdevs, to
do this we would register multiple drivers against the same pci_id and
with a small modification to the EAL rte_eal_pci_probe_all()/
rte_eal_pci_probe() functions we create a device instance for each
matched driver as long as the diver has a share-able flag.
So with the current DPDK architecture where the rte_cryptodev (also the
same for the rte_eth_dev) has a pointer from the rte_pci_driver to the
rte_pci_device and a back pointer from the rte_pci_device to the
rte_pci_driver, we are proposing to remove the back pointer from
rte_pci_device and then allow multiple rte_pci_driver. This will require
an API change to the PCI device uninit function. We'll outline all of
this in the RFC, but I just wanted to make you aware of it, as something
to keep in mind. Our solution will logically look something a bit like
below.
+-----------------------+ +------------------------+
| qat_sym_pmd | | qat_asym_pmd |
+-----------------------+ +------------------------+
| |
V V
+-----------------------+ +------------------------+
| rte_cryptodev | | rte_cryptodev |
+-----------------------+ +------------------------+
| |
V V
+----------------+ +----------------+
| rte_pci_driver | | rte_pci_driver |
+----------------+ +----------------+
^ | | ^
| ------------------------ |
/ | /
/ V /
| +----------------+ |
---------| rte_pci_device |---------
+----------------+
I guess the main change from your proposal to allow similar
functionality would be that dependency chain is reversed with the
rte_driver having the reference to the rte_device which could be shared
by multiple drivers.
+----------------------------+ +----------------+
| | | |
| drv specific | | bus specific |
| | | |
+-------------+ |+--------------------------+| |+--------------+|
| | || || || ||
| rte_eth_dev +--> rte_driver +--+--> rte_device ||
| | || char name[] || | || char name[] ||
+-------------+ || int init(rte_device *) || | || bool shared ||
|| int uninit(rte_device *)|| | || mutex lock ||
|| || | || ||
|+--------------------------+| | |+--------------+|
| | | +----------------+
+----------------------------+ |
|
|
+----------------------------+ |
| | |
| drv specific | |
| | |
+-------------+ |+--------------------------+| |
| | || || |
| rte_eth_dev +--> rte_driver +--+
| | || char name[] ||
+-------------+ || int init(rte_device *) ||
|| int uninit(rte_device *) ||
|| ||
|+--------------------------+|
| |
+----------------------------+
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] Proposal for a big eal / ethdev cleanup
2016-01-16 15:53 0% ` David Marchand
@ 2016-01-18 15:49 3% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2016-01-18 15:49 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Jan Viktorin
2016-01-16 16:53, David Marchand:
> On Thu, Jan 14, 2016 at 12:46 PM, Jan Viktorin <viktorin@rehivetech.com> wrote:
> > On Thu, 14 Jan 2016 11:38:16 +0100
> > David Marchand <david.marchand@6wind.com> wrote:
> >> Here is a proposal of a big cleanup in ethdev (cryptodev would have to
> >> follow) and eal structures.
[...]
> >> ABI is most likely broken with this, but I think this discussion can come later.
> >
> > I was trying in my initial approach to stay as much API and ABI backwards
> > compatible as possible to be acceptable into upstream. As just a few
> > people have shown their interest in these changes, I consider the ABI
> > compatibility very important.
> >
> > I can see, that your approach does not care too much... Otherwise, it looks
> > good to me. It is closer to the Linux drivers infra, so it seems to be clearer
> > then the current one.
>
> I did this on purpose.
> From my point of view, we will have an API/ABI breakage in this code
> at one point.
> So I sent this mail to show where I'd like us to go, because this
> looks saner on the mid/long term.
[...]
> > Another point is that the ethdev infra should not know about the
> > underlying bus infra. The question is whether we do a big clean
> > up (extract PCI-bus code out) or a small clean up (give the ethdev
> > infra a hint which bus system it deals with).
>
> Yes, and I think these two choices are reflected by our two respective
> proposals :-)
Regarding the API/ABI breaks and how the big the changes must be, I'd say
it is nice to have some changes without breaking the user interfaces.
Though sometimes there is a great value to refactor things and break them.
In such case, it is better to do the big changes at once so the breaking
would impact only one version instead of breaking the same API again and
again.
About this proposal, I vote for: +1
[...]
> > Moreover, there is no way how to pass arguments to pdevs, only to
> > vdevs. This was shortly disscussed in [2] for the szedata2 PMD.
> >
> > [2] http://dpdk.org/ml/archives/dev/2015-October/026285.html
>
> Shorty discussed with Thomas, yes.
> But after some experiments, it appears that you can pass devargs after
> a whitelist option at init (--pci-whitelist
> xxxx:xx:xx.x,whataniceoptionwehavehere=1).
> This does not work for hotplug.
> This is undocumented and this looks like a workaround, so I would
> prefer we come up with a better api for 2.3.
Yes we need also to redefine the command line syntax to have a generic way
of passing per-device parameters to the drivers.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] Proposal for a big eal / ethdev cleanup
@ 2016-01-19 10:59 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2016-01-19 10:59 UTC (permalink / raw)
To: Jan Viktorin; +Cc: dev
Jan,
On Tue, Jan 19, 2016 at 11:29 AM, Jan Viktorin <viktorin@rehivetech.com> wrote:
> On Mon, 18 Jan 2016 22:11:56 +0100
> David Marchand <david.marchand@6wind.com> wrote:
>> Ok, so what you propose is something like this ?
>
> I've expressed my basic understanding of this topic in the RFC patch set
> yesterday (as you know).
>
>>
>> - keep rte_driver as it is (init and uninit), I would say the name can
>> be changed later.
>
> Agreed.
>
>> - add rte_bus_driver (idem, not sure it is a good name) in place of
>> the rte_driver I mentioned in my initial mail.
>
> I don't like the name either. I have no other idea at the moment.
My initial intention was to go as far as possible with the approach I
described without caring about the api / abi.
Then if the result is worth, see how we could maintain the api / abi
and how to manage the changes if not possible.
So please, do not hesitate to break stuff.
>> Rather than have init / uninit, how about attach / detach methods ?
>
> You mean attach a driver to a device? Yes, much better. And what about
> probe? I was quite confused when writing a PMD as I couldn't understand
> clearly where should I start touching the hardware.
Yes, I also thought of probe name, but then for unplugging ?
We could use the same names as linux kernel probe/remove ?
I think freebsd kernel uses the same, so why not.
Regards,
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] ethdev: expose link status and speed using xstats
@ 2016-01-20 18:36 3% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2016-01-20 18:36 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Wed, 20 Jan 2016 16:13:34 +0100
Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> > We already have the rte_eth_link_get function. Why not let users
> > continue to use that? It's well defined, it is simple, and it is
> > consistent.
+1
API's should not duplicate results (DRY)
That said, it would be useful to have some way to get statistics
on the number of link transitions and time since last change.
But this ideally should be in rte_eth_link_get() but that wouldn't
be ABI compatiable.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] cfgfile: support looking up sections by index
@ 2016-01-21 7:42 3% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2016-01-21 7:42 UTC (permalink / raw)
To: Rich Lane, dev
On 01/19/2016 06:41 AM, Rich Lane wrote:
> This is useful when sections have duplicate names.
>
> Signed-off-by: Rich Lane <rlane@bigswitch.com>
> ---
> v1->v2:
> - Added new symbol to version script.
>
> lib/librte_cfgfile/rte_cfgfile.c | 16 ++++++++++++++++
> lib/librte_cfgfile/rte_cfgfile.h | 23 +++++++++++++++++++++++
> lib/librte_cfgfile/rte_cfgfile_version.map | 6 ++++++
> 3 files changed, 45 insertions(+)
>
> diff --git a/lib/librte_cfgfile/rte_cfgfile.c b/lib/librte_cfgfile/rte_cfgfile.c
> index a677dad..0bb40a4 100644
> --- a/lib/librte_cfgfile/rte_cfgfile.c
> +++ b/lib/librte_cfgfile/rte_cfgfile.c
> @@ -333,6 +333,22 @@ rte_cfgfile_section_entries(struct rte_cfgfile *cfg, const char *sectionname,
> return i;
> }
>
> +int
> +rte_cfgfile_section_entries_by_index(struct rte_cfgfile *cfg, int index,
> + struct rte_cfgfile_entry *entries, int max_entries)
> +{
> + int i;
> + const struct rte_cfgfile_section *sect;
> +
> + if (index >= cfg->num_sections)
> + return -1;
> +
> + sect = cfg->sections[index];
Since index is a signed int, I think you should check for < 0 as well in
the above. Sorry for not noticing/mentioning that on the first round, I
wasn't so much reviewing the code as just skimming through for general
API/ABI issues.
Other than that, looks ok to me.
- Panu -
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 1/2] ethdev: add vlan type for setting ether type
@ 2016-01-22 1:37 7% ` Helin Zhang
0 siblings, 0 replies; 200+ results
From: Helin Zhang @ 2016-01-22 1:37 UTC (permalink / raw)
To: dev
In order to set ether type of VLAN for single VLAN, inner
and outer VLAN, the VLAN type as an input parameter is added
to 'rte_eth_dev_set_vlan_ether_type()'.
In addition, corresponding changes in e1000, ixgbe and i40e are
also added.
Signed-off-by: Helin Zhang <helin.zhang@intel.com>
---
app/test-pmd/cmdline.c | 29 ++++++++++++++++++++---------
app/test-pmd/config.c | 8 ++++----
app/test-pmd/testpmd.h | 3 ++-
doc/guides/rel_notes/deprecation.rst | 4 ++++
doc/guides/rel_notes/release_2_3.rst | 6 ++++++
drivers/net/e1000/igb_ethdev.c | 20 +++++++++++++++-----
drivers/net/i40e/i40e_ethdev.c | 4 +++-
drivers/net/ixgbe/ixgbe_ethdev.c | 18 ++++++++++++++----
lib/librte_ether/rte_ethdev.c | 5 +++--
lib/librte_ether/rte_ethdev.h | 19 +++++++++++++++++--
10 files changed, 88 insertions(+), 28 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..ba1650b 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -275,8 +275,8 @@ static void cmd_help_long_parsed(void *parsed_result,
" Set the VLAN QinQ (extended queue in queue)"
" on a port.\n\n"
- "vlan set tpid (value) (port_id)\n"
- " Set the outer VLAN TPID for Packet Filtering on"
+ "vlan set (inner|outer) tpid (value) (port_id)\n"
+ " Set the VLAN TPID for Packet Filtering on"
" a port\n\n"
"rx_vlan add (vlan_id|all) (port_id)\n"
@@ -295,10 +295,6 @@ static void cmd_help_long_parsed(void *parsed_result,
" Remove a vlan_id, to the set of VLAN identifiers"
"filtered for VF(s) from port_id.\n\n"
- "rx_vlan set tpid (value) (port_id)\n"
- " Set the outer VLAN TPID for Packet Filtering on"
- " a port\n\n"
-
"tunnel_filter add (port_id) (outer_mac) (inner_mac) (ip_addr) "
"(inner_vlan) (vxlan|nvgre) (filter_type) (tenant_id) (queue_id)\n"
" add a tunnel filter of a port.\n\n"
@@ -2845,6 +2841,7 @@ cmdline_parse_inst_t cmd_vlan_offload = {
struct cmd_vlan_tpid_result {
cmdline_fixed_string_t vlan;
cmdline_fixed_string_t set;
+ cmdline_fixed_string_t vlan_type;
cmdline_fixed_string_t what;
uint16_t tp_id;
uint8_t port_id;
@@ -2856,8 +2853,17 @@ cmd_vlan_tpid_parsed(void *parsed_result,
__attribute__((unused)) void *data)
{
struct cmd_vlan_tpid_result *res = parsed_result;
- vlan_tpid_set(res->port_id, res->tp_id);
- return;
+ enum rte_vlan_type vlan_type;
+
+ if (!strcmp(res->vlan_type, "inner"))
+ vlan_type = ETH_VLAN_TYPE_INNER;
+ else if (!strcmp(res->vlan_type, "outer"))
+ vlan_type = ETH_VLAN_TYPE_OUTER;
+ else {
+ printf("Unknown vlan type\n");
+ return;
+ }
+ vlan_tpid_set(res->port_id, vlan_type, res->tp_id);
}
cmdline_parse_token_string_t cmd_vlan_tpid_vlan =
@@ -2866,6 +2872,9 @@ cmdline_parse_token_string_t cmd_vlan_tpid_vlan =
cmdline_parse_token_string_t cmd_vlan_tpid_set =
TOKEN_STRING_INITIALIZER(struct cmd_vlan_tpid_result,
set, "set");
+cmdline_parse_token_string_t cmd_vlan_type =
+ TOKEN_STRING_INITIALIZER(struct cmd_vlan_tpid_result,
+ vlan_type, "inner#outer");
cmdline_parse_token_string_t cmd_vlan_tpid_what =
TOKEN_STRING_INITIALIZER(struct cmd_vlan_tpid_result,
what, "tpid");
@@ -2879,10 +2888,12 @@ cmdline_parse_token_num_t cmd_vlan_tpid_portid =
cmdline_parse_inst_t cmd_vlan_tpid = {
.f = cmd_vlan_tpid_parsed,
.data = NULL,
- .help_str = "set tpid tp_id port_id, set the Outer VLAN Ether type",
+ .help_str = "set inner|outer tpid tp_id port_id, set the VLAN "
+ "Ether type",
.tokens = {
(void *)&cmd_vlan_tpid_vlan,
(void *)&cmd_vlan_tpid_set,
+ (void *)&cmd_vlan_type,
(void *)&cmd_vlan_tpid_what,
(void *)&cmd_vlan_tpid_tpid,
(void *)&cmd_vlan_tpid_portid,
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 7088f6f..537dd0b 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1821,19 +1821,19 @@ rx_vlan_all_filter_set(portid_t port_id, int on)
}
void
-vlan_tpid_set(portid_t port_id, uint16_t tp_id)
+vlan_tpid_set(portid_t port_id, enum rte_vlan_type vlan_type, uint16_t tp_id)
{
int diag;
if (port_id_is_invalid(port_id, ENABLED_WARN))
return;
- diag = rte_eth_dev_set_vlan_ether_type(port_id, tp_id);
+ diag = rte_eth_dev_set_vlan_ether_type(port_id, vlan_type, tp_id);
if (diag == 0)
return;
- printf("tx_vlan_tpid_set(port_pi=%d, tpid=%d) failed "
+ printf("tx_vlan_tpid_set(port_pi=%d, vlan_type=%d, tpid=%d) failed "
"diag=%d\n",
- port_id, tp_id, diag);
+ port_id, vlan_type, tp_id, diag);
}
void
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index ee7de98..d79d86d 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -507,7 +507,8 @@ void rx_vlan_filter_set(portid_t port_id, int on);
void rx_vlan_all_filter_set(portid_t port_id, int on);
int rx_vft_set(portid_t port_id, uint16_t vlan_id, int on);
void vlan_extend_set(portid_t port_id, int on);
-void vlan_tpid_set(portid_t port_id, uint16_t tp_id);
+void vlan_tpid_set(portid_t port_id, enum rte_vlan_type vlan_type,
+ uint16_t tp_id);
void tx_vlan_set(portid_t port_id, uint16_t vlan_id);
void tx_qinq_set(portid_t port_id, uint16_t vlan_id, uint16_t vlan_id_outer);
void tx_vlan_reset(portid_t port_id);
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..989db37 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -49,3 +49,7 @@ Deprecation Notices
commands (such as RETA update in testpmd). This should impact
CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
It should be integrated in release 2.3.
+
+* ABI changes are planned for ``vlan_tpid_set`` in ethdev structure
+ of ``eth_dev_ops`` from in release 16.07. Its return value will be changed
+ from ``void`` to ``int``.
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..1f32401 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -4,6 +4,8 @@ DPDK Release 2.3
New Features
------------
+* **Added modifying ether type of both single and double VLAN for i40e**
+
Resolved Issues
---------------
@@ -35,6 +37,10 @@ Known Issues
API Changes
-----------
+* The function of ``rte_eth_dev_set_vlan_ether_type()`` now has one more
+ parameter of ``enum rte_vlan_type`` for configuring single VLAN, inner
+ or outer VLAN.
+
ABI Changes
-----------
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index d1bbcda..b3cec86 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -125,7 +125,9 @@ static int eth_igb_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
static int eth_igb_vlan_filter_set(struct rte_eth_dev *dev,
uint16_t vlan_id, int on);
-static void eth_igb_vlan_tpid_set(struct rte_eth_dev *dev, uint16_t tpid_id);
+static void eth_igb_vlan_tpid_set(struct rte_eth_dev *dev,
+ enum rte_vlan_type vlan_type,
+ uint16_t tpid_id);
static void eth_igb_vlan_offload_set(struct rte_eth_dev *dev, int mask);
static void igb_vlan_hw_filter_enable(struct rte_eth_dev *dev);
@@ -2185,14 +2187,22 @@ eth_igb_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
}
static void
-eth_igb_vlan_tpid_set(struct rte_eth_dev *dev, uint16_t tpid)
+eth_igb_vlan_tpid_set(struct rte_eth_dev *dev, enum rte_vlan_type vlan_type,
+ uint16_t tpid)
{
struct e1000_hw *hw =
E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- uint32_t reg = ETHER_TYPE_VLAN ;
+ uint32_t reg = ETHER_TYPE_VLAN;
- reg |= (tpid << 16);
- E1000_WRITE_REG(hw, E1000_VET, reg);
+ switch (vlan_type) {
+ case ETH_VLAN_TYPE_INNER:
+ reg |= (tpid << 16);
+ E1000_WRITE_REG(hw, E1000_VET, reg);
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "Unsupported vlan type %d\n", vlan_type);
+ break;
+ }
}
static void
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bf6220d..56ed28d 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -299,7 +299,8 @@ static void i40e_dev_info_get(struct rte_eth_dev *dev,
static int i40e_vlan_filter_set(struct rte_eth_dev *dev,
uint16_t vlan_id,
int on);
-static void i40e_vlan_tpid_set(struct rte_eth_dev *dev, uint16_t tpid);
+static void i40e_vlan_tpid_set(struct rte_eth_dev *dev,
+ enum rte_vlan_type vlan_type, uint16_t tpid);
static void i40e_vlan_offload_set(struct rte_eth_dev *dev, int mask);
static void i40e_vlan_strip_queue_set(struct rte_eth_dev *dev,
uint16_t queue,
@@ -2321,6 +2322,7 @@ i40e_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
static void
i40e_vlan_tpid_set(__rte_unused struct rte_eth_dev *dev,
+ __rte_unused enum rte_vlan_type vlan_type,
__rte_unused uint16_t tpid)
{
PMD_INIT_FUNC_TRACE();
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 4c4c6df..20ed5b8 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -172,7 +172,9 @@ static int ixgbe_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
static int ixgbe_vlan_filter_set(struct rte_eth_dev *dev,
uint16_t vlan_id, int on);
-static void ixgbe_vlan_tpid_set(struct rte_eth_dev *dev, uint16_t tpid_id);
+static void ixgbe_vlan_tpid_set(struct rte_eth_dev *dev,
+ enum rte_vlan_type vlan_type,
+ uint16_t tpid_id);
static void ixgbe_vlan_hw_strip_bitmap_set(struct rte_eth_dev *dev,
uint16_t queue, bool on);
static void ixgbe_vlan_strip_queue_set(struct rte_eth_dev *dev, uint16_t queue,
@@ -1517,13 +1519,21 @@ ixgbe_vlan_strip_queue_set(struct rte_eth_dev *dev, uint16_t queue, int on)
}
static void
-ixgbe_vlan_tpid_set(struct rte_eth_dev *dev, uint16_t tpid)
+ixgbe_vlan_tpid_set(struct rte_eth_dev *dev, enum rte_vlan_type vlan_type,
+ uint16_t tpid)
{
struct ixgbe_hw *hw =
IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- /* Only the high 16-bits is valid */
- IXGBE_WRITE_REG(hw, IXGBE_EXVET, tpid << 16);
+ switch (vlan_type) {
+ case ETH_VLAN_TYPE_INNER:
+ /* Only the high 16-bits is valid */
+ IXGBE_WRITE_REG(hw, IXGBE_EXVET, tpid << 16);
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "Unsupported vlan type %d\n", vlan_type);
+ break;
+ }
}
void
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index ed971b4..589b7ca 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1695,14 +1695,15 @@ rte_eth_dev_set_vlan_strip_on_queue(uint8_t port_id, uint16_t rx_queue_id, int o
}
int
-rte_eth_dev_set_vlan_ether_type(uint8_t port_id, uint16_t tpid)
+rte_eth_dev_set_vlan_ether_type(uint8_t port_id, enum rte_vlan_type vlan_type,
+ uint16_t tpid)
{
struct rte_eth_dev *dev;
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = &rte_eth_devices[port_id];
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->vlan_tpid_set, -ENOTSUP);
- (*dev->dev_ops->vlan_tpid_set)(dev, tpid);
+ (*dev->dev_ops->vlan_tpid_set)(dev, vlan_type, tpid);
return 0;
}
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index bada8ad..c047cbe 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -351,6 +351,17 @@ struct rte_eth_rxmode {
};
/**
+ * VLAN types to indicate if it is for single VLAN, inner VLAN or outer VLAN.
+ * Note that most of time single VLAN is treated the same as inner VLAN.
+ */
+enum rte_vlan_type {
+ ETH_VLAN_TYPE_UNKNOWN = 0,
+ ETH_VLAN_TYPE_INNER, /**< Single VLAN, or inner VLAN. */
+ ETH_VLAN_TYPE_OUTER, /**< Outer VLAN. */
+ ETH_VLAN_TYPE_MAX,
+};
+
+/**
* A structure used to configure the Receive Side Scaling (RSS) feature
* of an Ethernet port.
* If not NULL, the *rss_key* pointer of the *rss_conf* structure points
@@ -1077,7 +1088,7 @@ typedef int (*vlan_filter_set_t)(struct rte_eth_dev *dev,
/**< @internal filtering of a VLAN Tag Identifier by an Ethernet device. */
typedef void (*vlan_tpid_set_t)(struct rte_eth_dev *dev,
- uint16_t tpid);
+ enum rte_vlan_type type, uint16_t tpid);
/**< @internal set the outer VLAN-TPID by an Ethernet device. */
typedef void (*vlan_offload_set_t)(struct rte_eth_dev *dev, int mask);
@@ -2349,6 +2360,8 @@ extern int rte_eth_dev_set_vlan_strip_on_queue(uint8_t port_id,
*
* @param port_id
* The port identifier of the Ethernet device.
+ * @vlan_type
+ * The vlan type.
* @param tag_type
* The Tag Protocol ID
* @return
@@ -2356,7 +2369,9 @@ extern int rte_eth_dev_set_vlan_strip_on_queue(uint8_t port_id,
* - (-ENOSUP) if hardware-assisted VLAN TPID setup is not supported.
* - (-ENODEV) if *port_id* invalid.
*/
-extern int rte_eth_dev_set_vlan_ether_type(uint8_t port_id, uint16_t tag_type);
+extern int rte_eth_dev_set_vlan_ether_type(uint8_t port_id,
+ enum rte_vlan_type vlan_type,
+ uint16_t tag_type);
/**
* Set VLAN offload configuration on an Ethernet device
--
2.5.0
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...
@ 2016-01-22 10:05 3% ` Panu Matilainen
2016-01-22 11:05 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-22 10:05 UTC (permalink / raw)
To: Ananyev, Konstantin, Andralojc, WojciechX; +Cc: dev
On 01/21/2016 12:51 PM, Ananyev, Konstantin wrote:
> Hi Panu,
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
>> Sent: Thursday, January 21, 2016 10:39 AM
>> To: Andralojc, WojciechX
>> Cc: dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...
>>
>> On 01/21/2016 10:18 AM, Wojciech Andralojc wrote:
>>> Patch reworked.
>>>
>>> Signed-off-by: Wojciech Andralojc <wojciechx.andralojc@intel.com>
>>> ---
>>> lib/librte_eal/common/include/arch/x86/rte_msr.h | 88 +++++++++++++++++
>>> lib/librte_eal/linuxapp/eal/Makefile | 1 +
>>> lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c | 116 +++++++++++++++++++++++
>>> 3 files changed, 205 insertions(+)
>>> create mode 100644 lib/librte_eal/common/include/arch/x86/rte_msr.h
>>> create mode 100644 lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c
>>
>> This creates a new arch-specific public API, with rte_msr.h installed as
>> a public header and implementation in the library (as opposed to
>> inline), and so the new functions would have to be added to
>> rte_eal_version.map.
>>
>> However that is a bit of a problem since it only exists on IA
>> architectures, so it'd mean dummy entries in the version map for all
>> other architectures. All the other arch-specific APIs are inline code so
>> this is the first of its kind.
>
> My thought was:
> 1. implementation is linux specific (as I know not supposed to work under freebsd).
> 2. they are not supposed to be used at run-time cide-path, so no need to be inlined.
Speed is not the only interesting attribute of inlining, inlined code
also effectively escapes the library ABI so it does not need versioning
/ exporting.
> 3. As I understand we plan to have a library that will use these functions anyway.
Is this library going to be a generic or specific to Intel CPUs?
Also, if there are no other uses for the MSR API at the moment, perhaps
the best place for this code would be within that library anyway?
> About dummy entries in the .map file: if we'll create a 'weak' generic implementation,
> that would just return an error - would it solve the issue?
Sure it'd solve the issue of dummy entries in .map but people seemed
opposed to having a highly arch-specific API exposed to all architectures.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...
2016-01-22 10:05 3% ` Panu Matilainen
@ 2016-01-22 11:05 0% ` Ananyev, Konstantin
2016-01-22 11:37 0% ` Andralojc, WojciechX
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2016-01-22 11:05 UTC (permalink / raw)
To: Panu Matilainen, Andralojc, WojciechX; +Cc: dev
> -----Original Message-----
> From: Panu Matilainen [mailto:pmatilai@redhat.com]
> Sent: Friday, January 22, 2016 10:06 AM
> To: Ananyev, Konstantin; Andralojc, WojciechX
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...
>
> On 01/21/2016 12:51 PM, Ananyev, Konstantin wrote:
> > Hi Panu,
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
> >> Sent: Thursday, January 21, 2016 10:39 AM
> >> To: Andralojc, WojciechX
> >> Cc: dev@dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...
> >>
> >> On 01/21/2016 10:18 AM, Wojciech Andralojc wrote:
> >>> Patch reworked.
> >>>
> >>> Signed-off-by: Wojciech Andralojc <wojciechx.andralojc@intel.com>
> >>> ---
> >>> lib/librte_eal/common/include/arch/x86/rte_msr.h | 88 +++++++++++++++++
> >>> lib/librte_eal/linuxapp/eal/Makefile | 1 +
> >>> lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c | 116 +++++++++++++++++++++++
> >>> 3 files changed, 205 insertions(+)
> >>> create mode 100644 lib/librte_eal/common/include/arch/x86/rte_msr.h
> >>> create mode 100644 lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c
> >>
> >> This creates a new arch-specific public API, with rte_msr.h installed as
> >> a public header and implementation in the library (as opposed to
> >> inline), and so the new functions would have to be added to
> >> rte_eal_version.map.
> >>
> >> However that is a bit of a problem since it only exists on IA
> >> architectures, so it'd mean dummy entries in the version map for all
> >> other architectures. All the other arch-specific APIs are inline code so
> >> this is the first of its kind.
> >
> > My thought was:
> > 1. implementation is linux specific (as I know not supposed to work under freebsd).
> > 2. they are not supposed to be used at run-time cide-path, so no need to be inlined.
>
> Speed is not the only interesting attribute of inlining, inlined code
> also effectively escapes the library ABI so it does not need versioning
> / exporting.
>
> > 3. As I understand we plan to have a library that will use these functions anyway.
>
> Is this library going to be a generic or specific to Intel CPUs?
As I understand - yes.
It supposed to utilise new Intel chips CAT abilities.
Wojciech, please correct me if I missed something here.
> Also, if there are no other uses for the MSR API at the moment, perhaps
> the best place for this code would be within that library anyway?
Sounds good to me.
Konstantin
>
> > About dummy entries in the .map file: if we'll create a 'weak' generic implementation,
> > that would just return an error - would it solve the issue?
>
> Sure it'd solve the issue of dummy entries in .map but people seemed
> opposed to having a highly arch-specific API exposed to all architectures.
>
> - Panu -
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...
2016-01-22 11:05 0% ` Ananyev, Konstantin
@ 2016-01-22 11:37 0% ` Andralojc, WojciechX
0 siblings, 0 replies; 200+ results
From: Andralojc, WojciechX @ 2016-01-22 11:37 UTC (permalink / raw)
To: Ananyev, Konstantin, Panu Matilainen; +Cc: dev
> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Friday, January 22, 2016 11:05 AM
> To: Panu Matilainen; Andralojc, WojciechX
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel
> Architecture Model Specific Registers (MSR)...
>
> > -----Original Message-----
> > From: Panu Matilainen [mailto:pmatilai@redhat.com]
> > Sent: Friday, January 22, 2016 10:06 AM
> > To: Ananyev, Konstantin; Andralojc, WojciechX
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel
> Architecture Model Specific Registers (MSR)...
> >
> > On 01/21/2016 12:51 PM, Ananyev, Konstantin wrote:
> > > Hi Panu,
> > >
> > >> -----Original Message-----
> > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu
> > >> Matilainen
> > >> Sent: Thursday, January 21, 2016 10:39 AM
> > >> To: Andralojc, WojciechX
> > >> Cc: dev@dpdk.org
> > >> Subject: Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write
> Intel Architecture Model Specific Registers (MSR)...
> > >>
> > >> On 01/21/2016 10:18 AM, Wojciech Andralojc wrote:
> > >>> Patch reworked.
> > >>>
> > >>> Signed-off-by: Wojciech Andralojc <wojciechx.andralojc@intel.com>
> > >>> ---
> > >>> lib/librte_eal/common/include/arch/x86/rte_msr.h | 88
> +++++++++++++++++
> > >>> lib/librte_eal/linuxapp/eal/Makefile | 1 +
> > >>> lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c | 116
> +++++++++++++++++++++++
> > >>> 3 files changed, 205 insertions(+)
> > >>> create mode 100644
> lib/librte_eal/common/include/arch/x86/rte_msr.h
> > >>> create mode 100644
> > >>> lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c
> > >>
> > >> This creates a new arch-specific public API, with rte_msr.h
> > >> installed as a public header and implementation in the library (as
> > >> opposed to inline), and so the new functions would have to be added
> > >> to rte_eal_version.map.
> > >>
> > >> However that is a bit of a problem since it only exists on IA
> > >> architectures, so it'd mean dummy entries in the version map for
> > >> all other architectures. All the other arch-specific APIs are
> > >> inline code so this is the first of its kind.
> > >
> > > My thought was:
> > > 1. implementation is linux specific (as I know not supposed to work under
> freebsd).
> > > 2. they are not supposed to be used at run-time cide-path, so no need to be
> inlined.
> >
> > Speed is not the only interesting attribute of inlining, inlined code
> > also effectively escapes the library ABI so it does not need
> > versioning / exporting.
> >
> > > 3. As I understand we plan to have a library that will use these functions
> anyway.
> >
> > Is this library going to be a generic or specific to Intel CPUs?
>
> As I understand - yes.
> It supposed to utilise new Intel chips CAT abilities.
> Wojciech, please correct me if I missed something here.
Konstantin, yes, you are right,
CAT enabling lib is Intel CPUs specific.
>
> > Also, if there are no other uses for the MSR API at the moment,
> > perhaps the best place for this code would be within that library anyway?
>
> Sounds good to me.
OK, sounds good.
Thank you both for your input.
>
> Konstantin
>
> >
> > > About dummy entries in the .map file: if we'll create a 'weak'
> > > generic implementation, that would just return an error - would it solve the
> issue?
> >
> > Sure it'd solve the issue of dummy entries in .map but people seemed
> > opposed to having a highly arch-specific API exposed to all architectures.
> >
> > - Panu -
> >
Wojciech Andralojc
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
@ 2016-01-22 15:22 3% ` Van Haaren, Harry
2016-01-22 15:53 0% ` Jay Rolette
2016-01-22 16:04 0% ` David Harton (dharton)
0 siblings, 2 replies; 200+ results
From: Van Haaren, Harry @ 2016-01-22 15:22 UTC (permalink / raw)
To: Thomas Monjalon, David Harton (dharton); +Cc: dev
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
> + Harry
Hey all,
> xstats are driver agnostic and have a well-defined naming scheme.
Indeed, described here:
http://dpdk.org/doc/guides/prog_guide/poll_mode_drv.html#extended-statistics-api
All of the rte_eth_stats statistics are presented in xstats consistently
(independent of which PMD is running), as they are implemented in rte_ethdev.c:
http://dpdk.org/browse/dpdk/tree/lib/librte_ether/rte_ethdev.c#n1500
From: David Harton:
> For example, what if there was a kind of "stats registry" composed of ID and name. It
> would work similar to xtats except instead of advertising strings only the "get" API would
> return ID/count pairs. If the application wishes to use the DPDK provided string they can
> call another API to get the stat string via the ID. These IDs would be well-defined
> clearly explaining what the count represent. This way the strings for counts will be
> uniform across drivers and also make it clear to the users what the counts truly represent
> and the application could obtain stats from any driver in a driver agnostic manner.
What you (David Harton) describe about a well-defined name, and clearly explaining the value
it is representing is what the goal was for xstats: a human readable string, which can be
easily parsed and a value retrieved.
The "rules" of encoding a statistic as an xstats string are pretty simple, and if any PMD
breaks the rules, it should be considered broken and fixed.
Consistency is key, in this case consistency in the PMD xstats implementations to make it
useful for clients of the API.
The big advantage xstats has over adding items to rte_eth_stats is that it won't break ABI.
Do you see a fundamental problem with parsing the strings to retrieve values?
If you like I could code up a minimal sample-app that only pulls statistics,
and you can show "interest" in various statistics for printing / monitoring?
Regards, -Harry
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
2016-01-22 15:22 3% ` Van Haaren, Harry
@ 2016-01-22 15:53 0% ` Jay Rolette
2016-01-22 16:04 0% ` David Harton (dharton)
1 sibling, 0 replies; 200+ results
From: Jay Rolette @ 2016-01-22 15:53 UTC (permalink / raw)
To: Van Haaren, Harry; +Cc: dev
On Fri, Jan 22, 2016 at 9:22 AM, Van Haaren, Harry <
harry.van.haaren@intel.com> wrote:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
>
> > + Harry
>
> Hey all,
>
> > xstats are driver agnostic and have a well-defined naming scheme.
>
> Indeed, described here:
>
> http://dpdk.org/doc/guides/prog_guide/poll_mode_drv.html#extended-statistics-api
>
> All of the rte_eth_stats statistics are presented in xstats consistently
> (independent of which PMD is running), as they are implemented in
> rte_ethdev.c:
> http://dpdk.org/browse/dpdk/tree/lib/librte_ether/rte_ethdev.c#n1500
>
>
> From: David Harton:
> > For example, what if there was a kind of "stats registry" composed of ID
> and name. It
> > would work similar to xtats except instead of advertising strings only
> the "get" API would
> > return ID/count pairs. If the application wishes to use the DPDK
> provided string they can
> > call another API to get the stat string via the ID. These IDs would be
> well-defined
> > clearly explaining what the count represent. This way the strings for
> counts will be
> > uniform across drivers and also make it clear to the users what the
> counts truly represent
> > and the application could obtain stats from any driver in a driver
> agnostic manner.
>
> What you (David Harton) describe about a well-defined name, and clearly
> explaining the value
> it is representing is what the goal was for xstats: a human readable
> string, which can be
> easily parsed and a value retrieved.
>
> The "rules" of encoding a statistic as an xstats string are pretty simple,
> and if any PMD
> breaks the rules, it should be considered broken and fixed.
>
> Consistency is key, in this case consistency in the PMD xstats
> implementations to make it
> useful for clients of the API.
>
> The big advantage xstats has over adding items to rte_eth_stats is that it
> won't break ABI.
>
> Do you see a fundamental problem with parsing the strings to retrieve
> values?
>
When you have an appliance with a large number of ports and a large number
of stats that you need to collect, having to parse those strings constantly
is very slow compared to having fixed struct members or at least known ID
values.
Strings are also error prone. While they may be consistent at this point,
it is remarkably easy for them to get out of sync along the way. Using an
ID instead avoids that neatly.
Jay
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
2016-01-22 15:22 3% ` Van Haaren, Harry
2016-01-22 15:53 0% ` Jay Rolette
@ 2016-01-22 16:04 0% ` David Harton (dharton)
1 sibling, 1 reply; 200+ results
From: David Harton (dharton) @ 2016-01-22 16:04 UTC (permalink / raw)
To: Van Haaren, Harry, Thomas Monjalon; +Cc: dev
> > xstats are driver agnostic and have a well-defined naming scheme.
>
> Indeed, described here:
> http://dpdk.org/doc/guides/prog_guide/poll_mode_drv.html#extended-
> statistics-api
Thanks for sharing. I do think what is in the link is well thought out but it also may not match how the application would choose to represent that stat (capitalization, abbreviation, etc).
> From: David Harton:
> > For example, what if there was a kind of "stats registry" composed of
> > ID and name. It would work similar to xtats except instead of
> > advertising strings only the "get" API would return ID/count pairs.
> > If the application wishes to use the DPDK provided string they can
> > call another API to get the stat string via the ID. These IDs would
> > be well-defined clearly explaining what the count represent. This way
> > the strings for counts will be uniform across drivers and also make it
> clear to the users what the counts truly represent and the application
> could obtain stats from any driver in a driver agnostic manner.
>
> What you (David Harton) describe about a well-defined name, and clearly
> explaining the value it is representing is what the goal was for xstats: a
> human readable string, which can be easily parsed and a value retrieved.
>
> The "rules" of encoding a statistic as an xstats string are pretty simple,
> and if any PMD breaks the rules, it should be considered broken and fixed.
I understand it may be broken, but that doesn't help finding them and ensuring they aren't broken to begin with. What regression/automation is in place to ensure drivers aren't broken?
>
> Consistency is key, in this case consistency in the PMD xstats
> implementations to make it useful for clients of the API.
>
> The big advantage xstats has over adding items to rte_eth_stats is that it
> won't break ABI.
100% agree. I can see the intent.
>
> Do you see a fundamental problem with parsing the strings to retrieve
> values?
I think parsing strings is expensive CPU wise and again subject to error as devices are added. That's why I was wondering if a binary id could be generated instead. The binary id could also be used to look up the string name if the application wants it. The API would be very similar to the current xstats API except it would pass id/value pairs instead of string/value pairs. This avoids string comparisons to figure out while still allowing flexibility between drivers. It would also 100% guarantee that any strings returned by "const char* rte_eth_xstats_str_get(uint32_t stat_id)" are consistent across devices.
I also think there is less chance for error if drivers assign their stats to ID versus constructing a string. I haven't checked my application, but I wonder if the binary size would actually be smaller if all the stats strings were centrally located versus distributed across binaries (highly dependent on the linker and optimization level).
>
> If you like I could code up a minimal sample-app that only pulls
> statistics, and you can show "interest" in various statistics for printing
> / monitoring?
Appreciate the offer. I actually understand what's is available. And, BTW, I apologize for being late to the game (looks like this was discussed last summer) but I'm just now getting looped in and following the mailer but I'm just wondering if something that is performance friendly for the user/application and flexible for the drivers is possible.
Thanks,
Dave
>
>
> Regards, -Harry
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] PCI: ABI change request for adding new field in rte_pci_id structure
@ 2016-01-25 2:36 9% Ziye Yang
0 siblings, 0 replies; 200+ results
From: Ziye Yang @ 2016-01-25 2:36 UTC (permalink / raw)
To: dev; +Cc: Ziye
From: Ziye <ziye.yang@intel.com>
The purpose of this patch is used to add a new field
"class" in rte_pci_id structure. The new class field includes
class_id, subcalss_id, programming interface of a pci device.
With this field, we can identify pci device by its class info,
which can be more flexible instead of probing the device by
vendor_id OR device_id OR subvendor_id OR subdevice_id.
For example, we can probe all nvme devices by class field, which
can be quite convenient.
Signed-off-by: Ziye Yang <ziye.yang@intel.com>
---
doc/guides/rel_notes/release_2_3.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..8fcb43f 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,10 @@ API Changes
ABI Changes
-----------
+* New field ``class`` is added into ``rte_pci_id`` structure. This new
+ added ``class`` field can be used to probe pci devices by class related
+ info. With this new field, the size of structure ``rte_pci_device`` will
+ be increased.
Shared Library Versions
-----------------------
--
1.9.3
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH 1/2] librte_pipeline: add support for packet redirection at action handlers
@ 2016-01-25 14:11 3% Jasvinder Singh
0 siblings, 0 replies; 200+ results
From: Jasvinder Singh @ 2016-01-25 14:11 UTC (permalink / raw)
To: dev
Currently, there is no mechanism that allows the pipeline ports (in/out) and
table action handlers to override the default forwarding decision (as
previously configured per input port or in the table entry). Therefore, new
pipeline API functions have been added which allows action handlers to
hijack packets and remove them from the pipeline processing, and then either
drop them or send them out of the pipeline on any output port. The port
(in/out) and table action handler prototypes have been changed for making
use of these new API functions. This feature will be helpful to implement
functions such as exception handling (e.g. TTL =0), load balancing etc.
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 5 -
doc/guides/rel_notes/release_2_3.rst | 5 +-
lib/librte_pipeline/Makefile | 4 +-
lib/librte_pipeline/rte_pipeline.c | 461 ++++++++++++++-------------
lib/librte_pipeline/rte_pipeline.h | 98 +++---
lib/librte_pipeline/rte_pipeline_version.map | 8 +
6 files changed, 307 insertions(+), 274 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..1a7d660 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -40,11 +40,6 @@ Deprecation Notices
* The scheduler statistics structure will change to allow keeping track of
RED actions.
-* librte_pipeline: The prototype for the pipeline input port, output port
- and table action handlers will be updated:
- the pipeline parameter will be added, the packets mask parameter will be
- either removed (for input port action handler) or made input-only.
-
* ABI changes are planned in cmdline buffer size to allow the use of long
commands (such as RETA update in testpmd). This should impact
CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..eb27643 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,9 @@ API Changes
ABI Changes
-----------
+* librte_pipeline: The prototype for the pipeline input port, output port
+ and table action handlers are updated:the pipeline parameter is added,
+ the packets mask parameter has been either removed or made input-only.
Shared Library Versions
-----------------------
@@ -63,7 +66,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_mbuf.so.2
librte_mempool.so.1
librte_meter.so.1
- librte_pipeline.so.2
+ + librte_pipeline.so.3
librte_pmd_bond.so.1
librte_pmd_ring.so.2
librte_port.so.2
diff --git a/lib/librte_pipeline/Makefile b/lib/librte_pipeline/Makefile
index 1166d3c..822fd41 100644
--- a/lib/librte_pipeline/Makefile
+++ b/lib/librte_pipeline/Makefile
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
@@ -41,7 +41,7 @@ CFLAGS += $(WERROR_FLAGS)
EXPORT_MAP := rte_pipeline_version.map
-LIBABIVER := 2
+LIBABIVER := 3
#
# all source are stored in SRCS-y
diff --git a/lib/librte_pipeline/rte_pipeline.c b/lib/librte_pipeline/rte_pipeline.c
index d625fd2..87f7634 100644
--- a/lib/librte_pipeline/rte_pipeline.c
+++ b/lib/librte_pipeline/rte_pipeline.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -49,14 +49,30 @@
#define RTE_TABLE_INVALID UINT32_MAX
#ifdef RTE_PIPELINE_STATS_COLLECT
-#define RTE_PIPELINE_STATS_ADD(counter, val) \
- ({ (counter) += (val); })
-#define RTE_PIPELINE_STATS_ADD_M(counter, mask) \
- ({ (counter) += __builtin_popcountll(mask); })
+#define RTE_PIPELINE_STATS_AH_DROP_WRITE(p, mask) \
+ ({ (p)->n_pkts_ah_drop = __builtin_popcountll(mask); })
+
+#define RTE_PIPELINE_STATS_AH_DROP_READ(p, counter) \
+ ({ (counter) += (p)->n_pkts_ah_drop; (p)->n_pkts_ah_drop = 0; })
+
+#define RTE_PIPELINE_STATS_TABLE_DROP0(p) \
+ ({ (p)->pkts_drop_mask = (p)->action_mask0[RTE_PIPELINE_ACTION_DROP]; })
+
+#define RTE_PIPELINE_STATS_TABLE_DROP1(p, counter) \
+({ \
+ uint64_t mask = (p)->action_mask0[RTE_PIPELINE_ACTION_DROP]; \
+ mask ^= (p)->pkts_drop_mask; \
+ (counter) += __builtin_popcountll(mask); \
+})
+
#else
-#define RTE_PIPELINE_STATS_ADD(counter, val)
-#define RTE_PIPELINE_STATS_ADD_M(counter, mask)
+
+#define RTE_PIPELINE_STATS_AH_DROP_WRITE(p, mask)
+#define RTE_PIPELINE_STATS_AH_DROP_READ(p, counter)
+#define RTE_PIPELINE_STATS_TABLE_DROP0(p)
+#define RTE_PIPELINE_STATS_TABLE_DROP1(p, counter)
+
#endif
struct rte_port_in {
@@ -75,6 +91,7 @@ struct rte_port_in {
/* List of enabled ports */
struct rte_port_in *next;
+ /* Statistics */
uint64_t n_pkts_dropped_by_ah;
};
@@ -82,12 +99,12 @@ struct rte_port_out {
/* Input parameters */
struct rte_port_out_ops ops;
rte_pipeline_port_out_action_handler f_action;
- rte_pipeline_port_out_action_handler_bulk f_action_bulk;
void *arg_ah;
/* Handle to low-level port */
void *h_port;
+ /* Statistics */
uint64_t n_pkts_dropped_by_ah;
};
@@ -106,7 +123,7 @@ struct rte_table {
/* Handle to the low-level table object */
void *h_table;
- /* Stats for this table. */
+ /* Statistics */
uint64_t n_pkts_dropped_by_lkp_hit_ah;
uint64_t n_pkts_dropped_by_lkp_miss_ah;
uint64_t n_pkts_dropped_lkp_hit;
@@ -133,13 +150,16 @@ struct rte_pipeline {
/* List of enabled ports */
uint64_t enabled_port_in_mask;
- struct rte_port_in *port_in_first;
+ struct rte_port_in *port_in_next;
/* Pipeline run structures */
struct rte_mbuf *pkts[RTE_PORT_IN_BURST_SIZE_MAX];
struct rte_pipeline_table_entry *entries[RTE_PORT_IN_BURST_SIZE_MAX];
uint64_t action_mask0[RTE_PIPELINE_ACTIONS];
uint64_t action_mask1[RTE_PIPELINE_ACTIONS];
+ uint64_t pkts_mask;
+ uint64_t n_pkts_ah_drop;
+ uint64_t pkts_drop_mask;
} __rte_cache_aligned;
static inline uint32_t
@@ -234,7 +254,9 @@ rte_pipeline_create(struct rte_pipeline_params *params)
p->num_ports_out = 0;
p->num_tables = 0;
p->enabled_port_in_mask = 0;
- p->port_in_first = NULL;
+ p->port_in_next = NULL;
+ p->pkts_mask = 0;
+ p->n_pkts_ah_drop = 0;
return p;
}
@@ -759,9 +781,6 @@ rte_pipeline_port_out_check_params(struct rte_pipeline *p,
struct rte_pipeline_port_out_params *params,
uint32_t *port_id)
{
- rte_pipeline_port_out_action_handler f_ah;
- rte_pipeline_port_out_action_handler_bulk f_ah_bulk;
-
if (p == NULL) {
RTE_LOG(ERR, PIPELINE, "%s: pipeline parameter NULL\n",
__func__);
@@ -794,7 +813,7 @@ rte_pipeline_port_out_check_params(struct rte_pipeline *p,
if (params->ops->f_tx == NULL) {
RTE_LOG(ERR, PIPELINE,
- "%s: f_tx function pointer NULL\n", __func__);
+ "%s: f_tx function pointer NULL\n", __func__);
return -EINVAL;
}
@@ -804,15 +823,6 @@ rte_pipeline_port_out_check_params(struct rte_pipeline *p,
return -EINVAL;
}
- f_ah = params->f_action;
- f_ah_bulk = params->f_action_bulk;
- if (((f_ah != NULL) && (f_ah_bulk == NULL)) ||
- ((f_ah == NULL) && (f_ah_bulk != NULL))) {
- RTE_LOG(ERR, PIPELINE, "%s: Action handlers have to be either"
- "both enabled or both disabled\n", __func__);
- return -EINVAL;
- }
-
/* Do we have room for one more port? */
if (p->num_ports_out == RTE_PIPELINE_PORT_OUT_MAX) {
RTE_LOG(ERR, PIPELINE,
@@ -905,7 +915,6 @@ rte_pipeline_port_out_create(struct rte_pipeline *p,
/* Save input parameters */
memcpy(&port->ops, params->ops, sizeof(struct rte_port_out_ops));
port->f_action = params->f_action;
- port->f_action_bulk = params->f_action_bulk;
port->arg_ah = params->arg_ah;
/* Initialize port internal data structure */
@@ -959,9 +968,8 @@ int
rte_pipeline_port_in_enable(struct rte_pipeline *p, uint32_t port_id)
{
struct rte_port_in *port, *port_prev, *port_next;
- struct rte_port_in *port_first, *port_last;
uint64_t port_mask;
- uint32_t port_prev_id, port_next_id, port_first_id, port_last_id;
+ uint32_t port_prev_id, port_next_id;
/* Check input arguments */
if (p == NULL) {
@@ -977,6 +985,8 @@ rte_pipeline_port_in_enable(struct rte_pipeline *p, uint32_t port_id)
return -EINVAL;
}
+ port = &p->ports_in[port_id];
+
/* Return if current input port is already enabled */
port_mask = 1LLU << port_id;
if (p->enabled_port_in_mask & port_mask)
@@ -990,20 +1000,13 @@ rte_pipeline_port_in_enable(struct rte_pipeline *p, uint32_t port_id)
port_prev = &p->ports_in[port_prev_id];
port_next = &p->ports_in[port_next_id];
- port = &p->ports_in[port_id];
port_prev->next = port;
port->next = port_next;
- /* Update the first and last input ports in the chain */
- port_first_id = __builtin_ctzll(p->enabled_port_in_mask);
- port_last_id = 63 - __builtin_clzll(p->enabled_port_in_mask);
-
- port_first = &p->ports_in[port_first_id];
- port_last = &p->ports_in[port_last_id];
-
- p->port_in_first = port_first;
- port_last->next = NULL;
+ /* Check if list of enabled ports was previously empty */
+ if (p->enabled_port_in_mask == port_mask)
+ p->port_in_next = port;
return 0;
}
@@ -1011,9 +1014,9 @@ rte_pipeline_port_in_enable(struct rte_pipeline *p, uint32_t port_id)
int
rte_pipeline_port_in_disable(struct rte_pipeline *p, uint32_t port_id)
{
- struct rte_port_in *port_prev, *port_next, *port_first, *port_last;
+ struct rte_port_in *port, *port_prev, *port_next;
uint64_t port_mask;
- uint32_t port_prev_id, port_next_id, port_first_id, port_last_id;
+ uint32_t port_prev_id, port_next_id;
/* Check input arguments */
if (p == NULL) {
@@ -1028,15 +1031,18 @@ rte_pipeline_port_in_disable(struct rte_pipeline *p, uint32_t port_id)
return -EINVAL;
}
+ port = &p->ports_in[port_id];
+
/* Return if current input port is already disabled */
port_mask = 1LLU << port_id;
if ((p->enabled_port_in_mask & port_mask) == 0)
return 0;
+ p->enabled_port_in_mask &= ~port_mask;
+
/* Return if no other enabled ports */
- if (__builtin_popcountll(p->enabled_port_in_mask) == 1) {
- p->enabled_port_in_mask &= ~port_mask;
- p->port_in_first = NULL;
+ if (p->enabled_port_in_mask == 0) {
+ p->port_in_next = NULL;
return 0;
}
@@ -1049,17 +1055,10 @@ rte_pipeline_port_in_disable(struct rte_pipeline *p, uint32_t port_id)
port_next = &p->ports_in[port_next_id];
port_prev->next = port_next;
- p->enabled_port_in_mask &= ~port_mask;
-
- /* Update the first and last input ports in the chain */
- port_first_id = __builtin_ctzll(p->enabled_port_in_mask);
- port_last_id = 63 - __builtin_clzll(p->enabled_port_in_mask);
-
- port_first = &p->ports_in[port_first_id];
- port_last = &p->ports_in[port_last_id];
- p->port_in_first = port_first;
- port_last->next = NULL;
+ /* Check if the port which has just been disabled is next to serve */
+ if (port == p->port_in_next)
+ p->port_in_next = port_next;
return 0;
}
@@ -1149,28 +1148,32 @@ rte_pipeline_compute_masks(struct rte_pipeline *p, uint64_t pkts_mask)
static inline void
rte_pipeline_action_handler_port_bulk(struct rte_pipeline *p,
- uint64_t pkts_mask, uint32_t port_id)
+ uint64_t pkts_mask, uint32_t port_id)
{
struct rte_port_out *port_out = &p->ports_out[port_id];
+ p->pkts_mask = pkts_mask;
+
/* Output port user actions */
- if (port_out->f_action_bulk != NULL) {
- uint64_t mask = pkts_mask;
+ if (port_out->f_action != NULL) {
+ port_out->f_action(p, p->pkts, pkts_mask, port_out->arg_ah);
- port_out->f_action_bulk(p->pkts, &pkts_mask, port_out->arg_ah);
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |= pkts_mask ^ mask;
- RTE_PIPELINE_STATS_ADD_M(port_out->n_pkts_dropped_by_ah,
- pkts_mask ^ mask);
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ port_out->n_pkts_dropped_by_ah);
}
/* Output port TX */
- if (pkts_mask != 0)
- port_out->ops.f_tx_bulk(port_out->h_port, p->pkts, pkts_mask);
+ if (p->pkts_mask != 0)
+ port_out->ops.f_tx_bulk(port_out->h_port,
+ p->pkts,
+ p->pkts_mask);
}
static inline void
rte_pipeline_action_handler_port(struct rte_pipeline *p, uint64_t pkts_mask)
{
+ p->pkts_mask = pkts_mask;
+
if ((pkts_mask & (pkts_mask + 1)) == 0) {
uint64_t n_pkts = __builtin_popcountll(pkts_mask);
uint32_t i;
@@ -1185,18 +1188,18 @@ rte_pipeline_action_handler_port(struct rte_pipeline *p, uint64_t pkts_mask)
if (port_out->f_action == NULL) /* Output port TX */
port_out->ops.f_tx(port_out->h_port, pkt);
else {
- uint64_t pkt_mask = 1LLU;
+ uint64_t pkt_mask = 1LLU << i;
- port_out->f_action(pkt, &pkt_mask,
+ port_out->f_action(p,
+ p->pkts,
+ pkt_mask,
port_out->arg_ah);
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |=
- (pkt_mask ^ 1LLU) << i;
- RTE_PIPELINE_STATS_ADD(port_out->n_pkts_dropped_by_ah,
- pkt_mask ^ 1LLU);
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ port_out->n_pkts_dropped_by_ah);
/* Output port TX */
- if (pkt_mask != 0)
+ if (pkt_mask & p->pkts_mask)
port_out->ops.f_tx(port_out->h_port,
pkt);
}
@@ -1221,18 +1224,16 @@ rte_pipeline_action_handler_port(struct rte_pipeline *p, uint64_t pkts_mask)
if (port_out->f_action == NULL) /* Output port TX */
port_out->ops.f_tx(port_out->h_port, pkt);
else {
- pkt_mask = 1LLU;
-
- port_out->f_action(pkt, &pkt_mask,
+ port_out->f_action(p,
+ p->pkts,
+ pkt_mask,
port_out->arg_ah);
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |=
- (pkt_mask ^ 1LLU) << i;
- RTE_PIPELINE_STATS_ADD(port_out->n_pkts_dropped_by_ah,
- pkt_mask ^ 1LLU);
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ port_out->n_pkts_dropped_by_ah);
/* Output port TX */
- if (pkt_mask != 0)
+ if (pkt_mask & p->pkts_mask)
port_out->ops.f_tx(port_out->h_port,
pkt);
}
@@ -1244,6 +1245,8 @@ static inline void
rte_pipeline_action_handler_port_meta(struct rte_pipeline *p,
uint64_t pkts_mask)
{
+ p->pkts_mask = pkts_mask;
+
if ((pkts_mask & (pkts_mask + 1)) == 0) {
uint64_t n_pkts = __builtin_popcountll(pkts_mask);
uint32_t i;
@@ -1260,18 +1263,18 @@ rte_pipeline_action_handler_port_meta(struct rte_pipeline *p,
if (port_out->f_action == NULL) /* Output port TX */
port_out->ops.f_tx(port_out->h_port, pkt);
else {
- uint64_t pkt_mask = 1LLU;
+ uint64_t pkt_mask = 1LLU << i;
- port_out->f_action(pkt, &pkt_mask,
+ port_out->f_action(p,
+ p->pkts,
+ pkt_mask,
port_out->arg_ah);
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |=
- (pkt_mask ^ 1LLU) << i;
- RTE_PIPELINE_STATS_ADD(port_out->n_pkts_dropped_by_ah,
- pkt_mask ^ 1ULL);
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ port_out->n_pkts_dropped_by_ah);
/* Output port TX */
- if (pkt_mask != 0)
+ if (pkt_mask & p->pkts_mask)
port_out->ops.f_tx(port_out->h_port,
pkt);
}
@@ -1297,18 +1300,16 @@ rte_pipeline_action_handler_port_meta(struct rte_pipeline *p,
if (port_out->f_action == NULL) /* Output port TX */
port_out->ops.f_tx(port_out->h_port, pkt);
else {
- pkt_mask = 1LLU;
-
- port_out->f_action(pkt, &pkt_mask,
+ port_out->f_action(p,
+ p->pkts,
+ pkt_mask,
port_out->arg_ah);
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |=
- (pkt_mask ^ 1LLU) << i;
- RTE_PIPELINE_STATS_ADD(port_out->n_pkts_dropped_by_ah,
- pkt_mask ^ 1ULL);
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ port_out->n_pkts_dropped_by_ah);
/* Output port TX */
- if (pkt_mask != 0)
+ if (pkt_mask & p->pkts_mask)
port_out->ops.f_tx(port_out->h_port,
pkt);
}
@@ -1342,136 +1343,140 @@ rte_pipeline_action_handler_drop(struct rte_pipeline *p, uint64_t pkts_mask)
int
rte_pipeline_run(struct rte_pipeline *p)
{
- struct rte_port_in *port_in;
-
- for (port_in = p->port_in_first; port_in != NULL;
- port_in = port_in->next) {
- uint64_t pkts_mask;
- uint32_t n_pkts, table_id;
-
- /* Input port RX */
- n_pkts = port_in->ops.f_rx(port_in->h_port, p->pkts,
- port_in->burst_size);
- if (n_pkts == 0)
- continue;
-
- pkts_mask = RTE_LEN2MASK(n_pkts, uint64_t);
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] = 0;
- p->action_mask0[RTE_PIPELINE_ACTION_PORT] = 0;
- p->action_mask0[RTE_PIPELINE_ACTION_PORT_META] = 0;
- p->action_mask0[RTE_PIPELINE_ACTION_TABLE] = 0;
+ struct rte_port_in *port_in = p->port_in_next;
+ uint32_t n_pkts, table_id;
- /* Input port user actions */
- if (port_in->f_action != NULL) {
- uint64_t mask = pkts_mask;
+ if (port_in == NULL)
+ return 0;
- port_in->f_action(p->pkts, n_pkts, &pkts_mask, port_in->arg_ah);
- mask ^= pkts_mask;
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |= mask;
- RTE_PIPELINE_STATS_ADD_M(port_in->n_pkts_dropped_by_ah, mask);
- }
+ /* Input port RX */
+ n_pkts = port_in->ops.f_rx(port_in->h_port, p->pkts,
+ port_in->burst_size);
+ if (n_pkts == 0) {
+ p->port_in_next = port_in->next;
+ return 0;
+ }
- /* Table */
- for (table_id = port_in->table_id; pkts_mask != 0; ) {
- struct rte_table *table;
- uint64_t lookup_hit_mask, lookup_miss_mask;
-
- /* Lookup */
- table = &p->tables[table_id];
- table->ops.f_lookup(table->h_table, p->pkts, pkts_mask,
- &lookup_hit_mask, (void **) p->entries);
- lookup_miss_mask = pkts_mask & (~lookup_hit_mask);
-
- /* Lookup miss */
- if (lookup_miss_mask != 0) {
- struct rte_pipeline_table_entry *default_entry =
- table->default_entry;
-
- /* Table user actions */
- if (table->f_action_miss != NULL) {
- uint64_t mask = lookup_miss_mask;
-
- table->f_action_miss(p->pkts,
- &lookup_miss_mask,
- default_entry, table->arg_ah);
- mask ^= lookup_miss_mask;
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |= mask;
- RTE_PIPELINE_STATS_ADD_M(
- table->n_pkts_dropped_by_lkp_miss_ah, mask);
- }
-
- /* Table reserved actions */
- if ((default_entry->action ==
- RTE_PIPELINE_ACTION_PORT) &&
- (lookup_miss_mask != 0))
- rte_pipeline_action_handler_port_bulk(p,
- lookup_miss_mask,
- default_entry->port_id);
- else {
- uint32_t pos = default_entry->action;
-
- p->action_mask0[pos] = lookup_miss_mask;
- if (pos == RTE_PIPELINE_ACTION_DROP) {
- RTE_PIPELINE_STATS_ADD_M(table->n_pkts_dropped_lkp_miss,
- lookup_miss_mask);
- }
- }
- }
+ p->pkts_mask = RTE_LEN2MASK(n_pkts, uint64_t);
+ p->action_mask0[RTE_PIPELINE_ACTION_DROP] = 0;
+ p->action_mask0[RTE_PIPELINE_ACTION_PORT] = 0;
+ p->action_mask0[RTE_PIPELINE_ACTION_PORT_META] = 0;
+ p->action_mask0[RTE_PIPELINE_ACTION_TABLE] = 0;
+
+ /* Input port user actions */
+ if (port_in->f_action != NULL) {
+ port_in->f_action(p, p->pkts, n_pkts, port_in->arg_ah);
+
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ port_in->n_pkts_dropped_by_ah);
+ }
+
+ /* Table */
+ for (table_id = port_in->table_id; p->pkts_mask != 0; ) {
+ struct rte_table *table;
+ uint64_t lookup_hit_mask, lookup_miss_mask;
+
+ /* Lookup */
+ table = &p->tables[table_id];
+ table->ops.f_lookup(table->h_table, p->pkts, p->pkts_mask,
+ &lookup_hit_mask, (void **) p->entries);
+ lookup_miss_mask = p->pkts_mask & (~lookup_hit_mask);
+
+ /* Lookup miss */
+ if (lookup_miss_mask != 0) {
+ struct rte_pipeline_table_entry *default_entry =
+ table->default_entry;
+
+ p->pkts_mask = lookup_miss_mask;
- /* Lookup hit */
- if (lookup_hit_mask != 0) {
- /* Table user actions */
- if (table->f_action_hit != NULL) {
- uint64_t mask = lookup_hit_mask;
-
- table->f_action_hit(p->pkts,
- &lookup_hit_mask,
- p->entries, table->arg_ah);
- mask ^= lookup_hit_mask;
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |= mask;
- RTE_PIPELINE_STATS_ADD_M(
- table->n_pkts_dropped_by_lkp_hit_ah, mask);
- }
-
- /* Table reserved actions */
- rte_pipeline_compute_masks(p, lookup_hit_mask);
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |=
- p->action_mask1[
- RTE_PIPELINE_ACTION_DROP];
- p->action_mask0[RTE_PIPELINE_ACTION_PORT] |=
- p->action_mask1[
- RTE_PIPELINE_ACTION_PORT];
- p->action_mask0[RTE_PIPELINE_ACTION_PORT_META] |=
- p->action_mask1[
- RTE_PIPELINE_ACTION_PORT_META];
- p->action_mask0[RTE_PIPELINE_ACTION_TABLE] |=
- p->action_mask1[
- RTE_PIPELINE_ACTION_TABLE];
-
- RTE_PIPELINE_STATS_ADD_M(table->n_pkts_dropped_lkp_hit,
- p->action_mask1[RTE_PIPELINE_ACTION_DROP]);
+ /* Table user actions */
+ if (table->f_action_miss != NULL) {
+ table->f_action_miss(p,
+ p->pkts,
+ lookup_miss_mask,
+ default_entry,
+ table->arg_ah);
+
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ table->n_pkts_dropped_by_lkp_miss_ah);
}
- /* Prepare for next iteration */
- pkts_mask = p->action_mask0[RTE_PIPELINE_ACTION_TABLE];
- table_id = table->table_next_id;
- p->action_mask0[RTE_PIPELINE_ACTION_TABLE] = 0;
+ /* Table reserved actions */
+ if ((default_entry->action == RTE_PIPELINE_ACTION_PORT) &&
+ (p->pkts_mask != 0))
+ rte_pipeline_action_handler_port_bulk(p,
+ p->pkts_mask,
+ default_entry->port_id);
+ else {
+ uint32_t pos = default_entry->action;
+
+ RTE_PIPELINE_STATS_TABLE_DROP0(p);
+
+ p->action_mask0[pos] |= p->pkts_mask;
+
+ RTE_PIPELINE_STATS_TABLE_DROP1(p,
+ table->n_pkts_dropped_lkp_miss);
+ }
}
- /* Table reserved action PORT */
- rte_pipeline_action_handler_port(p,
- p->action_mask0[RTE_PIPELINE_ACTION_PORT]);
+ /* Lookup hit */
+ if (lookup_hit_mask != 0) {
+ p->pkts_mask = lookup_hit_mask;
- /* Table reserved action PORT META */
- rte_pipeline_action_handler_port_meta(p,
- p->action_mask0[RTE_PIPELINE_ACTION_PORT_META]);
+ /* Table user actions */
+ if (table->f_action_hit != NULL) {
+ table->f_action_hit(p,
+ p->pkts,
+ lookup_hit_mask,
+ p->entries,
+ table->arg_ah);
- /* Table reserved action DROP */
- rte_pipeline_action_handler_drop(p,
- p->action_mask0[RTE_PIPELINE_ACTION_DROP]);
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ table->n_pkts_dropped_by_lkp_hit_ah);
+ }
+
+ /* Table reserved actions */
+ RTE_PIPELINE_STATS_TABLE_DROP0(p);
+ rte_pipeline_compute_masks(p, p->pkts_mask);
+ p->action_mask0[RTE_PIPELINE_ACTION_DROP] |=
+ p->action_mask1[
+ RTE_PIPELINE_ACTION_DROP];
+ p->action_mask0[RTE_PIPELINE_ACTION_PORT] |=
+ p->action_mask1[
+ RTE_PIPELINE_ACTION_PORT];
+ p->action_mask0[RTE_PIPELINE_ACTION_PORT_META] |=
+ p->action_mask1[
+ RTE_PIPELINE_ACTION_PORT_META];
+ p->action_mask0[RTE_PIPELINE_ACTION_TABLE] |=
+ p->action_mask1[
+ RTE_PIPELINE_ACTION_TABLE];
+
+ RTE_PIPELINE_STATS_TABLE_DROP1(p,
+ table->n_pkts_dropped_lkp_hit);
+ }
+
+ /* Prepare for next iteration */
+ p->pkts_mask = p->action_mask0[RTE_PIPELINE_ACTION_TABLE];
+ table_id = table->table_next_id;
+ p->action_mask0[RTE_PIPELINE_ACTION_TABLE] = 0;
}
- return 0;
+ /* Table reserved action PORT */
+ rte_pipeline_action_handler_port(p,
+ p->action_mask0[RTE_PIPELINE_ACTION_PORT]);
+
+ /* Table reserved action PORT META */
+ rte_pipeline_action_handler_port_meta(p,
+ p->action_mask0[RTE_PIPELINE_ACTION_PORT_META]);
+
+ /* Table reserved action DROP */
+ rte_pipeline_action_handler_drop(p,
+ p->action_mask0[RTE_PIPELINE_ACTION_DROP]);
+
+ /* Pick candidate for next port IN to serve */
+ p->port_in_next = port_in->next;
+
+ return n_pkts;
}
int
@@ -1498,26 +1503,32 @@ rte_pipeline_flush(struct rte_pipeline *p)
int
rte_pipeline_port_out_packet_insert(struct rte_pipeline *p,
- uint32_t port_id, struct rte_mbuf *pkt)
+ uint32_t port_id, struct rte_mbuf *pkt)
{
struct rte_port_out *port_out = &p->ports_out[port_id];
- /* Output port user actions */
- if (port_out->f_action == NULL)
- port_out->ops.f_tx(port_out->h_port, pkt); /* Output port TX */
- else {
- uint64_t pkt_mask = 1LLU;
-
- port_out->f_action(pkt, &pkt_mask, port_out->arg_ah);
-
- if (pkt_mask != 0) /* Output port TX */
- port_out->ops.f_tx(port_out->h_port, pkt);
- else {
- rte_pktmbuf_free(pkt);
- RTE_PIPELINE_STATS_ADD(port_out->n_pkts_dropped_by_ah, 1);
- }
- }
+ port_out->ops.f_tx(port_out->h_port, pkt); /* Output port TX */
+
+ return 0;
+}
+
+int rte_pipeline_ah_packet_hijack(struct rte_pipeline *p,
+ uint64_t pkts_mask)
+{
+ pkts_mask &= p->pkts_mask;
+ p->pkts_mask &= ~pkts_mask;
+
+ return 0;
+}
+
+int rte_pipeline_ah_packet_drop(struct rte_pipeline *p,
+ uint64_t pkts_mask)
+{
+ pkts_mask &= p->pkts_mask;
+ p->pkts_mask &= ~pkts_mask;
+ p->action_mask0[RTE_PIPELINE_ACTION_DROP] |= pkts_mask;
+ RTE_PIPELINE_STATS_AH_DROP_WRITE(p, pkts_mask);
return 0;
}
diff --git a/lib/librte_pipeline/rte_pipeline.h b/lib/librte_pipeline/rte_pipeline.h
index 5459324..ec3c2ea 100644
--- a/lib/librte_pipeline/rte_pipeline.h
+++ b/lib/librte_pipeline/rte_pipeline.h
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -263,6 +263,8 @@ struct rte_pipeline_table_entry {
* required not to free the packet buffer, which will be freed eventually by
* the pipeline.
*
+ * @param p
+ * Handle to pipeline instance
* @param pkts
* Burst of input packets specified as array of up to 64 pointers to struct
* rte_mbuf
@@ -283,8 +285,9 @@ struct rte_pipeline_table_entry {
* 0 on success, error code otherwise
*/
typedef int (*rte_pipeline_table_action_handler_hit)(
+ struct rte_pipeline *p,
struct rte_mbuf **pkts,
- uint64_t *pkts_mask,
+ uint64_t pkts_mask,
struct rte_pipeline_table_entry **entries,
void *arg);
@@ -296,6 +299,8 @@ typedef int (*rte_pipeline_table_action_handler_hit)(
* required not to free the packet buffer, which will be freed eventually by
* the pipeline.
*
+ * @param p
+ * Handle to pipeline instance
* @param pkts
* Burst of input packets specified as array of up to 64 pointers to struct
* rte_mbuf
@@ -316,8 +321,9 @@ typedef int (*rte_pipeline_table_action_handler_hit)(
* 0 on success, error code otherwise
*/
typedef int (*rte_pipeline_table_action_handler_miss)(
+ struct rte_pipeline *p,
struct rte_mbuf **pkts,
- uint64_t *pkts_mask,
+ uint64_t pkts_mask,
struct rte_pipeline_table_entry *entry,
void *arg);
@@ -565,16 +571,14 @@ int rte_pipeline_table_stats_read(struct rte_pipeline *p, uint32_t table_id,
* required not to free the packet buffer, which will be freed eventually by
* the pipeline.
*
+ * @param p
+ * Handle to pipeline instance
* @param pkts
* Burst of input packets specified as array of up to 64 pointers to struct
* rte_mbuf
* @param n
* Number of packets in the input burst. This parameter specifies that
* elements 0 to (n-1) of pkts array are valid.
- * @param pkts_mask
- * 64-bit bitmask specifying which packets in the input burst are still valid
- * after the action handler is executed. When pkts_mask bit n is set, then
- * element n of pkts array is pointing to a valid packet.
* @param arg
* Opaque parameter registered by the user at the pipeline table creation
* time
@@ -582,9 +586,9 @@ int rte_pipeline_table_stats_read(struct rte_pipeline *p, uint32_t table_id,
* 0 on success, error code otherwise
*/
typedef int (*rte_pipeline_port_in_action_handler)(
+ struct rte_pipeline *p,
struct rte_mbuf **pkts,
uint32_t n,
- uint64_t *pkts_mask,
void *arg);
/** Parameters for pipeline input port creation */
@@ -692,29 +696,6 @@ int rte_pipeline_port_in_stats_read(struct rte_pipeline *p, uint32_t port_id,
#define RTE_PIPELINE_PORT_OUT_MAX 64
/**
- * Pipeline output port action handler for single packet
- *
- * The action handler can decide to drop packets by resetting the pkt_mask
- * argument. In this case, the action handler is required not to free the
- * packet buffer, which will be freed eventually by the pipeline.
- *
- * @param pkt
- * Input packet
- * @param pkt_mask
- * Output argument set to 0 when the action handler decides to drop the input
- * packet and to 1LLU otherwise
- * @param arg
- * Opaque parameter registered by the user at the pipeline table creation
- * time
- * @return
- * 0 on success, error code otherwise
- */
-typedef int (*rte_pipeline_port_out_action_handler)(
- struct rte_mbuf *pkt,
- uint64_t *pkt_mask,
- void *arg);
-
-/**
* Pipeline output port action handler bulk
*
* The action handler can decide to drop packets by resetting the associated
@@ -722,22 +703,21 @@ typedef int (*rte_pipeline_port_out_action_handler)(
* required not to free the packet buffer, which will be freed eventually by
* the pipeline.
*
+ * @param p
+ * Handle to pipeline instance
* @param pkts
* Burst of input packets specified as array of up to 64 pointers to struct
* rte_mbuf
- * @param pkts_mask
- * 64-bit bitmask specifying which packets in the input burst are valid. When
- * pkts_mask bit n is set, then element n of pkts array is pointing to a
- * valid packet. Otherwise, element n of pkts array will not be accessed.
* @param arg
* Opaque parameter registered by the user at the pipeline table creation
* time
* @return
* 0 on success, error code otherwise
*/
-typedef int (*rte_pipeline_port_out_action_handler_bulk)(
+typedef int (*rte_pipeline_port_out_action_handler)(
+ struct rte_pipeline *p,
struct rte_mbuf **pkts,
- uint64_t *pkts_mask,
+ uint64_t pkts_mask,
void *arg);
/** Parameters for pipeline output port creation. The action handlers have to
@@ -750,12 +730,9 @@ struct rte_pipeline_port_out_params {
/** Opaque parameter to be passed to create operation when invoked */
void *arg_create;
- /** Callback function executing the user actions on single input
- packet */
- rte_pipeline_port_out_action_handler f_action;
/** Callback function executing the user actions on bust of input
packets */
- rte_pipeline_port_out_action_handler_bulk f_action_bulk;
+ rte_pipeline_port_out_action_handler f_action;
/** Opaque parameter to be passed to the action handler when invoked */
void *arg_ah;
};
@@ -802,6 +779,45 @@ int rte_pipeline_port_out_packet_insert(struct rte_pipeline *p,
struct rte_mbuf *pkt);
/**
+ * Pipeline packet hijack
+ *
+ * This function is called by the pipeline action handlers (port in/out, table)
+ * to hijack the packets selected using packet mask. The hijacked packets will
+ * no longer bethe part of the burst of packets undergoing pipeline processing.
+ * The hijacked packets can either be dropped or sent out of the pipeline on
+ * any output port by the action handler.
+ *
+ * @param p
+ * Handle to pipeline instance
+ * @param pkt_mask
+ * 64-bit bitmask specifying which packets in the input burst are valid. When
+ * pkts_mask bit n is set, then element n of pkts array is pointing to a
+ * valid packet. Otherwise, element n of pkts array will not be accessed.
+ * @return
+ * 0 on success, error code otherwise
+ */
+int rte_pipeline_ah_packet_hijack(struct rte_pipeline *p,
+ uint64_t pkts_mask);
+
+/**
+ * Pipeline packet drop
+ *
+ * This function is called by the pipeline action handlers (port in/out, table)
+ * to drop the packets selected using packet mask.
+ *
+ * @param p
+ * Handle to pipeline instance
+ * @param pkts_mask
+ * 64-bit bitmask specifying which packets in the input burst are valid. When
+ * pkts_mask bit n is set, then element n of pkts array is pointing to a
+ * valid packet. Otherwise, element n of pkts array will not be accessed.
+ * @return
+ * 0 on success, error code otherwise
+ */
+int rte_pipeline_ah_packet_drop(struct rte_pipeline *p,
+ uint64_t pkts_mask);
+
+/**
* Read pipeline port out stats.
*
* This function reads port out statistics identified by *port_id* of given
diff --git a/lib/librte_pipeline/rte_pipeline_version.map b/lib/librte_pipeline/rte_pipeline_version.map
index 4cc86f6..e4ee154 100644
--- a/lib/librte_pipeline/rte_pipeline_version.map
+++ b/lib/librte_pipeline/rte_pipeline_version.map
@@ -37,3 +37,11 @@ DPDK_2.2 {
rte_pipeline_table_entry_delete_bulk;
} DPDK_2.1;
+
+DPDK_16.04 {
+ global:
+
+ rte_pipeline_ah_packet_hijack;
+ rte_pipeline_ah_packet_drop;
+
+} DPDK_2.2;
--
2.5.0
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 07/12] librte_ether: extend rte_eth_fdir_flow to support tunnel format
@ 2016-01-26 6:20 4% ` Jingjing Wu
0 siblings, 0 replies; 200+ results
From: Jingjing Wu @ 2016-01-26 6:20 UTC (permalink / raw)
To: dev
This patch changed rte_eth_fdir_flow from union to struct to
support more packets formats, for example, Vxlan and GRE tunnel
packets with IP inner frame.
This patch also add new RTE_FDIR_TUNNEL_TYPE_GRE enum.
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
doc/guides/rel_notes/release_2_3.rst | 4 ++++
lib/librte_ether/rte_eth_ctrl.h | 27 +++++++++++++++------------
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..2216fee 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,10 @@ API Changes
ABI Changes
-----------
+* The ethdev flow director structure ``rte_eth_fdir_flow`` structure was
+ changed. New fields were added to extend flow director's input set, and
+ organizing is also changed to support multiple input format.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 248f719..eb4c13d 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -495,6 +495,7 @@ enum rte_eth_fdir_tunnel_type {
RTE_FDIR_TUNNEL_TYPE_UNKNOWN = 0,
RTE_FDIR_TUNNEL_TYPE_NVGRE,
RTE_FDIR_TUNNEL_TYPE_VXLAN,
+ RTE_FDIR_TUNNEL_TYPE_GRE,
};
/**
@@ -508,18 +509,20 @@ struct rte_eth_tunnel_flow {
};
/**
- * An union contains the inputs for all types of flow
+ * A struct contains the inputs for all types of flow
*/
-union rte_eth_fdir_flow {
- struct rte_eth_l2_flow l2_flow;
- struct rte_eth_udpv4_flow udp4_flow;
- struct rte_eth_tcpv4_flow tcp4_flow;
- struct rte_eth_sctpv4_flow sctp4_flow;
- struct rte_eth_ipv4_flow ip4_flow;
- struct rte_eth_udpv6_flow udp6_flow;
- struct rte_eth_tcpv6_flow tcp6_flow;
- struct rte_eth_sctpv6_flow sctp6_flow;
- struct rte_eth_ipv6_flow ipv6_flow;
+struct rte_eth_fdir_flow {
+ union {
+ struct rte_eth_l2_flow l2_flow;
+ struct rte_eth_udpv4_flow udp4_flow;
+ struct rte_eth_tcpv4_flow tcp4_flow;
+ struct rte_eth_sctpv4_flow sctp4_flow;
+ struct rte_eth_ipv4_flow ip4_flow;
+ struct rte_eth_udpv6_flow udp6_flow;
+ struct rte_eth_tcpv6_flow tcp6_flow;
+ struct rte_eth_sctpv6_flow sctp6_flow;
+ struct rte_eth_ipv6_flow ipv6_flow;
+ };
struct rte_eth_mac_vlan_flow mac_vlan_flow;
struct rte_eth_tunnel_flow tunnel_flow;
};
@@ -540,7 +543,7 @@ struct rte_eth_fdir_flow_ext {
*/
struct rte_eth_fdir_input {
uint16_t flow_type;
- union rte_eth_fdir_flow flow;
+ struct rte_eth_fdir_flow flow;
/**< Flow fields to match, dependent on flow_type */
struct rte_eth_fdir_flow_ext flow_ext;
/**< Additional fields to match */
--
2.4.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 07/12] librte_ether: extend rte_eth_fdir_flow to support tunnel format
@ 2016-01-26 6:26 4% ` Jingjing Wu
0 siblings, 0 replies; 200+ results
From: Jingjing Wu @ 2016-01-26 6:26 UTC (permalink / raw)
To: dev
This patch changed rte_eth_fdir_flow from union to struct to
support more packets formats, for example, Vxlan and GRE tunnel
packets with IP inner frame.
This patch also add new RTE_FDIR_TUNNEL_TYPE_GRE enum.
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
doc/guides/rel_notes/release_2_3.rst | 4 ++++
lib/librte_ether/rte_eth_ctrl.h | 27 +++++++++++++++------------
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..2216fee 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,10 @@ API Changes
ABI Changes
-----------
+* The ethdev flow director structure ``rte_eth_fdir_flow`` structure was
+ changed. New fields were added to extend flow director's input set, and
+ organizing is also changed to support multiple input format.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 248f719..eb4c13d 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -495,6 +495,7 @@ enum rte_eth_fdir_tunnel_type {
RTE_FDIR_TUNNEL_TYPE_UNKNOWN = 0,
RTE_FDIR_TUNNEL_TYPE_NVGRE,
RTE_FDIR_TUNNEL_TYPE_VXLAN,
+ RTE_FDIR_TUNNEL_TYPE_GRE,
};
/**
@@ -508,18 +509,20 @@ struct rte_eth_tunnel_flow {
};
/**
- * An union contains the inputs for all types of flow
+ * A struct contains the inputs for all types of flow
*/
-union rte_eth_fdir_flow {
- struct rte_eth_l2_flow l2_flow;
- struct rte_eth_udpv4_flow udp4_flow;
- struct rte_eth_tcpv4_flow tcp4_flow;
- struct rte_eth_sctpv4_flow sctp4_flow;
- struct rte_eth_ipv4_flow ip4_flow;
- struct rte_eth_udpv6_flow udp6_flow;
- struct rte_eth_tcpv6_flow tcp6_flow;
- struct rte_eth_sctpv6_flow sctp6_flow;
- struct rte_eth_ipv6_flow ipv6_flow;
+struct rte_eth_fdir_flow {
+ union {
+ struct rte_eth_l2_flow l2_flow;
+ struct rte_eth_udpv4_flow udp4_flow;
+ struct rte_eth_tcpv4_flow tcp4_flow;
+ struct rte_eth_sctpv4_flow sctp4_flow;
+ struct rte_eth_ipv4_flow ip4_flow;
+ struct rte_eth_udpv6_flow udp6_flow;
+ struct rte_eth_tcpv6_flow tcp6_flow;
+ struct rte_eth_sctpv6_flow sctp6_flow;
+ struct rte_eth_ipv6_flow ipv6_flow;
+ };
struct rte_eth_mac_vlan_flow mac_vlan_flow;
struct rte_eth_tunnel_flow tunnel_flow;
};
@@ -540,7 +543,7 @@ struct rte_eth_fdir_flow_ext {
*/
struct rte_eth_fdir_input {
uint16_t flow_type;
- union rte_eth_fdir_flow flow;
+ struct rte_eth_fdir_flow flow;
/**< Flow fields to match, dependent on flow_type */
struct rte_eth_fdir_flow_ext flow_ext;
/**< Additional fields to match */
--
2.4.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] ethdev: fix byte order inconsistence between fdir flow and mask
@ 2016-01-27 8:37 3% Jingjing Wu
2016-01-27 9:19 0% ` Thomas Monjalon
2016-02-01 2:48 3% ` [dpdk-dev] [PATCH v2] " Jingjing Wu
0 siblings, 2 replies; 200+ results
From: Jingjing Wu @ 2016-01-27 8:37 UTC (permalink / raw)
To: dev
Fixed issue of byte order in ethdev library that the structure
for setting fdir's mask and flow entry is inconsist and made
inputs of mask be in big endian.
fixes: 76c6f89e80d4 ("ixgbe: support new flow director masks")
2d4c1a9ea2ac ("ethdev: add new flow director masks")
Reported-by: Yaacov Hazan <yaacovh@mellanox.com>
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
app/test-pmd/cmdline.c | 6 ++---
doc/guides/rel_notes/release_2_3.rst | 6 +++++
drivers/net/ixgbe/ixgbe_fdir.c | 47 ++++++++++++++++++++++--------------
lib/librte_ether/rte_eth_ctrl.h | 7 ++++--
4 files changed, 43 insertions(+), 23 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..13194c9 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -8687,13 +8687,13 @@ cmd_flow_director_mask_parsed(void *parsed_result,
return;
}
- mask->vlan_tci_mask = res->vlan_mask;
+ mask->vlan_tci_mask = rte_cpu_to_be_16(res->vlan_mask);
IPV4_ADDR_TO_UINT(res->ipv4_src, mask->ipv4_mask.src_ip);
IPV4_ADDR_TO_UINT(res->ipv4_dst, mask->ipv4_mask.dst_ip);
IPV6_ADDR_TO_ARRAY(res->ipv6_src, mask->ipv6_mask.src_ip);
IPV6_ADDR_TO_ARRAY(res->ipv6_dst, mask->ipv6_mask.dst_ip);
- mask->src_port_mask = res->port_src;
- mask->dst_port_mask = res->port_dst;
+ mask->src_port_mask = rte_cpu_to_be_16(res->port_src);
+ mask->dst_port_mask = rte_cpu_to_be_16(res->port_dst);
}
cmd_reconfig_device_queue(res->port_id, 1, 1);
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..28d0f27 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -19,6 +19,10 @@ Drivers
Libraries
~~~~~~~~~
+* ** fix byte order inconsistence between fdir flow and mask **
+
+ Fixed issue in ethdev library that the structure for setting
+ fdir's mask and flow entry is inconsist in byte order.
Examples
~~~~~~~~
@@ -39,6 +43,8 @@ API Changes
ABI Changes
-----------
+* The fields in The ethdev structures ``rte_eth_fdir_masks`` were
+ changed to be in big endian.
Shared Library Versions
-----------------------
diff --git a/drivers/net/ixgbe/ixgbe_fdir.c b/drivers/net/ixgbe/ixgbe_fdir.c
index e03219b..7423b2d 100644
--- a/drivers/net/ixgbe/ixgbe_fdir.c
+++ b/drivers/net/ixgbe/ixgbe_fdir.c
@@ -309,6 +309,7 @@ fdir_set_input_mask_82599(struct rte_eth_dev *dev,
uint32_t fdiripv6m; /* IPv6 source and destination masks. */
uint16_t dst_ipv6m = 0;
uint16_t src_ipv6m = 0;
+ volatile uint32_t *reg;
PMD_INIT_FUNC_TRACE();
@@ -322,16 +323,16 @@ fdir_set_input_mask_82599(struct rte_eth_dev *dev,
/* use the L4 protocol mask for raw IPv4/IPv6 traffic */
fdirm |= IXGBE_FDIRM_L4P;
- if (input_mask->vlan_tci_mask == 0x0FFF)
+ if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0x0FFF))
/* mask VLAN Priority */
fdirm |= IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask == 0xE000)
+ else if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0xE000))
/* mask VLAN ID */
fdirm |= IXGBE_FDIRM_VLANID;
else if (input_mask->vlan_tci_mask == 0)
/* mask VLAN ID and Priority */
fdirm |= IXGBE_FDIRM_VLANID | IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask != 0xEFFF) {
+ else if (input_mask->vlan_tci_mask != rte_cpu_to_be_16(0xEFFF)) {
PMD_INIT_LOG(ERR, "invalid vlan_tci_mask");
return -EINVAL;
}
@@ -340,19 +341,26 @@ fdir_set_input_mask_82599(struct rte_eth_dev *dev,
IXGBE_WRITE_REG(hw, IXGBE_FDIRM, fdirm);
/* store the TCP/UDP port masks, bit reversed from port layout */
- fdirtcpm = reverse_fdir_bitmasks(input_mask->dst_port_mask,
- input_mask->src_port_mask);
+ fdirtcpm = reverse_fdir_bitmasks(
+ rte_be_to_cpu_16(input_mask->dst_port_mask),
+ rte_be_to_cpu_16(input_mask->src_port_mask));
- /* write all the same so that UDP, TCP and SCTP use the same mask */
+ /* write all the same so that UDP, TCP and SCTP use the same mask
+ * (little-endian)
+ */
IXGBE_WRITE_REG(hw, IXGBE_FDIRTCPM, ~fdirtcpm);
IXGBE_WRITE_REG(hw, IXGBE_FDIRUDPM, ~fdirtcpm);
IXGBE_WRITE_REG(hw, IXGBE_FDIRSCTPM, ~fdirtcpm);
info->mask.src_port_mask = input_mask->src_port_mask;
info->mask.dst_port_mask = input_mask->dst_port_mask;
- /* Store source and destination IPv4 masks (big-endian) */
- IXGBE_WRITE_REG(hw, IXGBE_FDIRSIP4M, ~(input_mask->ipv4_mask.src_ip));
- IXGBE_WRITE_REG(hw, IXGBE_FDIRDIP4M, ~(input_mask->ipv4_mask.dst_ip));
+ /* Store source and destination IPv4 masks (big-endian),
+ * can not use IXGBE_WRITE_REG.
+ */
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRSIP4M);
+ *reg = ~(input_mask->ipv4_mask.src_ip);
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRDIP4M);
+ *reg = ~(input_mask->ipv4_mask.dst_ip);
info->mask.src_ipv4_mask = input_mask->ipv4_mask.src_ip;
info->mask.dst_ipv4_mask = input_mask->ipv4_mask.dst_ip;
@@ -401,16 +409,16 @@ fdir_set_input_mask_x550(struct rte_eth_dev *dev,
/* some bits must be set for mac vlan or tunnel mode */
fdirm |= IXGBE_FDIRM_L4P | IXGBE_FDIRM_L3P;
- if (input_mask->vlan_tci_mask == 0x0FFF)
+ if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0x0FFF))
/* mask VLAN Priority */
fdirm |= IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask == 0xE000)
+ else if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0xE000))
/* mask VLAN ID */
fdirm |= IXGBE_FDIRM_VLANID;
else if (input_mask->vlan_tci_mask == 0)
/* mask VLAN ID and Priority */
fdirm |= IXGBE_FDIRM_VLANID | IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask != 0xEFFF) {
+ else if (input_mask->vlan_tci_mask != rte_cpu_to_be_16(0xEFFF)) {
PMD_INIT_LOG(ERR, "invalid vlan_tci_mask");
return -EINVAL;
}
@@ -444,7 +452,7 @@ fdir_set_input_mask_x550(struct rte_eth_dev *dev,
info->mask.tunnel_type_mask =
input_mask->tunnel_type_mask;
- switch (input_mask->tunnel_id_mask & 0xFFFFFFFF) {
+ switch (rte_be_to_cpu_32(input_mask->tunnel_id_mask)) {
case 0x0:
/* Mask vxlan id */
fdiripv6m |= IXGBE_FDIRIP6M_TNI_VNI;
@@ -904,13 +912,16 @@ fdir_write_perfect_filter_82599(struct ixgbe_hw *hw,
u32 addr_low, addr_high;
u32 tunnel_type = 0;
int err = 0;
+ volatile uint32_t *reg;
if (mode == RTE_FDIR_MODE_PERFECT) {
- /* record the IPv4 address (big-endian) */
- IXGBE_WRITE_REG(hw, IXGBE_FDIRIPSA,
- input->formatted.src_ip[0]);
- IXGBE_WRITE_REG(hw, IXGBE_FDIRIPDA,
- input->formatted.dst_ip[0]);
+ /* record the IPv4 address (big-endian)
+ * can not use IXGBE_WRITE_REG.
+ */
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRIPSA);
+ *reg = input->formatted.src_ip[0];
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRIPDA);
+ *reg = input->formatted.dst_ip[0];
/* record source and destination port (little-endian)*/
fdirport = IXGBE_NTOHS(input->formatted.dst_port);
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index ce224ad..80f9048 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -501,6 +501,7 @@ struct rte_eth_tunnel_flow {
/**
* An union contains the inputs for all types of flow
+ * Items in flows need to be in big endian
*/
union rte_eth_fdir_flow {
struct rte_eth_l2_flow l2_flow;
@@ -586,6 +587,7 @@ struct rte_eth_fdir_filter {
/**
* A structure used to configure FDIR masks that are used by the device
* to match the various fields of RX packet headers.
+ * Items in it need to be in big endian
*/
struct rte_eth_fdir_masks {
uint16_t vlan_tci_mask;
@@ -593,9 +595,10 @@ struct rte_eth_fdir_masks {
struct rte_eth_ipv6_flow ipv6_mask;
uint16_t src_port_mask;
uint16_t dst_port_mask;
- uint8_t mac_addr_byte_mask; /** Per byte MAC address mask */
+ uint8_t mac_addr_byte_mask; /** Bit mask for associated byte */
uint32_t tunnel_id_mask; /** tunnel ID mask */
- uint8_t tunnel_type_mask;
+ uint8_t tunnel_type_mask; /**< 1 - Match tunnel type,
+ 0 - Ignore tunnel type. */
};
/**
--
2.4.0
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ethdev: fix byte order inconsistence between fdir flow and mask
2016-01-27 8:37 3% [dpdk-dev] [PATCH] ethdev: fix byte order inconsistence between fdir flow and mask Jingjing Wu
@ 2016-01-27 9:19 0% ` Thomas Monjalon
2016-01-28 5:55 0% ` Wu, Jingjing
2016-02-01 2:48 3% ` [dpdk-dev] [PATCH v2] " Jingjing Wu
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2016-01-27 9:19 UTC (permalink / raw)
To: Jingjing Wu, john.mcnamara; +Cc: dev
2016-01-27 16:37, Jingjing Wu:
> Fixed issue of byte order in ethdev library that the structure
> for setting fdir's mask and flow entry is inconsist and made
> inputs of mask be in big endian.
Please be more precise. Which one is big endian?
Wasn't it tested before?
> fixes: 76c6f89e80d4 ("ixgbe: support new flow director masks")
> 2d4c1a9ea2ac ("ethdev: add new flow director masks")
Please put Fixes: on the two lines.
> --- a/doc/guides/rel_notes/release_2_3.rst
> +++ b/doc/guides/rel_notes/release_2_3.rst
> @@ -19,6 +19,10 @@ Drivers
> Libraries
> ~~~~~~~~~
>
> +* ** fix byte order inconsistence between fdir flow and mask **
> +
> + Fixed issue in ethdev library that the structure for setting
> + fdir's mask and flow entry is inconsist in byte order.
John, comment on release notes formatting?
It's important to have the first items well formatted.
> @@ -39,6 +43,8 @@ API Changes
> ABI Changes
> -----------
>
> +* The fields in The ethdev structures ``rte_eth_fdir_masks`` were
> + changed to be in big endian.
Please take care of uppercase typo here.
> - /* write all the same so that UDP, TCP and SCTP use the same mask */
> + /* write all the same so that UDP, TCP and SCTP use the same mask
> + * (little-endian)
> + */
Spacing typo here.
Sorry for the nits ;)
> - uint8_t mac_addr_byte_mask; /** Per byte MAC address mask */
> + uint8_t mac_addr_byte_mask; /** Bit mask for associated byte */
> uint32_t tunnel_id_mask; /** tunnel ID mask */
> - uint8_t tunnel_type_mask;
> + uint8_t tunnel_type_mask; /**< 1 - Match tunnel type,
> + 0 - Ignore tunnel type. */
These changes seem unrelated with the patch.
It's good to improve doc of this API but it's maybe not enough.
Example:
uint8_t mac_addr_byte_mask; /** Bit mask for associated byte */
Are we sure everybody understand how to fill it?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH V1 1/1] jobstats: added function abort for job
@ 2016-01-27 13:37 3% ` Panu Matilainen
2016-01-27 15:57 0% ` Jastrzebski, MichalX K
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-27 13:37 UTC (permalink / raw)
To: Marcin Kerlin, dev
On 01/26/2016 06:15 PM, Marcin Kerlin wrote:
> This patch adds new function rte_jobstats_abort. It marks *job* as finished
> and time of this work will be add to management time instead of execution time.
> This function should be used instead of rte_jobstats_finish if condition occure,
> condition is defined by the application for example when receiving n>0 packets.
>
> Signed-off-by: Marcin Kerlin <marcinx.kerlin@intel.com>
> ---
> lib/librte_jobstats/rte_jobstats.c | 22 ++++++++++++++++++++++
> lib/librte_jobstats/rte_jobstats.h | 17 +++++++++++++++++
> lib/librte_jobstats/rte_jobstats_version.map | 7 +++++++
> 3 files changed, 46 insertions(+)
>
[...]
> diff --git a/lib/librte_jobstats/rte_jobstats.h b/lib/librte_jobstats/rte_jobstats.h
> index de6a89a..9995319 100644
> --- a/lib/librte_jobstats/rte_jobstats.h
> +++ b/lib/librte_jobstats/rte_jobstats.h
> @@ -90,6 +90,9 @@ struct rte_jobstats {
> uint64_t exec_cnt;
> /**< Execute count. */
>
> + uint64_t last_job_time;
> + /**< Last job time */
> +
> char name[RTE_JOBSTATS_NAMESIZE];
> /**< Name of this job */
>
AFAICS this is an ABI break and as such, needs to be preannounced, see
http://dpdk.org/doc/guides/contributing/versioning.html
For 2.3 it'd need to be a CONFIG_RTE_NEXT_ABI feature.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API
@ 2016-01-27 13:56 3% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2016-01-27 13:56 UTC (permalink / raw)
To: Huawei Xie, dev; +Cc: dprovan
On 01/26/2016 07:03 PM, Huawei Xie wrote:
> v6 changes:
> reflect the changes in release notes and library version map file
> revise our duff's code style a bit to make it more readable
>
> v5 changes:
> add comment about duff's device and our variant implementation
>
> v3 changes:
> move while after case 0
> add context about duff's device and why we use while loop in the commit
> message
>
> v2 changes:
> unroll the loop a bit to help the performance
>
> rte_pktmbuf_alloc_bulk allocates a bulk of packet mbufs.
>
> There is related thread about this bulk API.
> http://dpdk.org/dev/patchwork/patch/4718/
> Thanks to Konstantin's loop unrolling.
>
> Attached the wiki page about duff's device. It explains the performance
> optimization through loop unwinding, and also the most dramatic use of
> case label fall-through.
> https://en.wikipedia.org/wiki/Duff%27s_device
>
> In our implementation, we use while() loop rather than do{} while() loop
> because we could not assume count is strictly positive. Using while()
> loop saves one line of check if count is zero.
>
> Signed-off-by: Gerald Rogers <gerald.rogers@intel.com>
> Signed-off-by: Huawei Xie <huawei.xie@intel.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> doc/guides/rel_notes/release_2_3.rst | 3 ++
> lib/librte_mbuf/rte_mbuf.h | 55 ++++++++++++++++++++++++++++++++++++
> lib/librte_mbuf/rte_mbuf_version.map | 7 +++++
> 3 files changed, 65 insertions(+)
>
> diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
> index 99de186..a52cba3 100644
> --- a/doc/guides/rel_notes/release_2_3.rst
> +++ b/doc/guides/rel_notes/release_2_3.rst
> @@ -4,6 +4,9 @@ DPDK Release 2.3
> New Features
> ------------
>
> +* **Enable bulk allocation of mbufs. **
> + A new function ``rte_pktmbuf_alloc_bulk()`` has been added to allow the user
> + to allocate a bulk of mbufs.
>
> Resolved Issues
> ---------------
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index f234ac9..b2ed479 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -1336,6 +1336,61 @@ static inline struct rte_mbuf *rte_pktmbuf_alloc(struct rte_mempool *mp)
> }
>
> /**
> + * Allocate a bulk of mbufs, initialize refcnt and reset the fields to default
> + * values.
> + *
> + * @param pool
> + * The mempool from which mbufs are allocated.
> + * @param mbufs
> + * Array of pointers to mbufs
> + * @param count
> + * Array size
> + * @return
> + * - 0: Success
> + */
> +static inline int rte_pktmbuf_alloc_bulk(struct rte_mempool *pool,
> + struct rte_mbuf **mbufs, unsigned count)
> +{
> + unsigned idx = 0;
> + int rc;
> +
> + rc = rte_mempool_get_bulk(pool, (void **)mbufs, count);
> + if (unlikely(rc))
> + return rc;
> +
> + /* To understand duff's device on loop unwinding optimization, see
> + * https://en.wikipedia.org/wiki/Duff's_device.
> + * Here while() loop is used rather than do() while{} to avoid extra
> + * check if count is zero.
> + */
> + switch (count % 4) {
> + case 0:
> + while (idx != count) {
> + RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
> + rte_mbuf_refcnt_set(mbufs[idx], 1);
> + rte_pktmbuf_reset(mbufs[idx]);
> + idx++;
> + case 3:
> + RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
> + rte_mbuf_refcnt_set(mbufs[idx], 1);
> + rte_pktmbuf_reset(mbufs[idx]);
> + idx++;
> + case 2:
> + RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
> + rte_mbuf_refcnt_set(mbufs[idx], 1);
> + rte_pktmbuf_reset(mbufs[idx]);
> + idx++;
> + case 1:
> + RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
> + rte_mbuf_refcnt_set(mbufs[idx], 1);
> + rte_pktmbuf_reset(mbufs[idx]);
> + idx++;
> + }
> + }
> + return 0;
> +}
> +
> +/**
> * Attach packet mbuf to another packet mbuf.
> *
> * After attachment we refer the mbuf we attached as 'indirect',
> diff --git a/lib/librte_mbuf/rte_mbuf_version.map b/lib/librte_mbuf/rte_mbuf_version.map
> index e10f6bd..257c65a 100644
> --- a/lib/librte_mbuf/rte_mbuf_version.map
> +++ b/lib/librte_mbuf/rte_mbuf_version.map
> @@ -18,3 +18,10 @@ DPDK_2.1 {
> rte_pktmbuf_pool_create;
>
> } DPDK_2.0;
> +
> +DPDK_2.3 {
> + global:
> +
> + rte_pktmbuf_alloc_bulk;
> +
> +} DPDK_2.1;
>
Since rte_pktmbuf_alloc_bulk() is an inline function, it is not part of
the library ABI and should not be listed in the version map.
I assume its inline for performance reasons, but then you lose the
benefits of dynamic linking such as ability to fix bugs and/or improve
itby just updating the library. Since the point of having a bulk API is
to improve performance by reducing the number of calls required, does it
really have to be inline? As in, have you actually measured the
difference between inline and non-inline and decided its worth all the
downsides?
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH V1 1/1] jobstats: added function abort for job
2016-01-27 13:37 3% ` Panu Matilainen
@ 2016-01-27 15:57 0% ` Jastrzebski, MichalX K
2016-01-28 7:41 3% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Jastrzebski, MichalX K @ 2016-01-27 15:57 UTC (permalink / raw)
To: Panu Matilainen, Kerlin, MarcinX, dev
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
> Sent: Wednesday, January 27, 2016 2:38 PM
> To: Kerlin, MarcinX <marcinx.kerlin@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH V1 1/1] jobstats: added function abort for job
>
> On 01/26/2016 06:15 PM, Marcin Kerlin wrote:
> > This patch adds new function rte_jobstats_abort. It marks *job* as finished
> > and time of this work will be add to management time instead of execution
> time.
> > This function should be used instead of rte_jobstats_finish if condition
> occure,
> > condition is defined by the application for example when receiving n>0
> packets.
> >
> > Signed-off-by: Marcin Kerlin <marcinx.kerlin@intel.com>
> > ---
> > lib/librte_jobstats/rte_jobstats.c | 22 ++++++++++++++++++++++
> > lib/librte_jobstats/rte_jobstats.h | 17 +++++++++++++++++
> > lib/librte_jobstats/rte_jobstats_version.map | 7 +++++++
> > 3 files changed, 46 insertions(+)
> >
> [...]
> > diff --git a/lib/librte_jobstats/rte_jobstats.h
> b/lib/librte_jobstats/rte_jobstats.h
> > index de6a89a..9995319 100644
> > --- a/lib/librte_jobstats/rte_jobstats.h
> > +++ b/lib/librte_jobstats/rte_jobstats.h
> > @@ -90,6 +90,9 @@ struct rte_jobstats {
> > uint64_t exec_cnt;
> > /**< Execute count. */
> >
> > + uint64_t last_job_time;
> > + /**< Last job time */
> > +
> > char name[RTE_JOBSTATS_NAMESIZE];
> > /**< Name of this job */
> >
>
> AFAICS this is an ABI break and as such, needs to be preannounced, see
> http://dpdk.org/doc/guides/contributing/versioning.html
> For 2.3 it'd need to be a CONFIG_RTE_NEXT_ABI feature.
>
> - Panu -
Hi Panu,
Thanks for Your notice. This last_job_time field is actually not necessary here
and will be removed from this structure.
Best regards
Michal
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH 2/3] rte_ctrl_if: add control interface library
[not found] <1453911849-16562-1-git-send-email-ferruh.yigit@intel.com>
@ 2016-01-27 16:24 1% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2016-01-27 16:24 UTC (permalink / raw)
To: dev
This library gets control messages form kernelspace and forwards them to
librte_ether and returns response back to the kernelspace.
Library does:
1) Trigger Linux virtual interface creation
2) Initialize the netlink socket communication
3) Provides process() API to the application that does processing the
received messages
This library requires corresponding kernel module to be inserted.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
config/common_linuxapp | 3 +-
doc/api/doxy-api-index.md | 3 +-
doc/api/doxy-api.conf | 1 +
doc/guides/rel_notes/release_2_3.rst | 9 +
lib/Makefile | 3 +-
lib/librte_ctrl_if/Makefile | 58 +++++
lib/librte_ctrl_if/rte_ctrl_if.c | 162 +++++++++++++
lib/librte_ctrl_if/rte_ctrl_if.h | 115 ++++++++++
lib/librte_ctrl_if/rte_ctrl_if_version.map | 9 +
lib/librte_ctrl_if/rte_ethtool.c | 354 +++++++++++++++++++++++++++++
lib/librte_ctrl_if/rte_ethtool.h | 54 +++++
lib/librte_ctrl_if/rte_nl.c | 259 +++++++++++++++++++++
lib/librte_ctrl_if/rte_nl.h | 60 +++++
lib/librte_eal/common/include/rte_log.h | 3 +-
mk/rte.app.mk | 3 +-
15 files changed, 1091 insertions(+), 5 deletions(-)
create mode 100644 lib/librte_ctrl_if/Makefile
create mode 100644 lib/librte_ctrl_if/rte_ctrl_if.c
create mode 100644 lib/librte_ctrl_if/rte_ctrl_if.h
create mode 100644 lib/librte_ctrl_if/rte_ctrl_if_version.map
create mode 100644 lib/librte_ctrl_if/rte_ethtool.c
create mode 100644 lib/librte_ctrl_if/rte_ethtool.h
create mode 100644 lib/librte_ctrl_if/rte_nl.c
create mode 100644 lib/librte_ctrl_if/rte_nl.h
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 5d5e3e4..f72ba0e 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
@@ -507,6 +507,7 @@ CONFIG_RTE_KNI_VHOST_DEBUG_TX=n
#
CONFIG_RTE_KCP_KMOD=y
CONFIG_RTE_KCP_KO_DEBUG=n
+CONFIG_RTE_LIBRTE_CTRL_IF=y
#
# Compile vhost library
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 7a91001..214d16e 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -149,4 +149,5 @@ There are many libraries, so their headers may be grouped by topics:
[common] (@ref rte_common.h),
[ABI compat] (@ref rte_compat.h),
[keepalive] (@ref rte_keepalive.h),
- [version] (@ref rte_version.h)
+ [version] (@ref rte_version.h),
+ [control interface] (@ref rte_ctrl_if.h)
diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
index 57e8b5d..fd69bf1 100644
--- a/doc/api/doxy-api.conf
+++ b/doc/api/doxy-api.conf
@@ -39,6 +39,7 @@ INPUT = doc/api/doxy-api-index.md \
lib/librte_cmdline \
lib/librte_compat \
lib/librte_cryptodev \
+ lib/librte_ctrl_if \
lib/librte_distributor \
lib/librte_ether \
lib/librte_hash \
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..39725e4 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -4,6 +4,14 @@ DPDK Release 2.3
New Features
------------
+* **Control interface support added.**
+
+ To enable controlling DPDK ports by common Linux tools.
+ Following modules added to DPDK:
+
+ * librte_ctrl_if library
+ * librte_eal/linuxapp/kcp kernel module
+
Resolved Issues
---------------
@@ -51,6 +59,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_acl.so.2
librte_cfgfile.so.2
librte_cmdline.so.1
+ + librte_ctrl_if.so.1
librte_distributor.so.1
librte_eal.so.2
librte_hash.so.2
diff --git a/lib/Makefile b/lib/Makefile
index ef172ea..a50bc1e 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
@@ -58,6 +58,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PORT) += librte_port
DIRS-$(CONFIG_RTE_LIBRTE_TABLE) += librte_table
DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += librte_pipeline
DIRS-$(CONFIG_RTE_LIBRTE_REORDER) += librte_reorder
+DIRS-$(CONFIG_RTE_LIBRTE_CTRL_IF) += librte_ctrl_if
ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
diff --git a/lib/librte_ctrl_if/Makefile b/lib/librte_ctrl_if/Makefile
new file mode 100644
index 0000000..4e82966
--- /dev/null
+++ b/lib/librte_ctrl_if/Makefile
@@ -0,0 +1,58 @@
+# BSD LICENSE
+#
+# Copyright(c) 2016 Intel Corporation. All rights reserved.
+# 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.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_ctrl_if.a
+
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+
+EXPORT_MAP := rte_ctrl_if_version.map
+
+LIBABIVER := 1
+
+SRCS-y += rte_ctrl_if.c
+SRCS-y += rte_nl.c
+SRCS-y += rte_ethtool.c
+
+#
+# Export include files
+#
+SYMLINK-y-include += rte_ctrl_if.h
+
+# this lib depends upon:
+DEPDIRS-y += lib/librte_ether
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_ctrl_if/rte_ctrl_if.c b/lib/librte_ctrl_if/rte_ctrl_if.c
new file mode 100644
index 0000000..a84eea0
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ctrl_if.c
@@ -0,0 +1,162 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation. All rights reserved.
+ * 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.
+ */
+
+#include <fcntl.h>
+#include <unistd.h>
+
+#include <sys/ioctl.h>
+
+#include <rte_ethdev.h>
+#include "rte_ctrl_if.h"
+#include "rte_nl.h"
+
+static int kcp_fd = -1;
+static int kcp_fd_ref;
+
+static int
+control_interface_init(void)
+{
+ int ret;
+ kcp_fd = open("/dev/" KCP_DEVICE, O_RDWR);
+
+ if (kcp_fd < 0) {
+ RTE_LOG(ERR, CTRL_IF,
+ "Failed to initialize control interface.\n");
+ return -1;
+ }
+
+ ret = control_interface_nl_init();
+ if (ret < 0)
+ close(kcp_fd);
+
+ return ret;
+}
+
+static int
+control_interface_ref_get(void)
+{
+ int ret = 0;
+
+ if (kcp_fd_ref == 0)
+ ret = control_interface_init();
+
+ if (ret == 0)
+ kcp_fd_ref++;
+
+ return kcp_fd_ref;
+}
+
+static void
+control_interface_release(void)
+{
+ close(kcp_fd);
+ control_interface_nl_release();
+}
+
+static int
+control_interface_ref_put(void)
+{
+ if (kcp_fd_ref == 0)
+ return 0;
+
+ kcp_fd_ref--;
+
+ if (kcp_fd_ref == 0)
+ control_interface_release();
+
+ return kcp_fd_ref;
+}
+
+static int
+rte_eth_control_interface_create_one(uint8_t port_id)
+{
+ if (control_interface_ref_get() != 0) {
+ ioctl(kcp_fd, RTE_KCP_IOCTL_CREATE, port_id);
+ RTE_LOG(DEBUG, CTRL_IF,
+ "Control interface created for port:%u\n",
+ port_id);
+ }
+
+ return 0;
+}
+
+int
+rte_eth_control_interface_create(void)
+{
+ int i;
+ int ret = 0;
+
+ for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
+ if (rte_eth_dev_is_valid_port(i)) {
+ ret = rte_eth_control_interface_create_one(i);
+ if (ret < 0)
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
+static int
+rte_eth_control_interface_destroy_one(uint8_t port_id)
+{
+ ioctl(kcp_fd, RTE_KCP_IOCTL_RELEASE, port_id);
+ control_interface_ref_put();
+ RTE_LOG(DEBUG, CTRL_IF, "Control interface destroyed for port:%u\n",
+ port_id);
+
+ return 0;
+}
+
+int
+rte_eth_control_interface_destroy(void)
+{
+ int i;
+ int ret = 0;
+
+ for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
+ if (rte_eth_dev_is_valid_port(i)) {
+ ret = rte_eth_control_interface_destroy_one(i);
+ if (ret < 0)
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
+int
+rte_eth_control_interface_process_msg(int flag, unsigned int timeout_sec)
+{
+ return control_interface_process_msg(flag, timeout_sec);
+}
diff --git a/lib/librte_ctrl_if/rte_ctrl_if.h b/lib/librte_ctrl_if/rte_ctrl_if.h
new file mode 100644
index 0000000..dcaf6dd
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ctrl_if.h
@@ -0,0 +1,115 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation. All rights reserved.
+ * 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_CTRL_IF_H_
+#define _RTE_CTRL_IF_H_
+
+/**
+ * @file
+ *
+ * Control Interface Library for RTE
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <exec-env/rte_kcp_common.h>
+
+/**
+ * Flags values for rte_eth_control_interface_process_msg() API
+ */
+enum control_interface_process_flag {
+ /**< Process if msg available. */
+ RTE_ETHTOOL_CTRL_IF_PROCESS_MSG,
+
+ /**< Discard msg if available, respond with a error value. */
+ RTE_ETHTOOL_CTRL_IF_DISCARD_MSG,
+};
+
+/**
+ * Creates control interfaces (Linux virtual network interface)for
+ * each existing eal port.
+ *
+ * This API opens device created by supportive kernel module and initializes
+ * kernel communication interface.
+ *
+ * If supportive kernel module is not inserted this API will return
+ * an error.
+ *
+ * @return
+ * 0 on success.
+ * Negative value on error.
+ */
+int rte_eth_control_interface_create(void);
+
+/**
+ * Destroys control interfaces.
+ *
+ * This API close device created by supportive kernel module and release
+ * underlying communication interface.
+ *
+ * @return
+ * 0 on success.
+ * Negative value on error.
+ */
+int rte_eth_control_interface_destroy(void);
+
+/**
+ * Process if any received message is available.
+ *
+ * This function can be blocking or unblocking according timeout_sec
+ * parameter value. If function will be continuous loop, like can be
+ * called by any forwarding lcore, nonblocking mode should be preferred.
+ * If a separate thread created to handle control messages, blocking
+ * mode can be preferred to save CPU cycles.
+ *
+ * @param flag
+ * Defines what to do with message, can be process or discard.
+ *
+ * @param timeout_sec
+ * if 0, function is in nonblocking mode.
+ * if > 0, blocks for given time, if there is no message available,
+ * sleeps again same amount of time. Value is in seconds.
+ *
+ * @return
+ * 0 on success.
+ * Negative value on error.
+ */
+int rte_eth_control_interface_process_msg(int flag, unsigned int timeout_sec);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_CTRL_IF_H_ */
diff --git a/lib/librte_ctrl_if/rte_ctrl_if_version.map b/lib/librte_ctrl_if/rte_ctrl_if_version.map
new file mode 100644
index 0000000..8b27e26
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ctrl_if_version.map
@@ -0,0 +1,9 @@
+DPDK_2.3 {
+ global:
+
+ rte_eth_control_interface_create;
+ rte_eth_control_interface_destroy;
+ rte_eth_control_interface_process_msg;
+
+ local: *;
+};
diff --git a/lib/librte_ctrl_if/rte_ethtool.c b/lib/librte_ctrl_if/rte_ethtool.c
new file mode 100644
index 0000000..1caeab4
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ethtool.c
@@ -0,0 +1,354 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation. All rights reserved.
+ * 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.
+ */
+
+#include <stdio.h>
+
+#include <linux/if_link.h>
+
+#include <rte_version.h>
+#include <rte_ethdev.h>
+#include "rte_ethtool.h"
+
+#define ETHTOOL_GEEPROM_LEN 99
+#define ETHTOOL_GREGS_LEN 98
+#define ETHTOOL_GSSET_COUNT 97
+
+static int
+get_drvinfo(int port_id, void *data, int *data_len)
+{
+ struct ethtool_drvinfo *info = data;
+ struct rte_eth_dev_info dev_info;
+ int n;
+
+ memset(&dev_info, 0, sizeof(dev_info));
+ rte_eth_dev_info_get(port_id, &dev_info);
+
+ snprintf(info->driver, sizeof(info->driver), "%s",
+ dev_info.driver_name);
+ snprintf(info->version, sizeof(info->version), "%s",
+ rte_version());
+ snprintf(info->bus_info, sizeof(info->bus_info),
+ "%04x:%02x:%02x.%x",
+ dev_info.pci_dev->addr.domain, dev_info.pci_dev->addr.bus,
+ dev_info.pci_dev->addr.devid, dev_info.pci_dev->addr.function);
+
+ n = rte_eth_dev_get_reg_length(port_id);
+ info->regdump_len = n < 0 ? 0 : n;
+
+ n = rte_eth_dev_get_eeprom_length(port_id);
+ info->eedump_len = n < 0 ? 0 : n;
+
+ info->n_stats = sizeof(struct rte_eth_stats) / sizeof(uint64_t);
+ info->testinfo_len = 0;
+
+ *data_len = sizeof(struct ethtool_drvinfo);
+
+ return 0;
+}
+
+static int
+get_reg_len(int port_id, void *data, int *data_len)
+{
+ int reg_length = 0;
+
+ reg_length = rte_eth_dev_get_reg_length(port_id);
+ if (reg_length < 0)
+ return reg_length;
+
+ *(int *)data = reg_length * sizeof(uint32_t);
+ *data_len = sizeof(int);
+
+ return 0;
+}
+
+static int
+get_reg(int port_id, void *in_data, void *out_data, int *out_data_len)
+{
+ unsigned int reg_length;
+ int reg_length_out_len;
+ struct ethtool_regs *ethtool_regs = in_data;
+ struct rte_dev_reg_info regs = {
+ .data = out_data,
+ .length = 0,
+ };
+ int ret;
+
+ ret = get_reg_len(port_id, ®_length, ®_length_out_len);
+ if (ret < 0 || reg_length > ethtool_regs->len)
+ return -1;
+
+ ret = rte_eth_dev_get_reg_info(port_id, ®s);
+ if (ret < 0)
+ return ret;
+
+ ethtool_regs->version = regs.version;
+ *out_data_len = reg_length;
+
+ return 0;
+}
+
+static int
+get_link(int port_id, void *data, int *data_len)
+{
+ struct rte_eth_link link;
+
+ rte_eth_link_get(port_id, &link);
+
+ *(int *)data = link.link_status;
+ *data_len = sizeof(int);
+
+ return 0;
+}
+
+static int
+get_eeprom_length(int port_id, void *data, int *data_len)
+{
+ int eeprom_length = 0;
+
+ eeprom_length = rte_eth_dev_get_eeprom_length(port_id);
+ if (eeprom_length < 0)
+ return eeprom_length;
+
+ *(int *)data = eeprom_length;
+ *data_len = sizeof(int);
+
+ return 0;
+}
+
+static int
+get_eeprom(int port_id, void *in_data, void *out_data)
+{
+ struct ethtool_eeprom *eeprom = in_data;
+ struct rte_dev_eeprom_info eeprom_info = {
+ .data = out_data,
+ .offset = eeprom->offset,
+ .length = eeprom->len,
+ };
+ int ret;
+
+ ret = rte_eth_dev_get_eeprom(port_id, &eeprom_info);
+ if (ret < 0)
+ return ret;
+
+ eeprom->magic = eeprom_info.magic;
+
+ return 0;
+}
+
+static int
+set_eeprom(int port_id, void *in_data, void *out_data)
+{
+ struct ethtool_eeprom *eeprom = in_data;
+ struct rte_dev_eeprom_info eeprom_info = {
+ .data = out_data,
+ .offset = eeprom->offset,
+ .length = eeprom->len,
+ };
+ int ret;
+
+ ret = rte_eth_dev_set_eeprom(port_id, &eeprom_info);
+ if (ret < 0)
+ return ret;
+
+ eeprom->magic = eeprom_info.magic;
+
+ return 0;
+}
+
+static int
+get_pauseparam(int port_id, void *data, void *data_len)
+{
+ struct ethtool_pauseparam *pauseparam = data;
+ struct rte_eth_fc_conf fc_conf;
+ int ret;
+
+ ret = rte_eth_dev_flow_ctrl_get(port_id, &fc_conf);
+ if (ret)
+ return ret;
+
+ pauseparam->tx_pause = 0;
+ pauseparam->rx_pause = 0;
+
+ switch (fc_conf.mode) {
+ case RTE_FC_RX_PAUSE:
+ pauseparam->rx_pause = 1;
+ break;
+ case RTE_FC_TX_PAUSE:
+ pauseparam->tx_pause = 1;
+ break;
+ case RTE_FC_FULL:
+ pauseparam->rx_pause = 1;
+ pauseparam->tx_pause = 1;
+ default:
+ break;
+ }
+ pauseparam->autoneg = (uint32_t)fc_conf.autoneg;
+
+ *(int *)data_len = sizeof(struct ethtool_pauseparam);
+
+ return 0;
+}
+
+int
+rte_eth_dev_ethtool_process(int cmd_id, int port_id, void *in_data,
+ void *out_data, int *out_data_len)
+{
+ int ret = 0;
+
+ if (!rte_eth_dev_is_valid_port(port_id))
+ return -ENODEV;
+
+ switch (cmd_id) {
+ case ETHTOOL_GDRVINFO:
+ return get_drvinfo(port_id, out_data, out_data_len);
+ case ETHTOOL_GREGS_LEN:
+ return get_reg_len(port_id, out_data, out_data_len);
+ case ETHTOOL_GREGS:
+ return get_reg(port_id, in_data, out_data, out_data_len);
+ case ETHTOOL_GLINK:
+ return get_link(port_id, out_data, out_data_len);
+ case ETHTOOL_GEEPROM_LEN:
+ return get_eeprom_length(port_id, out_data, out_data_len);
+ case ETHTOOL_GEEPROM:
+ return get_eeprom(port_id, in_data, out_data);
+ case ETHTOOL_SEEPROM:
+ return set_eeprom(port_id, in_data, out_data);
+ case ETHTOOL_GPAUSEPARAM:
+ return get_pauseparam(port_id, out_data, out_data_len);
+ default:
+ ret = -95 /* EOPNOTSUPP */;
+ break;
+ }
+
+ return ret;
+}
+
+static int
+set_mtu(int port_id, void *in_data)
+{
+ int *mtu = in_data;
+
+ return rte_eth_dev_set_mtu(port_id, *mtu);
+}
+
+static int
+get_stats(int port_id, void *data, int *data_len)
+{
+ struct rte_eth_stats stats;
+ struct rtnl_link_stats64 *if_stats = data;
+ int ret;
+
+ ret = rte_eth_stats_get(port_id, &stats);
+ if (ret < 0)
+ return -EOPNOTSUPP;
+
+ if_stats->rx_packets = stats.ipackets;
+ if_stats->tx_packets = stats.opackets;
+ if_stats->rx_bytes = stats.ibytes;
+ if_stats->tx_bytes = stats.obytes;
+ if_stats->rx_errors = stats.ierrors;
+ if_stats->tx_errors = stats.oerrors;
+ if_stats->rx_dropped = stats.imissed;
+ if_stats->multicast = stats.imcasts;
+
+ *data_len = sizeof(struct rtnl_link_stats64);
+
+ return 0;
+}
+
+static int
+get_mac(int port_id, void *data, int *data_len)
+{
+ struct ether_addr addr;
+
+ rte_eth_macaddr_get(port_id, &addr);
+ memcpy(data, &addr, sizeof(struct ether_addr));
+
+ *data_len = sizeof(struct ether_addr);
+
+ return 0;
+}
+
+static int
+set_mac(int port_id, void *in_data)
+{
+ struct ether_addr addr;
+
+ memcpy(&addr, in_data, ETHER_ADDR_LEN);
+
+ return rte_eth_dev_default_mac_addr_set(port_id, &addr);
+}
+
+static int
+start_port(int port_id)
+{
+ rte_eth_dev_stop(port_id);
+ return rte_eth_dev_start(port_id);
+}
+
+static int
+stop_port(int port_id)
+{
+ rte_eth_dev_stop(port_id);
+ return 0;
+}
+
+int
+rte_eth_dev_control_process(int cmd_id, int port_id, void *in_data,
+ void *out_data, int *out_data_len)
+{
+ int ret = 0;
+
+ if (!rte_eth_dev_is_valid_port(port_id))
+ return -ENODEV;
+
+ switch (cmd_id) {
+ case RTE_KCP_REQ_CHANGE_MTU:
+ return set_mtu(port_id, in_data);
+ case RTE_KCP_REQ_GET_STATS:
+ return get_stats(port_id, out_data, out_data_len);
+ case RTE_KCP_REQ_GET_MAC:
+ return get_mac(port_id, out_data, out_data_len);
+ case RTE_KCP_REQ_SET_MAC:
+ return set_mac(port_id, in_data);
+ case RTE_KCP_REQ_START_PORT:
+ return start_port(port_id);
+ case RTE_KCP_REQ_STOP_PORT:
+ return stop_port(port_id);
+ default:
+ ret = -95 /* EOPNOTSUPP */;
+ break;
+ }
+
+ return ret;
+}
diff --git a/lib/librte_ctrl_if/rte_ethtool.h b/lib/librte_ctrl_if/rte_ethtool.h
new file mode 100644
index 0000000..19f364f
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ethtool.h
@@ -0,0 +1,54 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation. All rights reserved.
+ * 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_ETHTOOL_H_
+#define _RTE_ETHTOOL_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <linux/ethtool.h>
+
+#include <exec-env/rte_kcp_common.h>
+
+int rte_eth_dev_ethtool_process(int cmd_id, int port_id, void *in_data,
+ void *out_data, int *out_data_len);
+int rte_eth_dev_control_process(int cmd_id, int port_id, void *in_data,
+ void *out_data, int *out_data_len);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_ETHTOOL_H_ */
diff --git a/lib/librte_ctrl_if/rte_nl.c b/lib/librte_ctrl_if/rte_nl.c
new file mode 100644
index 0000000..33f1319
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_nl.c
@@ -0,0 +1,259 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation. All rights reserved.
+ * 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.
+ */
+
+#include <unistd.h>
+
+#include <sys/socket.h>
+#include <linux/netlink.h>
+
+#include <rte_spinlock.h>
+#include <rte_ethdev.h>
+#include "rte_ethtool.h"
+#include "rte_nl.h"
+#include "rte_ctrl_if.h"
+
+#define KCP_NL_GRP 31
+#define MAX_PAYLOAD 1024
+
+struct ctrl_if_nl {
+ struct nlmsghdr *nlh;
+ struct msghdr msg;
+ struct iovec iov;
+};
+
+static int sock_fd = -1;
+pthread_t thread_id;
+pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
+pthread_mutex_t msg_lock = PTHREAD_MUTEX_INITIALIZER;
+static uint8_t nlmsg[NLMSG_SPACE(MAX_PAYLOAD) * 2];
+static struct sockaddr_nl dest_addr;
+static struct sockaddr_nl src_addr;
+
+static struct ctrl_if_nl nl_s = {
+ .nlh = (struct nlmsghdr *)nlmsg,
+};
+
+static struct ctrl_if_nl nl_r = {
+ .nlh = (struct nlmsghdr *)(nlmsg + NLMSG_SPACE(MAX_PAYLOAD)),
+};
+
+static int kcp_ethtool_msg_count;
+static struct kcp_ethtool_msg msg_storage;
+
+static void
+control_interface_nl_send(void *buf, size_t len)
+{
+ int ret;
+
+ /* Fill in the netlink message payload */
+ memcpy(NLMSG_DATA(nl_s.nlh), buf, len);
+
+ ret = sendmsg(sock_fd, &nl_s.msg, 0);
+
+ if (ret < 0)
+ RTE_LOG(ERR, CTRL_IF, "Failed nl msg send. ret:%d, err:%d\n",
+ ret, errno);
+}
+
+static void
+control_interface_nl_process_msg(struct kcp_ethtool_msg *msg)
+{
+ if (msg->cmd_id > RTE_KCP_REQ_UNKNOWN) {
+ msg->err = rte_eth_dev_control_process(msg->cmd_id,
+ msg->port_id, msg->input_buffer,
+ msg->output_buffer, &msg->output_buffer_len);
+ } else {
+ msg->err = rte_eth_dev_ethtool_process(msg->cmd_id,
+ msg->port_id, msg->input_buffer,
+ msg->output_buffer, &msg->output_buffer_len);
+ }
+
+ control_interface_nl_send((void *)msg,
+ sizeof(struct kcp_ethtool_msg));
+}
+
+int
+control_interface_process_msg(int flag, unsigned int timeout_sec)
+{
+ int ret = 0;
+ struct timespec ts;
+
+ pthread_mutex_lock(&msg_lock);
+
+ clock_gettime(CLOCK_REALTIME, &ts);
+ ts.tv_sec += timeout_sec;
+ while (timeout_sec && !kcp_ethtool_msg_count && !ret)
+ ret = pthread_cond_timedwait(&cond, &msg_lock, &ts);
+
+ switch (flag) {
+ case RTE_ETHTOOL_CTRL_IF_PROCESS_MSG:
+ if (kcp_ethtool_msg_count) {
+ control_interface_nl_process_msg(&msg_storage);
+ kcp_ethtool_msg_count = 0;
+ }
+ ret = 0;
+ break;
+
+ case RTE_ETHTOOL_CTRL_IF_DISCARD_MSG:
+ if (kcp_ethtool_msg_count) {
+ msg_storage.err = -1;
+ control_interface_nl_send((void *)&msg_storage,
+ sizeof(struct kcp_ethtool_msg));
+ kcp_ethtool_msg_count = 0;
+ }
+ ret = 0;
+ break;
+
+ default:
+ ret = -1;
+ break;
+ }
+ pthread_mutex_unlock(&msg_lock);
+
+ return ret;
+}
+
+static int
+msg_add_and_signal(struct nlmsghdr *nlh)
+{
+ pthread_mutex_lock(&msg_lock);
+
+ memcpy(&msg_storage, NLMSG_DATA(nlh), sizeof(struct kcp_ethtool_msg));
+ kcp_ethtool_msg_count = 1;
+
+ pthread_cond_signal(&cond);
+
+ pthread_mutex_unlock(&msg_lock);
+
+ return 0;
+}
+
+static void *
+control_interface_nl_recv(void *arg)
+{
+ int ret;
+
+ for (;;) {
+ ret = recvmsg(sock_fd, &nl_r.msg, 0);
+ if (ret < 0)
+ continue;
+
+ if ((unsigned)ret < sizeof(struct kcp_ethtool_msg)) {
+ RTE_LOG(WARNING, CTRL_IF,
+ "Received %u bytes, payload %lu\n",
+ ret, sizeof(struct kcp_ethtool_msg));
+ continue;
+ }
+
+ msg_add_and_signal(nl_r.nlh);
+ }
+
+ return arg;
+}
+
+static void
+nl_setup_header(struct ctrl_if_nl *nl, struct sockaddr_nl *daddr)
+{
+ memset(nl->nlh, 0, NLMSG_SPACE(MAX_PAYLOAD));
+
+ /* Fill the netlink message header */
+ nl->nlh->nlmsg_len = NLMSG_SPACE(MAX_PAYLOAD);
+ nl->nlh->nlmsg_pid = getpid(); /* self pid */
+ nl->nlh->nlmsg_flags = 0;
+
+ nl->iov.iov_base = (void *)nl->nlh;
+ nl->iov.iov_len = nl->nlh->nlmsg_len;
+ memset(&nl->msg, 0, sizeof(struct msghdr));
+ nl->msg.msg_name = (void *)daddr;
+ nl->msg.msg_namelen = sizeof(struct sockaddr_nl);
+ nl->msg.msg_iov = &nl->iov;
+ nl->msg.msg_iovlen = 1;
+}
+
+static int
+control_interface_nl_socket_init(void)
+{
+ int fd;
+ int ret;
+
+ fd = socket(PF_NETLINK, SOCK_RAW, KCP_NL_GRP);
+ if (fd < 0)
+ return -1;
+
+ src_addr.nl_family = AF_NETLINK;
+ src_addr.nl_pid = getpid();
+ ret = bind(fd, (struct sockaddr *)&src_addr, sizeof(src_addr));
+ if (ret) {
+ close(fd);
+ return -1;
+ }
+
+ dest_addr.nl_family = AF_NETLINK;
+ dest_addr.nl_pid = 0; /* For Linux Kernel */
+ dest_addr.nl_groups = 0;
+
+ nl_setup_header(&nl_s, &dest_addr);
+ nl_setup_header(&nl_r, &dest_addr);
+
+ return fd;
+}
+
+int
+control_interface_nl_init(void)
+{
+ int ret;
+ char buf[] = "pid";
+ sock_fd = control_interface_nl_socket_init();
+
+ if (sock_fd < 0) {
+ RTE_LOG(ERR, CTRL_IF,
+ "Failed to initialize control interface.\n");
+ return -1;
+ }
+
+ ret = pthread_create(&thread_id, NULL, control_interface_nl_recv,
+ NULL);
+ if (ret != 0)
+ return -1;
+ control_interface_nl_send((void *)buf, sizeof(buf));
+
+ return 0;
+}
+
+void
+control_interface_nl_release(void)
+{
+ pthread_cancel(thread_id);
+ pthread_join(thread_id, NULL);
+ close(sock_fd);
+}
diff --git a/lib/librte_ctrl_if/rte_nl.h b/lib/librte_ctrl_if/rte_nl.h
new file mode 100644
index 0000000..e422bf9
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_nl.h
@@ -0,0 +1,60 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation. All rights reserved.
+ * 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_NL_H_
+#define _RTE_NL_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define KCP_ETHTOOL_MSG_LEN 500
+struct kcp_ethtool_msg {
+ int cmd_id;
+ int port_id;
+ char input_buffer[KCP_ETHTOOL_MSG_LEN];
+ char output_buffer[KCP_ETHTOOL_MSG_LEN];
+ int input_buffer_len;
+ int output_buffer_len;
+ int err;
+};
+
+int control_interface_nl_init(void);
+void control_interface_nl_release(void);
+int control_interface_process_msg(int flag, unsigned int timeout_sec);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_NL_H_ */
diff --git a/lib/librte_eal/common/include/rte_log.h b/lib/librte_eal/common/include/rte_log.h
index 2e47e7f..a0a2c9f 100644
--- a/lib/librte_eal/common/include/rte_log.h
+++ b/lib/librte_eal/common/include/rte_log.h
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -79,6 +79,7 @@ extern struct rte_logs rte_logs;
#define RTE_LOGTYPE_PIPELINE 0x00008000 /**< Log related to pipeline. */
#define RTE_LOGTYPE_MBUF 0x00010000 /**< Log related to mbuf. */
#define RTE_LOGTYPE_CRYPTODEV 0x00020000 /**< Log related to cryptodev. */
+#define RTE_LOGTYPE_CTRL_IF 0x00040000 /**< Log related to control interface. */
/* these log types can be used in an application */
#define RTE_LOGTYPE_USER1 0x01000000 /**< User-defined log type 1. */
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 8ecab41..e1638f0 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
# Copyright(c) 2014-2015 6WIND S.A.
# All rights reserved.
#
@@ -122,6 +122,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_MBUF) += -lrte_mbuf
_LDLIBS-$(CONFIG_RTE_LIBRTE_MBUF_OFFLOAD) += -lrte_mbuf_offload
_LDLIBS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += -lrte_ip_frag
_LDLIBS-$(CONFIG_RTE_LIBRTE_ETHER) += -lethdev
+_LDLIBS-$(CONFIG_RTE_LIBRTE_CTRL_IF) += -lrte_ctrl_if
_LDLIBS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += -lrte_cryptodev
_LDLIBS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += -lrte_mempool
_LDLIBS-$(CONFIG_RTE_LIBRTE_RING) += -lrte_ring
--
2.5.0
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH] ethdev: fix byte order inconsistence between fdir flow and mask
2016-01-27 9:19 0% ` Thomas Monjalon
@ 2016-01-28 5:55 0% ` Wu, Jingjing
0 siblings, 0 replies; 200+ results
From: Wu, Jingjing @ 2016-01-28 5:55 UTC (permalink / raw)
To: Thomas Monjalon, Mcnamara, John; +Cc: dev
>
> 2016-01-27 16:37, Jingjing Wu:
> > Fixed issue of byte order in ethdev library that the structure for
> > setting fdir's mask and flow entry is inconsist and made inputs of
> > mask be in big endian.
>
> Please be more precise. Which one is big endian?
> Wasn't it tested before?
>
It is tested, it works. But byte order fields in the structures for fdir are not
consist, few are in host endian. It will make user confused, so this patch
is to make all fields in the same byte order.
> > fixes: 76c6f89e80d4 ("ixgbe: support new flow director masks")
> > 2d4c1a9ea2ac ("ethdev: add new flow director masks")
>
> Please put Fixes: on the two lines.
>
OK. Will add in later version.
> > --- a/doc/guides/rel_notes/release_2_3.rst
> > +++ b/doc/guides/rel_notes/release_2_3.rst
> > @@ -19,6 +19,10 @@ Drivers
> > Libraries
> > ~~~~~~~~~
> >
> > +* ** fix byte order inconsistence between fdir flow and mask **
> > +
> > + Fixed issue in ethdev library that the structure for setting
> > + fdir's mask and flow entry is inconsist in byte order.
>
> John, comment on release notes formatting?
> It's important to have the first items well formatted.
>
> > @@ -39,6 +43,8 @@ API Changes
> > ABI Changes
> > -----------
> >
> > +* The fields in The ethdev structures ``rte_eth_fdir_masks`` were
> > + changed to be in big endian.
>
> Please take care of uppercase typo here.
Ok. Thanks for point.
>
> > - /* write all the same so that UDP, TCP and SCTP use the same mask
> */
> > + /* write all the same so that UDP, TCP and SCTP use the same mask
> > + * (little-endian)
> > + */
>
> Spacing typo here.
> Sorry for the nits ;)
>
Will fix this in later version.
> > - uint8_t mac_addr_byte_mask; /** Per byte MAC address mask */
> > + uint8_t mac_addr_byte_mask; /** Bit mask for associated byte */
> > uint32_t tunnel_id_mask; /** tunnel ID mask */
> > - uint8_t tunnel_type_mask;
> > + uint8_t tunnel_type_mask; /**< 1 - Match tunnel type,
> > + 0 - Ignore tunnel type. */
>
> These changes seem unrelated with the patch.
> It's good to improve doc of this API but it's maybe not enough.
> Example:
> uint8_t mac_addr_byte_mask; /** Bit mask for associated byte */
> Are we sure everybody understand how to fill it?
OK. Will improve this.
Thanks
JIngjing
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH V1 1/1] jobstats: added function abort for job
2016-01-27 15:57 0% ` Jastrzebski, MichalX K
@ 2016-01-28 7:41 3% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2016-01-28 7:41 UTC (permalink / raw)
To: Jastrzebski, MichalX K, Kerlin, MarcinX, dev
On 01/27/2016 05:57 PM, Jastrzebski, MichalX K wrote:
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
>> Sent: Wednesday, January 27, 2016 2:38 PM
>> To: Kerlin, MarcinX <marcinx.kerlin@intel.com>; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH V1 1/1] jobstats: added function abort for job
>>
>> On 01/26/2016 06:15 PM, Marcin Kerlin wrote:
>>> This patch adds new function rte_jobstats_abort. It marks *job* as finished
>>> and time of this work will be add to management time instead of execution
>> time.
>>> This function should be used instead of rte_jobstats_finish if condition
>> occure,
>>> condition is defined by the application for example when receiving n>0
>> packets.
>>>
>>> Signed-off-by: Marcin Kerlin <marcinx.kerlin@intel.com>
>>> ---
>>> lib/librte_jobstats/rte_jobstats.c | 22 ++++++++++++++++++++++
>>> lib/librte_jobstats/rte_jobstats.h | 17 +++++++++++++++++
>>> lib/librte_jobstats/rte_jobstats_version.map | 7 +++++++
>>> 3 files changed, 46 insertions(+)
>>>
>> [...]
>>> diff --git a/lib/librte_jobstats/rte_jobstats.h
>> b/lib/librte_jobstats/rte_jobstats.h
>>> index de6a89a..9995319 100644
>>> --- a/lib/librte_jobstats/rte_jobstats.h
>>> +++ b/lib/librte_jobstats/rte_jobstats.h
>>> @@ -90,6 +90,9 @@ struct rte_jobstats {
>>> uint64_t exec_cnt;
>>> /**< Execute count. */
>>>
>>> + uint64_t last_job_time;
>>> + /**< Last job time */
>>> +
>>> char name[RTE_JOBSTATS_NAMESIZE];
>>> /**< Name of this job */
>>>
>>
>> AFAICS this is an ABI break and as such, needs to be preannounced, see
>> http://dpdk.org/doc/guides/contributing/versioning.html
>> For 2.3 it'd need to be a CONFIG_RTE_NEXT_ABI feature.
>>
>> - Panu -
>
> Hi Panu,
> Thanks for Your notice. This last_job_time field is actually not necessary here
> and will be removed from this structure.
Right, makes sense. You can always add it later on when there's a more
pressing need to break the ABI.
- Panu -
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 1/3] i40e: add setting VF MAC address in DPDK PF host
2016-01-28 8:40 4% [dpdk-dev] [PATCH 0/3] support setting i40e VF MAC address from DPDK host side Helin Zhang
@ 2016-01-28 8:40 4% ` Helin Zhang
0 siblings, 0 replies; 200+ results
From: Helin Zhang @ 2016-01-28 8:40 UTC (permalink / raw)
To: dev
It adds pre-setting the VF MAC addresses from DPDK PF host
side before any VF being initialized, by introducing a new
element of 'struct rte_vf_conf' in 'struct rte_eth_conf'.
It supports up to 128 VFs per physical port of setting VF
MAC addresses.
Signed-off-by: Helin Zhang <helin.zhang@intel.com>
---
doc/guides/rel_notes/release_2_3.rst | 9 +++++++++
drivers/net/i40e/i40e_ethdev.c | 21 +++++++++++++++++++++
drivers/net/i40e/i40e_ethdev.h | 1 +
drivers/net/i40e/i40e_pf.c | 2 ++
lib/librte_ether/rte_ethdev.h | 10 ++++++++++
5 files changed, 43 insertions(+)
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..8ba3594 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -4,6 +4,11 @@ DPDK Release 2.3
New Features
------------
+* **Added setting default MAC address for i40e VF.**
+
+ Added setting default MAC address for i40e VF before in PF host
+ driver, by providing those MAC addresses in PF port configuration.
+
Resolved Issues
---------------
@@ -39,6 +44,10 @@ API Changes
ABI Changes
-----------
+* The ethdev structure of ``rte_eth_dev``, ``rte_eth_dev_data`` and
+ ``rte_eth_conf`` were changed to support setting default MAC address
+ for i40e VF, by DPDK PF host.
+
Shared Library Versions
-----------------------
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bf6220d..f7cec39 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1020,6 +1020,7 @@ i40e_dev_configure(struct rte_eth_dev *dev)
I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
enum rte_eth_rx_mq_mode mq_mode = dev->data->dev_conf.rxmode.mq_mode;
+ struct ether_addr *p_mac_addr;
int i, ret;
/* Initialize to TRUE. If any of Rx queues doesn't meet the
@@ -1074,6 +1075,26 @@ i40e_dev_configure(struct rte_eth_dev *dev)
}
}
+ /* Store the configured VF MAC address */
+ for (i = 0; i < RTE_MIN(pf->vf_num, ETH_VF_NUM_MAX); i++) {
+ p_mac_addr = &(dev->data->dev_conf.vf_conf[i].mac_addr);
+ if (is_valid_assigned_ether_addr(p_mac_addr)) {
+ ether_addr_copy(p_mac_addr, &(pf->vfs[i].mac_addr));
+ PMD_DRV_LOG(INFO, "MAC address "
+ "%02x:%02x:%02x:%02x:%02x:%02x will be "
+ "used as default address of VF[%d]",
+ p_mac_addr->addr_bytes[0],
+ p_mac_addr->addr_bytes[1],
+ p_mac_addr->addr_bytes[2],
+ p_mac_addr->addr_bytes[3],
+ p_mac_addr->addr_bytes[4],
+ p_mac_addr->addr_bytes[5], i);
+ } else {
+ PMD_DRV_LOG(WARNING, "Invalid MAC address configured "
+ "for VF[%d], use zero instead", i);
+ }
+ }
+
return 0;
err_dcb:
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 1f9792b..66aad4d 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -312,6 +312,7 @@ struct i40e_pf_vf {
uint16_t vf_idx; /* VF index in pf->vfs */
uint16_t lan_nb_qps; /* Actual queues allocated */
uint16_t reset_cnt; /* Total vf reset times */
+ struct ether_addr mac_addr; /* Default MAC address */
};
/*
diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c
index cbf4e5b..be7cbf7 100644
--- a/drivers/net/i40e/i40e_pf.c
+++ b/drivers/net/i40e/i40e_pf.c
@@ -315,6 +315,8 @@ i40e_pf_host_process_cmd_get_vf_resource(struct i40e_pf_vf *vf)
/* As assume Vf only has single VSI now, always return 0 */
vf_res->vsi_res[0].vsi_id = 0;
vf_res->vsi_res[0].num_queue_pairs = vf->vsi->nb_qps;
+ ether_addr_copy(&vf->mac_addr,
+ (struct ether_addr *)vf_res->vsi_res[0].default_mac_addr);
send_msg:
i40e_pf_host_send_msg_to_vf(vf, I40E_VIRTCHNL_OP_GET_VF_RESOURCES,
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index bada8ad..88f1d9b 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -754,6 +754,15 @@ struct rte_intr_conf {
uint16_t rxq;
};
+#define ETH_VF_NUM_MAX 128 /* Maximum number of Virtual Functions supported */
+
+/**
+ * A structure to define VF configurations to be used in PF host driver.
+ */
+struct rte_vf_conf {
+ struct ether_addr mac_addr; /* Pre-configured VF MAC address. */
+};
+
/**
* A structure used to configure an Ethernet port.
* Depending upon the RX multi-queue mode, extra advanced
@@ -793,6 +802,7 @@ struct rte_eth_conf {
uint32_t dcb_capability_en;
struct rte_fdir_conf fdir_conf; /**< FDIR configuration. */
struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */
+ struct rte_vf_conf vf_conf[ETH_VF_NUM_MAX]; /**< VF configuration. */
};
/**
--
2.5.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 0/3] support setting i40e VF MAC address from DPDK host side
@ 2016-01-28 8:40 4% Helin Zhang
2016-01-28 8:40 4% ` [dpdk-dev] [PATCH 1/3] i40e: add setting VF MAC address in DPDK PF host Helin Zhang
0 siblings, 1 reply; 200+ results
From: Helin Zhang @ 2016-01-28 8:40 UTC (permalink / raw)
To: dev
It adds pre-setting i40e VF MAC addresses from DPDK PF host side,
during host port initialization, by introduing a new port
configuration element. It then can pre-set VF MAC addresses
before any launching VFs, and the VF MAC addresses will not be
random each time launching a VF.
There should be no ABI broken, as ABI changes
in 'struct rte_eth_conf' has already been announced in R2.2.
Helin Zhang (3):
i40e: add setting VF MAC address in DPDK PF host
i40evf: use ether interface for validating MAC address
app/testpmd: set default MAC addresses for each VF
app/test-pmd/testpmd.c | 19 +++++++++++++++++++
doc/guides/rel_notes/release_2_3.rst | 9 +++++++++
drivers/net/i40e/i40e_ethdev.c | 21 +++++++++++++++++++++
drivers/net/i40e/i40e_ethdev.h | 1 +
drivers/net/i40e/i40e_ethdev_vf.c | 14 +++++++-------
drivers/net/i40e/i40e_pf.c | 2 ++
lib/librte_ether/rte_ethdev.h | 10 ++++++++++
7 files changed, 69 insertions(+), 7 deletions(-)
--
2.5.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 1/4] lib/ether: optimize the 'rte_eth_tunnel_filter_conf' structure
@ 2016-01-28 9:05 3% ` Sun, Xutao
0 siblings, 0 replies; 200+ results
From: Sun, Xutao @ 2016-01-28 9:05 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
Hi, Thomas
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, January 28, 2016 4:22 PM
> To: Sun, Xutao <xutao.sun@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 1/4] lib/ether: optimize the
> 'rte_eth_tunnel_filter_conf' structure
>
> 2016-01-28 15:30, Xutao Sun:
> > Change the fields of outer_mac and inner_mac from pointer to struct in
> order to keep the code's readability.
>
> [...]
> > - tunnel_filter_conf.outer_mac = &res->outer_mac;
> > - tunnel_filter_conf.inner_mac = &res->inner_mac;
> > + (void)rte_memcpy(&tunnel_filter_conf.outer_mac, &res-
> >outer_mac,
> > + ETHER_ADDR_LEN);
> > + (void)rte_memcpy(&tunnel_filter_conf.inner_mac, &res-
> >inner_mac,
> > + ETHER_ADDR_LEN);
>
> The (void) casting is useless here.
>
> > --- a/lib/librte_ether/rte_eth_ctrl.h
> > +++ b/lib/librte_ether/rte_eth_ctrl.h
> > @@ -280,8 +280,8 @@ enum rte_tunnel_iptype {
> > * Tunneling Packet filter configuration.
> > */
> > struct rte_eth_tunnel_filter_conf {
> > - struct ether_addr *outer_mac; /**< Outer MAC address filter. */
> > - struct ether_addr *inner_mac; /**< Inner MAC address filter. */
> > + struct ether_addr outer_mac; /**< Outer MAC address filter. */
> > + struct ether_addr inner_mac; /**< Inner MAC address filter. */
>
> It is an API change.
> Please remove the deprecation notice and update the release notes in this
> patch (atomically).
I will remove the deprecation notice and update the release notes.
Is it an ABI change instead of an API change?
Thanks,
Xutao
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3 1/4] lib/ether: optimize the'rte_eth_tunnel_filter_conf' structure
[not found] ` <1453976778-27807-1-git-send-email-xutao.sun@intel.com>
@ 2016-01-28 10:26 13% ` Xutao Sun
0 siblings, 0 replies; 200+ results
From: Xutao Sun @ 2016-01-28 10:26 UTC (permalink / raw)
To: dev
Change the fields of outer_mac and inner_mac from pointer to struct in order to keep the code's readability.
Signed-off-by: Xutao Sun <xutao.sun@intel.com>
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
---
app/test-pmd/cmdline.c | 6 ++++--
doc/guides/rel_notes/deprecation.rst | 5 -----
doc/guides/rel_notes/release_2_3.rst | 2 ++
drivers/net/i40e/i40e_ethdev.c | 12 ++++++------
lib/librte_ether/rte_eth_ctrl.h | 4 ++--
5 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 6d28c1b..67df259 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6640,8 +6640,10 @@ cmd_tunnel_filter_parsed(void *parsed_result,
struct rte_eth_tunnel_filter_conf tunnel_filter_conf;
int ret = 0;
- tunnel_filter_conf.outer_mac = &res->outer_mac;
- tunnel_filter_conf.inner_mac = &res->inner_mac;
+ rte_memcpy(&tunnel_filter_conf.outer_mac, &res->outer_mac,
+ ETHER_ADDR_LEN);
+ rte_memcpy(&tunnel_filter_conf.inner_mac, &res->inner_mac,
+ ETHER_ADDR_LEN);
tunnel_filter_conf.inner_vlan = res->inner_vlan;
if (res->ip_value.family == AF_INET) {
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..a895364 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -32,11 +32,6 @@ Deprecation Notices
RTE_ETH_FLOW_MAX. The release 2.2 does not contain these ABI changes,
but release 2.3 will.
-* ABI changes are planned for rte_eth_tunnel_filter_conf. Change the fields
- of outer_mac and inner_mac from pointer to struct in order to keep the
- code's readability. The release 2.2 does not contain these ABI changes, but
- release 2.3 will, and no backwards compatibility is planned.
-
* The scheduler statistics structure will change to allow keeping track of
RED actions.
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..ee7fd48 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,8 @@ API Changes
ABI Changes
-----------
+* The fields of outer_mac and inner_mac were changed from pointer
+ to struct in order to keep the code's readability.
Shared Library Versions
-----------------------
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bf6220d..1dd1077 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -5828,10 +5828,10 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
}
pfilter = cld_filter;
- (void)rte_memcpy(&pfilter->outer_mac, tunnel_filter->outer_mac,
- sizeof(struct ether_addr));
- (void)rte_memcpy(&pfilter->inner_mac, tunnel_filter->inner_mac,
- sizeof(struct ether_addr));
+ (void)rte_memcpy(&pfilter->outer_mac, &tunnel_filter->outer_mac,
+ ETHER_ADDR_LEN);
+ (void)rte_memcpy(&pfilter->inner_mac, &tunnel_filter->inner_mac,
+ ETHER_ADDR_LEN);
pfilter->inner_vlan = tunnel_filter->inner_vlan;
if (tunnel_filter->ip_type == RTE_TUNNEL_IPTYPE_IPV4) {
@@ -6131,13 +6131,13 @@ i40e_tunnel_filter_param_check(struct i40e_pf *pf,
}
if ((filter->filter_type & ETH_TUNNEL_FILTER_OMAC) &&
- (is_zero_ether_addr(filter->outer_mac))) {
+ (is_zero_ether_addr(&filter->outer_mac))) {
PMD_DRV_LOG(ERR, "Cannot add NULL outer MAC address");
return -EINVAL;
}
if ((filter->filter_type & ETH_TUNNEL_FILTER_IMAC) &&
- (is_zero_ether_addr(filter->inner_mac))) {
+ (is_zero_ether_addr(&filter->inner_mac))) {
PMD_DRV_LOG(ERR, "Cannot add NULL inner MAC address");
return -EINVAL;
}
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index ce224ad..30cbde7 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -280,8 +280,8 @@ enum rte_tunnel_iptype {
* Tunneling Packet filter configuration.
*/
struct rte_eth_tunnel_filter_conf {
- struct ether_addr *outer_mac; /**< Outer MAC address filter. */
- struct ether_addr *inner_mac; /**< Inner MAC address filter. */
+ struct ether_addr outer_mac; /**< Outer MAC address filter. */
+ struct ether_addr inner_mac; /**< Inner MAC address filter. */
uint16_t inner_vlan; /**< Inner VLAN filter. */
enum rte_tunnel_iptype ip_type; /**< IP address type. */
union {
--
1.9.3
^ permalink raw reply [relevance 13%]
* Re: [dpdk-dev] [PATCH 1/4] lib/librte_port: add PCAP file support to source port
@ 2016-01-28 11:54 4% ` Panu Matilainen
2016-01-29 15:10 4% ` Zhang, Roy Fan
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-28 11:54 UTC (permalink / raw)
To: Fan Zhang, dev
On 01/27/2016 07:39 PM, Fan Zhang wrote:
> Originally, source ports in librte_port is an input port used as packet
> generator. Similar to Linux kernel /dev/zero character device, it
> generates null packets. This patch adds optional PCAP file support to
> source port: instead of sending NULL packets, the source port generates
> packets copied from a PCAP file. To increase the performance, the packets
> in the file are loaded to memory initially, and copied to mbufs in circular
> manner. Users can enable or disable this feature by setting
> CONFIG_RTE_PORT_PCAP compiler option "y" or "n".
>
> Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> ---
> config/common_bsdapp | 1 +
> config/common_linuxapp | 1 +
> lib/librte_port/Makefile | 4 +
> lib/librte_port/rte_port_source_sink.c | 190 +++++++++++++++++++++++++++++++++
> lib/librte_port/rte_port_source_sink.h | 7 ++
> mk/rte.app.mk | 1 +
> 6 files changed, 204 insertions(+)
>
[...]
> +#ifdef RTE_PORT_PCAP
> +
> +/**
> + * Load PCAP file, allocate and copy packets in the file to memory
> + *
> + * @param p
> + * Parameters for source port
> + * @param port
> + * Handle to source port
> + * @param socket_id
> + * Socket id where the memory is created
> + * @return
> + * 0 on SUCCESS
> + * error code otherwise
> + */
> +static int
> +pcap_source_load(struct rte_port_source_params *p,
> + struct rte_port_source *port,
> + int socket_id)
> +{
[...]
> +#else
> +static int
> +pcap_source_load(__rte_unused struct rte_port_source_params *p,
> + struct rte_port_source *port,
> + __rte_unused int socket_id)
> +{
> + port->pkt_buff = NULL;
> + port->pkt_len = NULL;
> + port->pkts = NULL;
> + port->pkt_index = 0;
> +
> + return 0;
> +}
> +#endif
Same as in patch 3/4, shouldn't this return -ENOTSUP when pcap support
is not built in, instead of success?
[...]
> diff --git a/lib/librte_port/rte_port_source_sink.h b/lib/librte_port/rte_port_source_sink.h
> index 0f9be79..6f39bec 100644
> --- a/lib/librte_port/rte_port_source_sink.h
> +++ b/lib/librte_port/rte_port_source_sink.h
> @@ -53,6 +53,13 @@ extern "C" {
> struct rte_port_source_params {
> /** Pre-initialized buffer pool */
> struct rte_mempool *mempool;
> + /** The full path of the pcap file to read packets from */
> + char *file_name;
> + /** The number of bytes to be read from each packet in the
> + * pcap file. If this value is 0, the whole packet is read;
> + * if it is bigger than packet size, the generated packets
> + * will contain the whole packet */
> + uint32_t n_bytes_per_pkt;
> };
This is a likely ABI-break. It "only" appends to the struct, which might
in some cases be okay but only when there's no sensible use for the
struct within arrays or embedded in structs. The ip_pipeline example for
example embeds struct rte_port_source_params within another struct which
is could be thought of as an indication that other applications might be
doing this as well.
An ABI break for librte_port has not been announced for 2.3 so you'd
need to announce the intent to do so in 2.4 now, and then either wait
till post 2.3 or wrap this in CONFIG_RTE_NEXT_ABI.
- Panu -
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [RFC] ABI breakage for rte_mempool to reduce footprint
@ 2016-01-28 19:02 7% Wiles, Keith
0 siblings, 0 replies; 200+ results
From: Wiles, Keith @ 2016-01-28 19:02 UTC (permalink / raw)
To: dev
Hi Everyone,
Currently every mempool created has a footprint of 1.5Megs of memory just for the struct rte_mempool, this also includes all of the rte_pktmbuf creates as well. The issue is the local_cache adds about 1.5Megs of memory, which is a huge amount IMHO for non-cached based mempools. Without the local_cache the structure is about 192bytes. You can set the config option for the cache to ’n’, but then all allocations will not use the per core cache. I have some code I will send as a patch to have the local_cache allocated only when a mempool is created and the caller has a non-zero cache size set in the call.
This will break ABI for the struct rte_mempool, but does remove some of the ifdefs for RTE_MEMPOOL_CACHE_SIZE in the code. The performance appears to be the same, but will do some more testing before I submit the patch.
Please let me know if this would be reasonable or other comments.
Regards,
Keith
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [RFC] Abi breakage for rte_mempool to reduce footprint
@ 2016-01-28 20:07 7% Wiles, Keith
0 siblings, 0 replies; 200+ results
From: Wiles, Keith @ 2016-01-28 20:07 UTC (permalink / raw)
To: dev
Hi Everyone,
Currently every mempool created has a footprint of 1.5Megs of memory just for the struct rte_mempool, this also includes all of the rte_pktmbuf creates as well. The issue is the local_cache adds about 1.5Megs of memory, which is a huge amount IMHO for non-cached based mempools. Without the local_cache the structure is about 192bytes. You can set the config option for the cache to ’n’, but then all allocations will not use the per core cache. I have some code I will send as a patch to have the local_cache allocated only when a mempool is created and the caller has a non-zero cache size set in the call.
This will break ABI for the struct rte_mempool, but does remove some of the ifdefs for RTE_MEMPOOL_CACHE_SIZE in the code. The performance appears to be the same, but will do some more testing before I submit the patch.
Please let me know if this would be reasonable or other comments.
Regards,
Keith
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
2016-01-13 12:22 3% ` Panu Matilainen
@ 2016-01-28 21:38 4% ` Thomas Monjalon
2016-01-29 9:21 4% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2016-01-28 21:38 UTC (permalink / raw)
To: Panu Matilainen, Stephen Hemminger; +Cc: dev, Ziye Yang
2016-01-13 14:22, Panu Matilainen:
> On 01/13/2016 01:55 PM, Bruce Richardson wrote:
> > On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
> >> On Tue, 29 Dec 2015 10:53:26 +0800
> >> Ziye Yang <ziye.yang@intel.com> wrote:
> >>
> >>> This patch is used to add the class_id support
> >>> for pci_probe since some devices need the class_info
> >>> (class_code, subclass_code, programming_interface)
> >>>
> >>> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
> >>
> >> Since rte_pci is exposed to application this breaks the ABI.
> >
> > But applications are not going to be defining rte_pci_ids values internally, are
> > they? That is for drivers to use. Is this really an ABI breakage for applications that we
> > need to be concerned about?
>
> There might not be applications using it but drivers are ABI consumers
> too - think of 3rd party drivers and such.
Drivers are not ABI consumers in the sense that ABI means
Application Binary Interface.
We are talking about drivers interface here.
When establishing the ABI policy we were discussing about applications only.
I agree we must allow 3rd party drivers but there is no good reason
to try to upgrade DPDK without upgrading/porting the external drivers.
If someone does not want to release its driver and keep upgrading DPDK,
it is acceptable IMHO to force an upgrade of its driver.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v7 4/5] doc: update with link changes
@ 2016-01-29 0:42 8% ` Marc Sune
0 siblings, 0 replies; 200+ results
From: Marc Sune @ 2016-01-29 0:42 UTC (permalink / raw)
To: dev, Wenzhuo Lu, Helin Zhang, Harish Patil, Jing Chen
Add new features, ABI changes and resolved issues notice for
the refactored link patch.
Signed-off-by: Marc Sune <marcdevel@gmail.com>
---
doc/guides/rel_notes/release_2_3.rst | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..b10c3bb 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -4,10 +4,28 @@ DPDK Release 2.3
New Features
------------
+* **ethdev: define a set of advertised link speeds.**
+
+ Allowing to define a set of advertised speeds for auto-negociation,
+ explicitely disable link auto-negociation (single speed) and full
+ auto-negociation.
+
+* **ethdev: add speed_cap bitmap to recover eth device link speed capabilities
+ define a set of advertised link speeds.**
+
+ ``struct rte_eth_dev_info`` has now speed_cap bitmap, which allows the
+ application to recover the supported speeds for that ethernet device.
+
Resolved Issues
---------------
+* **ethdev: Fixed link_speed overflow in rte_eth_link for 100Gbps.**
+
+ 100Gbps in Mbps (100000) exceeds 16 bit max value of ``link_speed`` in
+ ``rte_eth_link``.
+
+
EAL
~~~
@@ -23,6 +41,9 @@ Libraries
Examples
~~~~~~~~
+* New API call, rte_eth_speed_to_bm_flag(), in ethdev to map numerical speeds
+ to bitmap fields.
+
Other
~~~~~
@@ -39,6 +60,11 @@ API Changes
ABI Changes
-----------
+* The ethdev rte_eth_link and rte_eth_conf structures were changed to
+ support the new link API, as well as ETH_LINK_HALF/FULL_DUPLEX.
+
+* The ethdev rte_eth_dev_info was changed to support device speed capabilities.
+
Shared Library Versions
-----------------------
--
2.1.4
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
2016-01-28 21:38 4% ` Thomas Monjalon
@ 2016-01-29 9:21 4% ` Panu Matilainen
2016-01-29 9:34 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-29 9:21 UTC (permalink / raw)
To: Thomas Monjalon, Stephen Hemminger; +Cc: dev, Ziye Yang
On 01/28/2016 11:38 PM, Thomas Monjalon wrote:
> 2016-01-13 14:22, Panu Matilainen:
>> On 01/13/2016 01:55 PM, Bruce Richardson wrote:
>>> On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
>>>> On Tue, 29 Dec 2015 10:53:26 +0800
>>>> Ziye Yang <ziye.yang@intel.com> wrote:
>>>>
>>>>> This patch is used to add the class_id support
>>>>> for pci_probe since some devices need the class_info
>>>>> (class_code, subclass_code, programming_interface)
>>>>>
>>>>> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
>>>>
>>>> Since rte_pci is exposed to application this breaks the ABI.
>>>
>>> But applications are not going to be defining rte_pci_ids values internally, are
>>> they? That is for drivers to use. Is this really an ABI breakage for applications that we
>>> need to be concerned about?
>>
>> There might not be applications using it but drivers are ABI consumers
>> too - think of 3rd party drivers and such.
>
> Drivers are not ABI consumers in the sense that ABI means
> Application Binary Interface.
> We are talking about drivers interface here.
> When establishing the ABI policy we were discussing about applications only.
Generally speaking an ABI is an interface between two program (or
software if you like) modules, its not specific to "applications".
Looking at http://dpdk.org/doc/guides/contributing/versioning.html I see
it does only talk about applications, but an ABI consumer can also be
another library. A driver calling rte_malloc() is just as much
librte_eal ABI consumer as anything else.
Now, I understand that drivers use and need interface(s) that
applications have no use for or simply cannot use, and those interfaces
could be subject to different policies. As an extreme example, the Linux
kernel has two isolated ABIs, one is the userland system call interface
which is guaranteed to stay forever and the other is kernel module
interface, guarantees nothing at all.
In DPDK the difference is far muddier than that since all the interfaces
live in common, versioned userland DSOs. So if there are two different
interfaces following two different policies, it's all the more important
to clearly document them. One simple way could be using a different
prefix than rte_.
> I agree we must allow 3rd party drivers but there is no good reason
> to try to upgrade DPDK without upgrading/porting the external drivers.
> If someone does not want to release its driver and keep upgrading DPDK,
> it is acceptable IMHO to force an upgrade of its driver.
Note that I've no particular sympathy for 3rd party drivers as such.
What I *do* care about is that breakage is made explicit, as in drivers
built for an incompatible version refuse to load at all, instead of
silently corrupting memory etc.
- Panu -
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
2016-01-29 9:21 4% ` Panu Matilainen
@ 2016-01-29 9:34 3% ` Thomas Monjalon
2016-01-29 10:10 3% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2016-01-29 9:34 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Ziye Yang
2016-01-29 11:21, Panu Matilainen:
> On 01/28/2016 11:38 PM, Thomas Monjalon wrote:
> > 2016-01-13 14:22, Panu Matilainen:
> >> On 01/13/2016 01:55 PM, Bruce Richardson wrote:
> >>> On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
> >>>> On Tue, 29 Dec 2015 10:53:26 +0800
> >>>> Ziye Yang <ziye.yang@intel.com> wrote:
> >>>>
> >>>>> This patch is used to add the class_id support
> >>>>> for pci_probe since some devices need the class_info
> >>>>> (class_code, subclass_code, programming_interface)
> >>>>>
> >>>>> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
> >>>>
> >>>> Since rte_pci is exposed to application this breaks the ABI.
> >>>
> >>> But applications are not going to be defining rte_pci_ids values internally, are
> >>> they? That is for drivers to use. Is this really an ABI breakage for applications that we
> >>> need to be concerned about?
> >>
> >> There might not be applications using it but drivers are ABI consumers
> >> too - think of 3rd party drivers and such.
> >
> > Drivers are not ABI consumers in the sense that ABI means
> > Application Binary Interface.
> > We are talking about drivers interface here.
> > When establishing the ABI policy we were discussing about applications only.
>
> Generally speaking an ABI is an interface between two program (or
> software if you like) modules, its not specific to "applications".
> Looking at http://dpdk.org/doc/guides/contributing/versioning.html I see
> it does only talk about applications, but an ABI consumer can also be
> another library. A driver calling rte_malloc() is just as much
> librte_eal ABI consumer as anything else.
>
> Now, I understand that drivers use and need interface(s) that
> applications have no use for or simply cannot use, and those interfaces
> could be subject to different policies. As an extreme example, the Linux
> kernel has two isolated ABIs, one is the userland system call interface
> which is guaranteed to stay forever and the other is kernel module
> interface, guarantees nothing at all.
>
> In DPDK the difference is far muddier than that since all the interfaces
> live in common, versioned userland DSOs. So if there are two different
> interfaces following two different policies, it's all the more important
> to clearly document them. One simple way could be using a different
> prefix than rte_.
Good suggestion. Or we can simply have different files with a clear notice
in their headers and in the versioning doc.
It was well split in rte_cryptodev_pmd.h
> > I agree we must allow 3rd party drivers but there is no good reason
> > to try to upgrade DPDK without upgrading/porting the external drivers.
> > If someone does not want to release its driver and keep upgrading DPDK,
> > it is acceptable IMHO to force an upgrade of its driver.
>
> Note that I've no particular sympathy for 3rd party drivers as such.
> What I *do* care about is that breakage is made explicit, as in drivers
> built for an incompatible version refuse to load at all, instead of
> silently corrupting memory etc.
OK I agree.
Anyway the ABI versionning does not cover the structure changes.
What about making a DPDK version check when registering a driver?
So a binary driver would be clearly bound to a DPDK version.
And we should change or remove the .so version which never change for
most of drivers.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
2016-01-29 9:34 3% ` Thomas Monjalon
@ 2016-01-29 10:10 3% ` Panu Matilainen
2016-01-29 12:47 0% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-29 10:10 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Ziye Yang
On 01/29/2016 11:34 AM, Thomas Monjalon wrote:
> 2016-01-29 11:21, Panu Matilainen:
>> On 01/28/2016 11:38 PM, Thomas Monjalon wrote:
>>> 2016-01-13 14:22, Panu Matilainen:
>>>> On 01/13/2016 01:55 PM, Bruce Richardson wrote:
>>>>> On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
>>>>>> On Tue, 29 Dec 2015 10:53:26 +0800
>>>>>> Ziye Yang <ziye.yang@intel.com> wrote:
>>>>>>
>>>>>>> This patch is used to add the class_id support
>>>>>>> for pci_probe since some devices need the class_info
>>>>>>> (class_code, subclass_code, programming_interface)
>>>>>>>
>>>>>>> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
>>>>>>
>>>>>> Since rte_pci is exposed to application this breaks the ABI.
>>>>>
>>>>> But applications are not going to be defining rte_pci_ids values internally, are
>>>>> they? That is for drivers to use. Is this really an ABI breakage for applications that we
>>>>> need to be concerned about?
>>>>
>>>> There might not be applications using it but drivers are ABI consumers
>>>> too - think of 3rd party drivers and such.
>>>
>>> Drivers are not ABI consumers in the sense that ABI means
>>> Application Binary Interface.
>>> We are talking about drivers interface here.
>>> When establishing the ABI policy we were discussing about applications only.
>>
>> Generally speaking an ABI is an interface between two program (or
>> software if you like) modules, its not specific to "applications".
>> Looking at http://dpdk.org/doc/guides/contributing/versioning.html I see
>> it does only talk about applications, but an ABI consumer can also be
>> another library. A driver calling rte_malloc() is just as much
>> librte_eal ABI consumer as anything else.
>>
>> Now, I understand that drivers use and need interface(s) that
>> applications have no use for or simply cannot use, and those interfaces
>> could be subject to different policies. As an extreme example, the Linux
>> kernel has two isolated ABIs, one is the userland system call interface
>> which is guaranteed to stay forever and the other is kernel module
>> interface, guarantees nothing at all.
>>
>> In DPDK the difference is far muddier than that since all the interfaces
>> live in common, versioned userland DSOs. So if there are two different
>> interfaces following two different policies, it's all the more important
>> to clearly document them. One simple way could be using a different
>> prefix than rte_.
>
> Good suggestion. Or we can simply have different files with a clear notice
> in their headers and in the versioning doc.
> It was well split in rte_cryptodev_pmd.h
Using separate headers is also good. Optimally both? :)
>>> I agree we must allow 3rd party drivers but there is no good reason
>>> to try to upgrade DPDK without upgrading/porting the external drivers.
>>> If someone does not want to release its driver and keep upgrading DPDK,
>>> it is acceptable IMHO to force an upgrade of its driver.
>>
>> Note that I've no particular sympathy for 3rd party drivers as such.
>> What I *do* care about is that breakage is made explicit, as in drivers
>> built for an incompatible version refuse to load at all, instead of
>> silently corrupting memory etc.
>
> OK I agree.
Cool, the rest is just details then.
> Anyway the ABI versionning does not cover the structure changes.
> What about making a DPDK version check when registering a driver?
> So a binary driver would be clearly bound to a DPDK version.
That's one possibility. Another way to achieve essentially the same is
to make rte_eal_driver_register() symbol version follow the DPDK
version, in which case a driver built for another version will fail at
dlopen() already.
> And we should change or remove the .so version which never change for
> most of drivers.
Yup, so-versioning DSOs which do not offer any ABI is kinda pointless.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
2016-01-29 10:10 3% ` Panu Matilainen
@ 2016-01-29 12:47 0% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2016-01-29 12:47 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Ziye Yang
On 01/29/2016 12:10 PM, Panu Matilainen wrote:
> On 01/29/2016 11:34 AM, Thomas Monjalon wrote:
>> 2016-01-29 11:21, Panu Matilainen:
>>> On 01/28/2016 11:38 PM, Thomas Monjalon wrote:
>>>> 2016-01-13 14:22, Panu Matilainen:
>>>>> On 01/13/2016 01:55 PM, Bruce Richardson wrote:
>>>>>> On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
>>>>>>> On Tue, 29 Dec 2015 10:53:26 +0800
>>>>>>> Ziye Yang <ziye.yang@intel.com> wrote:
>>>>>>>
>>>>>>>> This patch is used to add the class_id support
>>>>>>>> for pci_probe since some devices need the class_info
>>>>>>>> (class_code, subclass_code, programming_interface)
>>>>>>>>
>>>>>>>> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
>>>>>>>
>>>>>>> Since rte_pci is exposed to application this breaks the ABI.
>>>>>>
>>>>>> But applications are not going to be defining rte_pci_ids values
>>>>>> internally, are
>>>>>> they? That is for drivers to use. Is this really an ABI breakage
>>>>>> for applications that we
>>>>>> need to be concerned about?
>>>>>
>>>>> There might not be applications using it but drivers are ABI consumers
>>>>> too - think of 3rd party drivers and such.
>>>>
>>>> Drivers are not ABI consumers in the sense that ABI means
>>>> Application Binary Interface.
>>>> We are talking about drivers interface here.
>>>> When establishing the ABI policy we were discussing about
>>>> applications only.
>>>
>>> Generally speaking an ABI is an interface between two program (or
>>> software if you like) modules, its not specific to "applications".
>>> Looking at http://dpdk.org/doc/guides/contributing/versioning.html I see
>>> it does only talk about applications, but an ABI consumer can also be
>>> another library. A driver calling rte_malloc() is just as much
>>> librte_eal ABI consumer as anything else.
>>>
>>> Now, I understand that drivers use and need interface(s) that
>>> applications have no use for or simply cannot use, and those interfaces
>>> could be subject to different policies. As an extreme example, the Linux
>>> kernel has two isolated ABIs, one is the userland system call interface
>>> which is guaranteed to stay forever and the other is kernel module
>>> interface, guarantees nothing at all.
>>>
>>> In DPDK the difference is far muddier than that since all the interfaces
>>> live in common, versioned userland DSOs. So if there are two different
>>> interfaces following two different policies, it's all the more important
>>> to clearly document them. One simple way could be using a different
>>> prefix than rte_.
>>
>> Good suggestion. Or we can simply have different files with a clear
>> notice
>> in their headers and in the versioning doc.
>> It was well split in rte_cryptodev_pmd.h
>
> Using separate headers is also good. Optimally both? :)
>
>>>> I agree we must allow 3rd party drivers but there is no good reason
>>>> to try to upgrade DPDK without upgrading/porting the external drivers.
>>>> If someone does not want to release its driver and keep upgrading DPDK,
>>>> it is acceptable IMHO to force an upgrade of its driver.
>>>
>>> Note that I've no particular sympathy for 3rd party drivers as such.
>>> What I *do* care about is that breakage is made explicit, as in drivers
>>> built for an incompatible version refuse to load at all, instead of
>>> silently corrupting memory etc.
>>
>> OK I agree.
>
> Cool, the rest is just details then.
>
>> Anyway the ABI versionning does not cover the structure changes.
>> What about making a DPDK version check when registering a driver?
>> So a binary driver would be clearly bound to a DPDK version.
>
> That's one possibility. Another way to achieve essentially the same is
> to make rte_eal_driver_register() symbol version follow the DPDK
> version, in which case a driver built for another version will fail at
> dlopen() already.
Thinking about this a bit more, symbol versioning doesn't cut it because
its not always used (static linkakage) and I guess we should cover that too.
Another similar possibility that blocks it at dlopen() level is to munge
the actual function name to carry a version, so it becomes something
like rte_eal_driver_register_v230() and later _v240() etc. AFAICS its
only ever invoked via PMD_REGISTER_DRIVER() so the calling details can
conveniently be hidden there.
- Panu -
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/4] lib/librte_port: add PCAP file support to source port
2016-01-28 11:54 4% ` Panu Matilainen
@ 2016-01-29 15:10 4% ` Zhang, Roy Fan
0 siblings, 0 replies; 200+ results
From: Zhang, Roy Fan @ 2016-01-29 15:10 UTC (permalink / raw)
To: Panu Matilainen, dev
Hi Panu,
Thank you for the careful review and comments.
On 28/01/2016 11:54, Panu Matilainen wrote:
> On 01/27/2016 07:39 PM, Fan Zhang wrote:
>> Originally, source ports in librte_port is an input port used as packet
>> generator. Similar to Linux kernel /dev/zero character device, it
>> generates null packets. This patch adds optional PCAP file support to
>> source port: instead of sending NULL packets, the source port generates
>> packets copied from a PCAP file. To increase the performance, the
>> packets
>> in the file are loaded to memory initially, and copied to mbufs in
>> circular
>> manner. Users can enable or disable this feature by setting
>> CONFIG_RTE_PORT_PCAP compiler option "y" or "n".
>>
>> Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
>> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
>> ---
>> config/common_bsdapp | 1 +
>> config/common_linuxapp | 1 +
>> lib/librte_port/Makefile | 4 +
>> lib/librte_port/rte_port_source_sink.c | 190
>> +++++++++++++++++++++++++++++++++
>> lib/librte_port/rte_port_source_sink.h | 7 ++
>> mk/rte.app.mk | 1 +
>> 6 files changed, 204 insertions(+)
>>
> [...]
>> +#ifdef RTE_PORT_PCAP
>> +
>> +/**
>> + * Load PCAP file, allocate and copy packets in the file to memory
>> + *
>> + * @param p
>> + * Parameters for source port
>> + * @param port
>> + * Handle to source port
>> + * @param socket_id
>> + * Socket id where the memory is created
>> + * @return
>> + * 0 on SUCCESS
>> + * error code otherwise
>> + */
>> +static int
>> +pcap_source_load(struct rte_port_source_params *p,
>> + struct rte_port_source *port,
>> + int socket_id)
>> +{
> [...]
>> +#else
>> +static int
>> +pcap_source_load(__rte_unused struct rte_port_source_params *p,
>> + struct rte_port_source *port,
>> + __rte_unused int socket_id)
>> +{
>> + port->pkt_buff = NULL;
>> + port->pkt_len = NULL;
>> + port->pkts = NULL;
>> + port->pkt_index = 0;
>> +
>> + return 0;
>> +}
>> +#endif
>
> Same as in patch 3/4, shouldn't this return -ENOTSUP when pcap support
> is not built in, instead of success?
Thank you for the suggestion. I will make the change in V2.
> [...]
>
>> diff --git a/lib/librte_port/rte_port_source_sink.h
>> b/lib/librte_port/rte_port_source_sink.h
>> index 0f9be79..6f39bec 100644
>> --- a/lib/librte_port/rte_port_source_sink.h
>> +++ b/lib/librte_port/rte_port_source_sink.h
>> @@ -53,6 +53,13 @@ extern "C" {
>> struct rte_port_source_params {
>> /** Pre-initialized buffer pool */
>> struct rte_mempool *mempool;
>> + /** The full path of the pcap file to read packets from */
>> + char *file_name;
>> + /** The number of bytes to be read from each packet in the
>> + * pcap file. If this value is 0, the whole packet is read;
>> + * if it is bigger than packet size, the generated packets
>> + * will contain the whole packet */
>> + uint32_t n_bytes_per_pkt;
>> };
>
> This is a likely ABI-break. It "only" appends to the struct, which
> might in some cases be okay but only when there's no sensible use for
> the struct within arrays or embedded in structs. The ip_pipeline
> example for example embeds struct rte_port_source_params within
> another struct which is could be thought of as an indication that
> other applications might be doing this as well.
>
> An ABI break for librte_port has not been announced for 2.3 so you'd
> need to announce the intent to do so in 2.4 now, and then either wait
> till post 2.3 or wrap this in CONFIG_RTE_NEXT_ABI.
> - Panu -
Before Submitting the patch I have run validate-abi script, the
validation results showed "compatible" on all libraries.
Also, the patch's added line in the rte_port_source_sink.c was ensured
that, if the CONFIG_RTE_PORT_PCAP compiler option is set to "n" (by
default), the added read-only elements in the new rte_source_params
structure won't be touched.
CONFIG_RTE_PORT_PCAP compiler option lies in config/comm_bsdapp and
config/com_linuxapp, and is freshly added in this patch.
If an application is built on top of latest release version of
rte_port_source_sink library, it shall work fine with the new library if
the new CONFIG_RTE_PORT_PCAP opition is left the default "n".
ip_pipeline example works fine this way.
I hope this changes your mind on breaking the ABI.
Best regards,
Fan
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2] ethdev: fix byte order inconsistence between fdir flow and mask
2016-01-27 8:37 3% [dpdk-dev] [PATCH] ethdev: fix byte order inconsistence between fdir flow and mask Jingjing Wu
2016-01-27 9:19 0% ` Thomas Monjalon
@ 2016-02-01 2:48 3% ` Jingjing Wu
1 sibling, 0 replies; 200+ results
From: Jingjing Wu @ 2016-02-01 2:48 UTC (permalink / raw)
To: dev
Fixed issue of byte order in ethdev library that the structure
for setting fdir's mask and flow entry is inconsist and made
inputs of mask be in big endian.
Fixes: 76c6f89e80d4 ("ixgbe: support new flow director masks")
Fixes: 2d4c1a9ea2ac ("ethdev: add new flow director masks")
Reported-by: Yaacov Hazan <yaacovh@mellanox.com>
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
v2 changes:
fix typo and reword API doc.
app/test-pmd/cmdline.c | 6 ++---
doc/guides/rel_notes/release_2_3.rst | 6 +++++
drivers/net/ixgbe/ixgbe_fdir.c | 47 ++++++++++++++++++++++--------------
lib/librte_ether/rte_eth_ctrl.h | 17 ++++++++++---
4 files changed, 51 insertions(+), 25 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..13194c9 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -8687,13 +8687,13 @@ cmd_flow_director_mask_parsed(void *parsed_result,
return;
}
- mask->vlan_tci_mask = res->vlan_mask;
+ mask->vlan_tci_mask = rte_cpu_to_be_16(res->vlan_mask);
IPV4_ADDR_TO_UINT(res->ipv4_src, mask->ipv4_mask.src_ip);
IPV4_ADDR_TO_UINT(res->ipv4_dst, mask->ipv4_mask.dst_ip);
IPV6_ADDR_TO_ARRAY(res->ipv6_src, mask->ipv6_mask.src_ip);
IPV6_ADDR_TO_ARRAY(res->ipv6_dst, mask->ipv6_mask.dst_ip);
- mask->src_port_mask = res->port_src;
- mask->dst_port_mask = res->port_dst;
+ mask->src_port_mask = rte_cpu_to_be_16(res->port_src);
+ mask->dst_port_mask = rte_cpu_to_be_16(res->port_dst);
}
cmd_reconfig_device_queue(res->port_id, 1, 1);
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..77e4edd 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -19,6 +19,10 @@ Drivers
Libraries
~~~~~~~~~
+* ** fix byte order inconsistence between fdir flow and mask **
+
+ Fixed issue in ethdev library that the structure for setting
+ fdir's mask and flow entry is inconsist in byte order.
Examples
~~~~~~~~
@@ -39,6 +43,8 @@ API Changes
ABI Changes
-----------
+* The fields in ethdev structure ``rte_eth_fdir_masks`` were
+ changed to be in big endian.
Shared Library Versions
-----------------------
diff --git a/drivers/net/ixgbe/ixgbe_fdir.c b/drivers/net/ixgbe/ixgbe_fdir.c
index e03219b..2c874b1 100644
--- a/drivers/net/ixgbe/ixgbe_fdir.c
+++ b/drivers/net/ixgbe/ixgbe_fdir.c
@@ -309,6 +309,7 @@ fdir_set_input_mask_82599(struct rte_eth_dev *dev,
uint32_t fdiripv6m; /* IPv6 source and destination masks. */
uint16_t dst_ipv6m = 0;
uint16_t src_ipv6m = 0;
+ volatile uint32_t *reg;
PMD_INIT_FUNC_TRACE();
@@ -322,16 +323,16 @@ fdir_set_input_mask_82599(struct rte_eth_dev *dev,
/* use the L4 protocol mask for raw IPv4/IPv6 traffic */
fdirm |= IXGBE_FDIRM_L4P;
- if (input_mask->vlan_tci_mask == 0x0FFF)
+ if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0x0FFF))
/* mask VLAN Priority */
fdirm |= IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask == 0xE000)
+ else if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0xE000))
/* mask VLAN ID */
fdirm |= IXGBE_FDIRM_VLANID;
else if (input_mask->vlan_tci_mask == 0)
/* mask VLAN ID and Priority */
fdirm |= IXGBE_FDIRM_VLANID | IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask != 0xEFFF) {
+ else if (input_mask->vlan_tci_mask != rte_cpu_to_be_16(0xEFFF)) {
PMD_INIT_LOG(ERR, "invalid vlan_tci_mask");
return -EINVAL;
}
@@ -340,19 +341,26 @@ fdir_set_input_mask_82599(struct rte_eth_dev *dev,
IXGBE_WRITE_REG(hw, IXGBE_FDIRM, fdirm);
/* store the TCP/UDP port masks, bit reversed from port layout */
- fdirtcpm = reverse_fdir_bitmasks(input_mask->dst_port_mask,
- input_mask->src_port_mask);
+ fdirtcpm = reverse_fdir_bitmasks(
+ rte_be_to_cpu_16(input_mask->dst_port_mask),
+ rte_be_to_cpu_16(input_mask->src_port_mask));
- /* write all the same so that UDP, TCP and SCTP use the same mask */
+ /* write all the same so that UDP, TCP and SCTP use the same mask
+ * (little-endian)
+ */
IXGBE_WRITE_REG(hw, IXGBE_FDIRTCPM, ~fdirtcpm);
IXGBE_WRITE_REG(hw, IXGBE_FDIRUDPM, ~fdirtcpm);
IXGBE_WRITE_REG(hw, IXGBE_FDIRSCTPM, ~fdirtcpm);
info->mask.src_port_mask = input_mask->src_port_mask;
info->mask.dst_port_mask = input_mask->dst_port_mask;
- /* Store source and destination IPv4 masks (big-endian) */
- IXGBE_WRITE_REG(hw, IXGBE_FDIRSIP4M, ~(input_mask->ipv4_mask.src_ip));
- IXGBE_WRITE_REG(hw, IXGBE_FDIRDIP4M, ~(input_mask->ipv4_mask.dst_ip));
+ /* Store source and destination IPv4 masks (big-endian),
+ * can not use IXGBE_WRITE_REG.
+ */
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRSIP4M);
+ *reg = ~(input_mask->ipv4_mask.src_ip);
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRDIP4M);
+ *reg = ~(input_mask->ipv4_mask.dst_ip);
info->mask.src_ipv4_mask = input_mask->ipv4_mask.src_ip;
info->mask.dst_ipv4_mask = input_mask->ipv4_mask.dst_ip;
@@ -401,16 +409,16 @@ fdir_set_input_mask_x550(struct rte_eth_dev *dev,
/* some bits must be set for mac vlan or tunnel mode */
fdirm |= IXGBE_FDIRM_L4P | IXGBE_FDIRM_L3P;
- if (input_mask->vlan_tci_mask == 0x0FFF)
+ if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0x0FFF))
/* mask VLAN Priority */
fdirm |= IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask == 0xE000)
+ else if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0xE000))
/* mask VLAN ID */
fdirm |= IXGBE_FDIRM_VLANID;
else if (input_mask->vlan_tci_mask == 0)
/* mask VLAN ID and Priority */
fdirm |= IXGBE_FDIRM_VLANID | IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask != 0xEFFF) {
+ else if (input_mask->vlan_tci_mask != rte_cpu_to_be_16(0xEFFF)) {
PMD_INIT_LOG(ERR, "invalid vlan_tci_mask");
return -EINVAL;
}
@@ -444,7 +452,7 @@ fdir_set_input_mask_x550(struct rte_eth_dev *dev,
info->mask.tunnel_type_mask =
input_mask->tunnel_type_mask;
- switch (input_mask->tunnel_id_mask & 0xFFFFFFFF) {
+ switch (rte_be_to_cpu_32(input_mask->tunnel_id_mask)) {
case 0x0:
/* Mask vxlan id */
fdiripv6m |= IXGBE_FDIRIP6M_TNI_VNI;
@@ -904,13 +912,16 @@ fdir_write_perfect_filter_82599(struct ixgbe_hw *hw,
u32 addr_low, addr_high;
u32 tunnel_type = 0;
int err = 0;
+ volatile uint32_t *reg;
if (mode == RTE_FDIR_MODE_PERFECT) {
- /* record the IPv4 address (big-endian) */
- IXGBE_WRITE_REG(hw, IXGBE_FDIRIPSA,
- input->formatted.src_ip[0]);
- IXGBE_WRITE_REG(hw, IXGBE_FDIRIPDA,
- input->formatted.dst_ip[0]);
+ /* record the IPv4 address (big-endian)
+ * can not use IXGBE_WRITE_REG.
+ */
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRIPSA);
+ *reg = input->formatted.src_ip[0];
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRIPDA);
+ *reg = input->formatted.dst_ip[0];
/* record source and destination port (little-endian)*/
fdirport = IXGBE_NTOHS(input->formatted.dst_port);
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index ce224ad..d433e0b 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -501,6 +501,7 @@ struct rte_eth_tunnel_flow {
/**
* An union contains the inputs for all types of flow
+ * Items in flows need to be in big endian
*/
union rte_eth_fdir_flow {
struct rte_eth_l2_flow l2_flow;
@@ -588,14 +589,22 @@ struct rte_eth_fdir_filter {
* to match the various fields of RX packet headers.
*/
struct rte_eth_fdir_masks {
- uint16_t vlan_tci_mask;
+ uint16_t vlan_tci_mask; /**< Bit mask for vlan_tci in big endian */
+ /** Bit mask for ipv4 flow in big endian. */
struct rte_eth_ipv4_flow ipv4_mask;
+ /** Bit maks for ipv6 flow in big endian. */
struct rte_eth_ipv6_flow ipv6_mask;
+ /** Bit mask for L4 source port in big endian. */
uint16_t src_port_mask;
+ /** Bit mask for L4 destination port in big endian. */
uint16_t dst_port_mask;
- uint8_t mac_addr_byte_mask; /** Per byte MAC address mask */
- uint32_t tunnel_id_mask; /** tunnel ID mask */
- uint8_t tunnel_type_mask;
+ /** 6 bit mask for proper 6 bytes of Mac address, bit 0 matches the
+ first byte on the wire */
+ uint8_t mac_addr_byte_mask;
+ /** Bit mask for tunnel ID in big endian. */
+ uint32_t tunnel_id_mask;
+ uint8_t tunnel_type_mask; /**< 1 - Match tunnel type,
+ 0 - Ignore tunnel type. */
};
/**
--
2.4.0
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v1] doc: add example text to release notes
@ 2016-02-01 15:24 9% John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2016-02-01 15:24 UTC (permalink / raw)
To: dev
Added example text to each of the release notes sections to show
the preferred format.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
This is a little late since there are already several release note
submissions but I'd like to add some guidance on what the release
notes should look like to, hopefully, make the final edit easier.
doc/guides/rel_notes/release_2_3.rst | 75 ++++++++++++++++++++++++++++++++++++
1 file changed, 75 insertions(+)
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..2cb04c0 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -1,13 +1,61 @@
DPDK Release 2.3
================
+
+** Read this first **
+
+The text below explains how to update the release notes.
+
+Use proper spelling, capitalization and punctuation in all sections.
+
+Variable and config names should be quoted as fixed width text: ``LIKE_THIS``.
+
+Build the docs and view the output file to ensure the changes are correct::
+
+ make doc-guides-html
+
+ firefox build/doc/html/guides/rel_notes/release_2_3.html
+
+
New Features
------------
+This section should contain new features added in this release. Sample format:
+
+
+* **Add a title in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description in the past tense. The description
+ should be enough to allow someone scanning the release notes to understand
+ the new feature.
+
+ If the feature adds a lot of sub-features you can use a bullet list like
+ this.
+
+ * Added feature foo to do something.
+ * Enhanced feature bar to do something else.
+
+ Refer to the previous release notes for examples.
+
Resolved Issues
---------------
+This section should contain bug fixes added to the relevant sections. Sample
+format:
+
+
+* **code/section Fixed issue in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description of the resolved issue in the past
+ tense. The title should contain the code/lib section like a commit
+ message. Add the entries in alphabetic order in the relevant sections
+ below.
+
+
EAL
~~~
@@ -32,17 +80,44 @@ Known Issues
------------
+This section should contain new known issues in this release. Sample format:
+
+
+* **Add title in present tense with full stop.**
+
+ Add a short 1-2 sentence description of the known issue in the present
+ tense. Add information on any known workarounds.
+
+
+
API Changes
-----------
+This section should contain API changes. Sample format:
+
+
+* Add a short 1-2 sentence description of the API change. Use fixed width
+ quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past
+ tense.
+
+
+
ABI Changes
-----------
+* Add a short 1-2 sentence description of the ABI change that was announced in
+ the previous releases and made in this release. Use fixed width quotes for
+ ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+
+
Shared Library Versions
-----------------------
+Update any library version updated in this release and prepend with a ``+``
+sign.
+
The libraries prepended with a plus sign were incremented in this version.
.. code-block:: diff
--
2.5.0
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
@ 2016-02-01 16:47 3% ` David Harton (dharton)
2016-02-01 21:23 0% ` Matthew Hall
2016-02-02 11:40 3% ` Van Haaren, Harry
0 siblings, 2 replies; 200+ results
From: David Harton (dharton) @ 2016-02-01 16:47 UTC (permalink / raw)
To: Van Haaren, Harry, Thomas Monjalon; +Cc: dev
Hi folks,
I didn't see any follow up to this response.
My original concern was rte_eth_stats_get() moving away from a more conventional based definition (note, I believe Matthew Hall made an interesting suggestion to follow a MIB based definition elsewhere). However, if modifying that API is not desired then I'd really like to have some feedback about extending the current xstats model.
Again, it is desired not to have to copy and/or parse strings for scalability reasons but still maintain the "ABI flexibility" for which the xstats model was geared towards.
Thanks,
Dave
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of David Harton (dharton)
> Sent: Friday, January 22, 2016 2:26 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>; Thomas Monjalon <thomas.monjalon@6wind.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
>
> > > > Do you see a fundamental problem with parsing the strings to
> > > > retrieve values?
> > >
> > > I think parsing strings is expensive CPU wise
> >
> > Parsing the strings can be done once at startup, and the index of the
> > statistics in the array cached. When actually reading statistics,
> > access of the array of statistics at the previously cached index will
> > return the same statistic. It is not needed to do strcmp() per statistic
> per read.
>
> How is this order guaranteed through the API? The stat is currently
> identified by the string not by order returned. What if a driver returns
> more/less stats based on config that changes after boot?
>
> >
> >
> > > That's why I was wondering if a binary id could be generated instead.
> >
> > I've worked with such a system before, it dynamically registered
> > string-
> > >int mappings at runtime, and allowed "reverse" mapping them too. Its
> > workable, and I'm not opposed to it if the conclusion is that it
> > really is necessary, but I'm not sure about that.
> >
> >
> > > The API
> > > would be very similar to the current xstats API except it would pass
> > > id/value pairs instead of string/value pairs. This avoids string
> > > comparisons to figure out while still allowing flexibility between
> > drivers.
> >
> > Apart from a once-off scan at startup, xstats achieves this.
>
> Partially true. You may not need to perform strcmp() per read, although I
> don't believe the defined API guarantees that this would be safe (see
> above); but, you still have to perform a strcpy() of each stat whether the
> caller is interested in it or not.
>
> >
> >
> > > It would also 100% guarantee that any strings returned by "const
> > > char* rte_eth_xstats_str_get(uint32_t stat_id)" are consistent
> > > across devices.
> >
> > Yes - that is a nice feature that xstats (in its current form) doesn't
> > have.
> > But what price is there to pay for this?
> > We need to map an ID for each stat that exists.
> >
> > How and where will this mapping happen? Perhaps would you expand a
> > little on how you see this working?
>
> I wasn't thinking dynamic registration as that might be more than
> necessary. I can code up a detailed snippet that shares the idea if
> wanted but I think the following communicates the basic idea:
>
> enum rte_eth_stat_e {
> /* accurate desc #1 */
> RTE_ETH_STAT_1,
> /* accurate desc #2 */
> RTE_ETH_STAT_2,
> ...
> }
> struct rte_eth_id_stat {
> rte_eth_stat_e id;
> uin64_t value;
> }
>
> int rte_eth_id_stats_num(uint8_t port_id, uint32_t *num_stats);
> /* returns < 0 on error or the number of stats that could have been read
> (i.e. if userd */ int rte_eth_id_stats_get(uint8_t port_id, uint32_t
> num_stats, rte_eth_id_stat *id_stats); const char*
> rte_eth_id_stat_str(rte_eth_stat_e id);
>
> This allows a driver to return whatever stats that it supports in a
> consistent manner and also in a performance friendly way. In fact, the
> driver side would be identical to what they have today but instead of
> having arrays with "string stat name" they will have the rte_eth_stat_e.
>
> >
> > > I also think there is less chance for error if drivers assign their
> > > stats to ID versus constructing a string.
> >
> > Have a look in how the mapping is done in the xstats implementation
> > for ixgbe for example:
> > http://dpdk.org/browse/dpdk/tree/drivers/net/ixgbe/ixgbe_ethdev.c#n540
> >
> > It's a pretty simple {"string stat name" -> offsetof( stuct hw,
> > register_var_name )}
>
> It's not how they add the strings but rather the format of the string
> itself that is error prone.
> IOTW, the "string stat name" is prone to not being formatted correctly or
> consistently.
>
> >
> >
> > > I haven't checked my application, but I wonder if the binary size
> > > would actually be smaller if all the stats strings were centrally
> > > located versus distributed across binaries (highly dependent on the
> > linker and optimization level).
> >
> > Sounds like optimizing the wrong thing to me.
>
> Wasn't trying to optimize image size as much as saying it's a side benefit
> due to string consolidation.
>
> >
> >
> > > > If you like I could code up a minimal sample-app that only pulls
> > > > statistics, and you can show "interest" in various statistics for
> > > > printing / monitoring?
> > >
> > > Appreciate the offer. I actually understand what's is available.
> > > And, BTW, I apologize for being late to the game (looks like this
> > > was discussed last summer) but I'm just now getting looped in and
> > > following the mailer but I'm just wondering if something that is
> > performance friendly for the user/application and flexible for the
> > drivers is possible.
> >
> > We're all looking for the same thing - just different approaches
> > that's all :)
> >
> >
> > RE: Thomas asking about performance numbers:
> > I can scrape together some raw tsc data on Monday and post to list,
> > and we can discuss it more then.
>
> I can do the same if desired. But, just to make sure we are discussing
> the same issue:
>
> 1) call rte_eth_xtats_get()
> This will result in many string copies and depending on the driver *many*
> copies I don't want or care about.
> 2) "tokenize"/parse/hash the string returned to identify what the stat
> actually is I'm guessing you are stating that this step could be mitigated
> at startup. But, again, I don't think the API provides a guarantee which
> usually leads to bugs over time.
> 3) Copy the value of the stat into the driver agnostic container the
> application uses
> 4) Repeat steps 1-3 for every interface being serviced every 5 or 10 secs
>
> Contrast that to my suggestion which has no string copies and a compile
> time mapping between "stat_id" and "app stat" can be created for step 2.
> I think the performance differences are obvious even without generating
> cycle times.
>
> I know that dpdk is largely focused on data plane performance and rightly
> so, but, I'm hoping we can keep the control plane in mind as well
> especially in the areas around stats or things that happen periodically
> per port.
>
> Regards,
> Dave
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
2016-02-01 16:47 3% ` David Harton (dharton)
@ 2016-02-01 21:23 0% ` Matthew Hall
2016-02-02 11:40 3% ` Van Haaren, Harry
1 sibling, 0 replies; 200+ results
From: Matthew Hall @ 2016-02-01 21:23 UTC (permalink / raw)
To: David Harton (dharton); +Cc: dev
On Mon, Feb 01, 2016 at 04:47:56PM +0000, David Harton (dharton) wrote:
> Hi folks,
>
> I didn't see any follow up to this response.
>
> My original concern was rte_eth_stats_get() moving away from a more
> conventional based definition (note, I believe Matthew Hall made an
> interesting suggestion to follow a MIB based definition elsewhere).
> However, if modifying that API is not desired then I'd really like to have
> some feedback about extending the current xstats model.
>
> Again, it is desired not to have to copy and/or parse strings for
> scalability reasons but still maintain the "ABI flexibility" for which the
> xstats model was geared towards.
>
> Thanks,
> Dave
For me, I'd like to be able to get the core common stats in single memory
blocks which are as self-consistent and atomic as possible.
I'd prefer to only resort to stuff like xstats using some kind of
string-to-number lookup at the beginning, and only for weird stuff not the
common MIB-like items.
>From past experience this would be very valuable.
Matthew.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] rings PMD detaching
@ 2016-02-02 5:41 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2016-02-02 5:41 UTC (permalink / raw)
To: Mauricio Vásquez; +Cc: dev, Jan Viktorin
Hello Mauricio,
On Tue, Feb 2, 2016 at 2:37 AM, Mauricio Vásquez
<mauricio.vasquezbernal@studenti.polito.it> wrote:
> I was wondering if there were a way to detach (delete) a ring pmd device
> created with rte_eth_from_rings. I realized that rte_eth_dev_detach does
> not work in this case because there is a comparison between the device's
> name and the driver's name in rte_eal_vdev_uninit, then devices created
> with arbitrary names can not be uninitialized.
I would say this is the same problem than what I observed in pci code.
Doing a "driver" lookup on detach is useless (and buggy in your case),
eal should just reuse the driver that the device had been attached to.
The problem is that, for vdev, the driver is not stored in a device
object at attach time, since there is no device object.
> My question is how to implement it?, I have two ideas on mind:
> - make rte_pmd_ring_devuninit a public function, then the user can call
> this using as argument the name of the device.
Having something like this enter abi, because of a bug in eal, does
not sound like a good idea.
> - modify rte_eal_vdev_uninit in such a way that there is not any comparison
> based on the dev name, probably it will require to add some extra field in
> the rte_eth_dev structure to distinguish between the different virtual
> devices.
No, the problem lies in eal where resources are bound to drivers.
No reason to pollute ethdev (we have enough workarounds in it ;-)).
This driver lookup should just go away.
If we had the rte_device I described [1], this kind of issues would disappear.
[1] http://dpdk.org/ml/archives/dev/2016-January/031390.html
Regards,
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
2016-02-01 16:47 3% ` David Harton (dharton)
2016-02-01 21:23 0% ` Matthew Hall
@ 2016-02-02 11:40 3% ` Van Haaren, Harry
1 sibling, 0 replies; 200+ results
From: Van Haaren, Harry @ 2016-02-02 11:40 UTC (permalink / raw)
To: 'David Harton (dharton)', Thomas Monjalon; +Cc: dev
+John,
> From: David Harton
> Subject: RE: [dpdk-dev] Future Direction for rte_eth_stats_get()
>
> Hi folks,
>
> I didn't see any follow up to this response.
I think you may have missed one:
http://dpdk.org/ml/archives/dev/2016-January/032211.html
> <snip>
> However, if modifying that API is not desired then I'd
> really like to have some feedback about extending the current xstats model.
API / ABI modification/breakage is something that will
need to be considered in any discussions. The 2.3 (or 16.04)
V1 patch deadline has passed, so any output from this
discussion will be leading to the 16.07 release.
> Again, it is desired not to have to copy and/or parse strings for scalability reasons but
> still maintain the "ABI flexibility" for which the xstats model was geared towards.
Agreed.
From: David Harton
> enum rte_eth_stat_e {
> /* accurate desc #1 */
> RTE_ETH_STAT_1,
> /* accurate desc #2 */
> RTE_ETH_STAT_2,
> ...
> }
For this enum, do you see each stat for every PMD entered here?
RX_GOOD_PACKETS,
What about RX and TX, is it listed twice?
RX_GOOD_PACKETS,
TX_GOOD_PACKETS,
In a case where a VF has RX_GOOD_PACKETS, does it get its "own" set?
RX_GOOD_PACKETS,
TX_GOOD_PACKETS,
VF_RX_GOOD_PACKETS,
VF_TX_GOOD_PACKETS,
I'm looking at the enum thinking it will grow out of control.
Have you thought about adding metadata for RX / TX, PF / VF?
If metadata info is added, it would make retrieving a set of
statistics based on a certain mask much easier. Do you think
this may be of use?
-Harry
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags
@ 2016-02-02 22:59 3% Thomas Monjalon
2016-02-02 23:10 1% ` [dpdk-dev] [PATCH v1 2/5] eal: move CPU flag functions out of headers Thomas Monjalon
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Thomas Monjalon @ 2016-02-02 22:59 UTC (permalink / raw)
To: david.marchand, ferruh.yigit; +Cc: dev, viktorin
Following the work of Ferruh, I suggest this cleanup to remove as much
as possible of the code from the cpuflags headers.
The goal is to un-inline these functions (not performance sensitive)
and remove the CPU flags table from the ABI (just added recently).
The bonus is to stop mimic x86 in ARM and PPC implementations.
WARNING: it has not been tested nor compiled on Tilera, ARM and POWER8.
Please help, thank you.
Thomas Monjalon (5):
eal: get CPU flag name
eal: move CPU flag functions out of headers
eal/arm: adapt CPU flags check to the arch
eal/ppc: adapt CPU flags check to the arch
eal: remove compiler optimization workaround
app/test/test_hash_scaling.c | 2 +
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 +-
lib/librte_eal/common/arch/arm/rte_cpuflags.c | 170 ++++++++++++++++-----
lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c | 145 +++++++++++++-----
lib/librte_eal/common/arch/tile/rte_cpuflags.c | 11 ++
lib/librte_eal/common/arch/x86/rte_cpuflags.c | 91 +++++++++++
lib/librte_eal/common/eal_common_cpuflags.c | 18 +--
.../common/include/arch/arm/rte_cpuflags_32.h | 78 ----------
.../common/include/arch/arm/rte_cpuflags_64.h | 79 ----------
.../common/include/arch/ppc_64/rte_cpuflags.h | 64 --------
.../common/include/arch/tile/rte_cpuflags.h | 29 ----
.../common/include/arch/x86/rte_cpuflags.h | 66 --------
.../common/include/generic/rte_cpuflags.h | 56 ++-----
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 3 +-
14 files changed, 364 insertions(+), 450 deletions(-)
--
2.5.2
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] mempool: Reduce rte_mempool structure size
@ 2016-02-02 23:02 2% Keith Wiles
2016-02-03 17:11 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Keith Wiles @ 2016-02-02 23:02 UTC (permalink / raw)
To: dev
The rte_mempool structure is changed, which will cause an ABI change
for this structure.
Allow mempool cache support to be dynamic depending on if the
mempool being created needs cache support. Saves about 1.5M of
memory used by the rte_mempool structure. Performance does not seem
to be effected running l3fwd and the test_mempool execution passed.
Allocating small mempools which do not require cache can consume
larges amounts of memory if you have a number of these mempools.
Signed-off-by: Keith Wiles <keith.wiles@intel.com>
---
app/test/test_mempool.c | 4 +--
lib/librte_mempool/rte_mempool.c | 56 ++++++++++++++++++----------------------
lib/librte_mempool/rte_mempool.h | 29 ++++++++++-----------
3 files changed, 40 insertions(+), 49 deletions(-)
diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index 72f8fb6..7b479f8 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -122,8 +122,8 @@ test_mempool_basic(void)
return -1;
printf("get private data\n");
- if (rte_mempool_get_priv(mp) !=
- (char*) mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num))
+ if (rte_mempool_get_priv(mp) != (char *)mp +
+ MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size))
return -1;
printf("get physical address of an object\n");
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index aff5f6d..bdf8e2e 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -450,15 +450,11 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
int page_size = getpagesize();
/* compilation-time checks */
+#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool) &
RTE_CACHE_LINE_MASK) != 0);
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
RTE_CACHE_LINE_MASK) != 0);
- RTE_BUILD_BUG_ON((offsetof(struct rte_mempool, local_cache) &
- RTE_CACHE_LINE_MASK) != 0);
-#endif
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_debug_stats) &
RTE_CACHE_LINE_MASK) != 0);
RTE_BUILD_BUG_ON((offsetof(struct rte_mempool, stats) &
@@ -527,9 +523,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
*/
int head = sizeof(struct rte_mempool);
int new_size = (private_data_size + head) % page_size;
- if (new_size) {
+ if (new_size)
private_data_size += page_size - new_size;
- }
}
/* try to allocate tailq entry */
@@ -544,7 +539,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
* store mempool objects. Otherwise reserve a memzone that is large
* enough to hold mempool header and metadata plus mempool objects.
*/
- mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num) + private_data_size;
+ mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num, cache_size);
+ mempool_size += private_data_size;
mempool_size = RTE_ALIGN_CEIL(mempool_size, RTE_MEMPOOL_ALIGN);
if (vaddr == NULL)
mempool_size += (size_t)objsz.total_size * n;
@@ -598,8 +594,15 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
mp->cache_flushthresh = CALC_CACHE_FLUSHTHRESH(cache_size);
mp->private_data_size = private_data_size;
+ /*
+ * local_cache pointer is set even if cache_size is zero.
+ * The local_cache points to just past the elt_pa[] array.
+ */
+ mp->local_cache = (struct rte_mempool_cache *)
+ ((char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num, 0));
+
/* calculate address of the first element for continuous mempool. */
- obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num) +
+ obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num, cache_size) +
private_data_size;
obj = RTE_PTR_ALIGN_CEIL(obj, RTE_MEMPOOL_ALIGN);
@@ -613,9 +616,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
mp->elt_va_start = (uintptr_t)obj;
mp->elt_pa[0] = mp->phys_addr +
(mp->elt_va_start - (uintptr_t)mp);
-
- /* mempool elements in a separate chunk of memory. */
} else {
+ /* mempool elements in a separate chunk of memory. */
mp->elt_va_start = (uintptr_t)vaddr;
memcpy(mp->elt_pa, paddr, sizeof (mp->elt_pa[0]) * pg_num);
}
@@ -645,19 +647,15 @@ unsigned
rte_mempool_count(const struct rte_mempool *mp)
{
unsigned count;
+ unsigned lcore_id;
count = rte_ring_count(mp->ring);
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
- {
- unsigned lcore_id;
- if (mp->cache_size == 0)
- return count;
+ if (mp->cache_size == 0)
+ return count;
- for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
- count += mp->local_cache[lcore_id].len;
- }
-#endif
+ for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
+ count += mp->local_cache[lcore_id].len;
/*
* due to race condition (access to len is not locked), the
@@ -672,13 +670,15 @@ rte_mempool_count(const struct rte_mempool *mp)
static unsigned
rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
{
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
unsigned lcore_id;
unsigned count = 0;
unsigned cache_count;
fprintf(f, " cache infos:\n");
fprintf(f, " cache_size=%"PRIu32"\n", mp->cache_size);
+ if (mp->cache_size == 0)
+ return count;
+
for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
cache_count = mp->local_cache[lcore_id].len;
fprintf(f, " cache_count[%u]=%u\n", lcore_id, cache_count);
@@ -686,11 +686,6 @@ rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
}
fprintf(f, " total_cache_count=%u\n", count);
return count;
-#else
- RTE_SET_USED(mp);
- fprintf(f, " cache disabled\n");
- return 0;
-#endif
}
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
@@ -755,13 +750,16 @@ mempool_audit_cookies(const struct rte_mempool *mp)
#define mempool_audit_cookies(mp) do {} while(0)
#endif
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/* check cookies before and after objects */
static void
mempool_audit_cache(const struct rte_mempool *mp)
{
/* check cache size consistency */
unsigned lcore_id;
+
+ if (mp->cache_size == 0)
+ return;
+
for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
if (mp->local_cache[lcore_id].len > mp->cache_flushthresh) {
RTE_LOG(CRIT, MEMPOOL, "badness on cache[%u]\n",
@@ -770,10 +768,6 @@ mempool_audit_cache(const struct rte_mempool *mp)
}
}
}
-#else
-#define mempool_audit_cache(mp) do {} while(0)
-#endif
-
/* check the consistency of mempool (size, cookies, ...) */
void
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 6e2390a..434ef98 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -95,7 +95,6 @@ struct rte_mempool_debug_stats {
} __rte_cache_aligned;
#endif
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/**
* A structure that stores a per-core object cache.
*/
@@ -107,7 +106,6 @@ struct rte_mempool_cache {
*/
void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache objects */
} __rte_cache_aligned;
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
/**
* A structure that stores the size of mempool elements.
@@ -194,10 +192,7 @@ struct rte_mempool {
unsigned private_data_size; /**< Size of private data. */
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
- /** Per-lcore local cache. */
- struct rte_mempool_cache local_cache[RTE_MAX_LCORE];
-#endif
+ struct rte_mempool_cache *local_cache; /**< Per-lcore local cache */
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
/** Per-lcore statistics. */
@@ -247,6 +242,13 @@ struct rte_mempool {
#endif
/**
+ * Size of elt_pa array size based on number of pages. (Internal use)
+ */
+#define __PA_SIZE(mp, pgn) \
+ RTE_ALIGN_CEIL((((pgn) - RTE_DIM((mp)->elt_pa)) * \
+ sizeof((mp)->elt_pa[0])), RTE_CACHE_LINE_SIZE)
+
+/**
* Calculate the size of the mempool header.
*
* @param mp
@@ -254,9 +256,9 @@ struct rte_mempool {
* @param pgn
* Number of pages used to store mempool objects.
*/
-#define MEMPOOL_HEADER_SIZE(mp, pgn) (sizeof(*(mp)) + \
- RTE_ALIGN_CEIL(((pgn) - RTE_DIM((mp)->elt_pa)) * \
- sizeof ((mp)->elt_pa[0]), RTE_CACHE_LINE_SIZE))
+#define MEMPOOL_HEADER_SIZE(mp, pgn, cs) \
+ (sizeof(*(mp)) + __PA_SIZE(mp, pgn) + (((cs) == 0) ? 0 : \
+ (sizeof(struct rte_mempool_cache) * RTE_MAX_LCORE)))
/**
* Return true if the whole mempool is in contiguous memory.
@@ -755,19 +757,16 @@ static inline void __attribute__((always_inline))
__mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
unsigned n, int is_mp)
{
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
struct rte_mempool_cache *cache;
uint32_t index;
void **cache_objs;
unsigned lcore_id = rte_lcore_id();
uint32_t cache_size = mp->cache_size;
uint32_t flushthresh = mp->cache_flushthresh;
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
/* increment stat now, adding in mempool always success */
__MEMPOOL_STAT_ADD(mp, put, n);
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/* cache is not enabled or single producer or non-EAL thread */
if (unlikely(cache_size == 0 || is_mp == 0 ||
lcore_id >= RTE_MAX_LCORE))
@@ -802,7 +801,6 @@ __mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
return;
ring_enqueue:
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
/* push remaining objects in ring */
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
@@ -946,7 +944,6 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
unsigned n, int is_mc)
{
int ret;
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
struct rte_mempool_cache *cache;
uint32_t index, len;
void **cache_objs;
@@ -992,7 +989,6 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
return 0;
ring_dequeue:
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
/* get remaining objects from ring */
if (is_mc)
@@ -1293,7 +1289,8 @@ void rte_mempool_audit(const struct rte_mempool *mp);
*/
static inline void *rte_mempool_get_priv(struct rte_mempool *mp)
{
- return (char *)mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num);
+ return (char *)mp +
+ MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size);
}
/**
--
2.7.0
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v1 2/5] eal: move CPU flag functions out of headers
2016-02-02 22:59 3% [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Thomas Monjalon
@ 2016-02-02 23:10 1% ` Thomas Monjalon
2016-02-02 23:51 0% ` [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Jan Viktorin
2016-02-03 13:38 0% ` Jerin Jacob
2 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2016-02-02 23:10 UTC (permalink / raw)
To: david.marchand, ferruh.yigit; +Cc: dev, viktorin
The patch c344eab3ee has moved the hardware definition of CPU flags.
Now the functions checking these hardware flags are also moved.
The function rte_cpu_get_flag_enabled() is no more inline.
The benefits are:
- remove rte_cpu_feature_table from the ABI (recently added)
- hide hardware details from the API
- allow to adapt structures per arch (done in next patch)
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
app/test/test_hash_scaling.c | 2 +
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 -
lib/librte_eal/common/arch/arm/rte_cpuflags.c | 99 ++++++++++++++++++++++
lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c | 79 +++++++++++++++++
lib/librte_eal/common/arch/tile/rte_cpuflags.c | 11 +++
lib/librte_eal/common/arch/x86/rte_cpuflags.c | 83 ++++++++++++++++++
lib/librte_eal/common/eal_common_cpuflags.c | 3 +
.../common/include/arch/arm/rte_cpuflags_32.h | 78 -----------------
.../common/include/arch/arm/rte_cpuflags_64.h | 79 -----------------
.../common/include/arch/ppc_64/rte_cpuflags.h | 64 --------------
.../common/include/arch/tile/rte_cpuflags.h | 29 -------
.../common/include/arch/x86/rte_cpuflags.h | 66 ---------------
.../common/include/generic/rte_cpuflags.h | 50 +----------
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 -
14 files changed, 278 insertions(+), 367 deletions(-)
diff --git a/app/test/test_hash_scaling.c b/app/test/test_hash_scaling.c
index 744e5e3..1c4c75d 100644
--- a/app/test/test_hash_scaling.c
+++ b/app/test/test_hash_scaling.c
@@ -31,6 +31,8 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+#include <stdio.h>
+
#include <rte_cycles.h>
#include <rte_hash.h>
#include <rte_hash_crc.h>
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 1280cb2..f0aa698 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -139,7 +139,6 @@ DPDK_2.2 {
DPDK_2.3 {
global:
- rte_cpu_feature_table;
rte_cpu_get_flag_name;
} DPDK_2.2;
diff --git a/lib/librte_eal/common/arch/arm/rte_cpuflags.c b/lib/librte_eal/common/arch/arm/rte_cpuflags.c
index 62e0791..664f527 100644
--- a/lib/librte_eal/common/arch/arm/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/arm/rte_cpuflags.c
@@ -2,6 +2,7 @@
* BSD LICENSE
*
* Copyright (C) Cavium networks Ltd. 2015.
+ * Copyright(c) 2015 RehiveTech. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -32,6 +33,46 @@
#include "rte_cpuflags.h"
+#include <elf.h>
+#include <fcntl.h>
+#include <assert.h>
+#include <unistd.h>
+#include <string.h>
+
+#ifndef AT_HWCAP
+#define AT_HWCAP 16
+#endif
+
+#ifndef AT_HWCAP2
+#define AT_HWCAP2 26
+#endif
+
+#ifndef AT_PLATFORM
+#define AT_PLATFORM 15
+#endif
+
+enum cpu_register_t {
+ REG_HWCAP = 0,
+ REG_HWCAP2,
+};
+
+typedef uint32_t cpuid_registers_t[4];
+
+/**
+ * Struct to hold a processor feature entry
+ */
+struct feature_entry {
+ uint32_t leaf; /**< cpuid leaf */
+ uint32_t subleaf; /**< cpuid subleaf */
+ uint32_t reg; /**< cpuid register */
+ uint32_t bit; /**< cpuid register bit */
+#define CPU_FLAG_NAME_MAX_LEN 64
+ char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
+};
+
+#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
+ [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
+
#ifdef RTE_ARCH_64
const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(FP, 0x00000001, 0, REG_HWCAP, 0)
@@ -77,6 +118,64 @@ const struct feature_entry rte_cpu_feature_table[] = {
};
#endif
+/*
+ * Read AUXV software register and get cpu features for ARM
+ */
+static void
+rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
+ __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
+{
+ int auxv_fd;
+#ifdef RTE_ARCH_64
+ Elf64_auxv_t auxv;
+#else
+ Elf32_auxv_t auxv;
+#endif
+
+ auxv_fd = open("/proc/self/auxv", O_RDONLY);
+ assert(auxv_fd);
+ while (read(auxv_fd, &auxv, sizeof(auxv)) == sizeof(auxv)) {
+ if (auxv.a_type == AT_HWCAP) {
+ out[REG_HWCAP] = auxv.a_un.a_val;
+ } else if (auxv.a_type == AT_HWCAP2) {
+ out[REG_HWCAP2] = auxv.a_un.a_val;
+ } else if (auxv.a_type == AT_PLATFORM) {
+#ifdef RTE_ARCH_64
+ if (!strcmp((const char *)auxv.a_un.a_val, "aarch64"))
+#else
+ if (!strcmp((const char *)auxv.a_un.a_val, "v7l"))
+#endif
+ out[REG_PLATFORM] = 0x0001;
+ }
+ }
+}
+
+/*
+ * Checks if a particular flag is available on current machine.
+ */
+int
+rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
+{
+ const struct feature_entry *feat;
+ cpuid_registers_t regs = {0};
+
+ if (feature >= RTE_CPUFLAG_NUMFLAGS)
+ /* Flag does not match anything in the feature tables */
+ return -ENOENT;
+
+ feat = &rte_cpu_feature_table[feature];
+
+ if (!feat->leaf)
+ /* This entry in the table wasn't filled out! */
+ return -EFAULT;
+
+ /* get the cpuid leaf containing the desired feature */
+ rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
+
+ /* check if the feature is enabled */
+ return (regs[feat->reg] >> feat->bit) & 1;
+}
+
const char *
rte_cpu_get_flag_name(enum rte_cpu_flag_t feature)
{
diff --git a/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c b/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
index a270ccc..b7e0b72 100644
--- a/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
@@ -32,6 +32,38 @@
#include "rte_cpuflags.h"
+#include <elf.h>
+#include <fcntl.h>
+#include <assert.h>
+#include <unistd.h>
+
+/* Symbolic values for the entries in the auxiliary table */
+#define AT_HWCAP 16
+#define AT_HWCAP2 26
+
+/* software based registers */
+enum cpu_register_t {
+ REG_HWCAP = 0,
+ REG_HWCAP2,
+};
+
+typedef uint32_t cpuid_registers_t[4];
+
+/**
+ * Struct to hold a processor feature entry
+ */
+struct feature_entry {
+ uint32_t leaf; /**< cpuid leaf */
+ uint32_t subleaf; /**< cpuid subleaf */
+ uint32_t reg; /**< cpuid register */
+ uint32_t bit; /**< cpuid register bit */
+#define CPU_FLAG_NAME_MAX_LEN 64
+ char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
+};
+
+#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
+ [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
+
const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(PPC_LE, 0x00000001, 0, REG_HWCAP, 0)
FEAT_DEF(TRUE_LE, 0x00000001, 0, REG_HWCAP, 1)
@@ -69,6 +101,53 @@ const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(ARCH_2_07, 0x00000001, 0, REG_HWCAP2, 31)
};
+/*
+ * Read AUXV software register and get cpu features for Power
+ */
+static void
+rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
+ __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
+{
+ int auxv_fd;
+ Elf64_auxv_t auxv;
+
+ auxv_fd = open("/proc/self/auxv", O_RDONLY);
+ assert(auxv_fd);
+ while (read(auxv_fd, &auxv,
+ sizeof(Elf64_auxv_t)) == sizeof(Elf64_auxv_t)) {
+ if (auxv.a_type == AT_HWCAP)
+ out[REG_HWCAP] = auxv.a_un.a_val;
+ else if (auxv.a_type == AT_HWCAP2)
+ out[REG_HWCAP2] = auxv.a_un.a_val;
+ }
+}
+
+/*
+ * Checks if a particular flag is available on current machine.
+ */
+int
+rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
+{
+ const struct feature_entry *feat;
+ cpuid_registers_t regs = {0};
+
+ if (feature >= RTE_CPUFLAG_NUMFLAGS)
+ /* Flag does not match anything in the feature tables */
+ return -ENOENT;
+
+ feat = &rte_cpu_feature_table[feature];
+
+ if (!feat->leaf)
+ /* This entry in the table wasn't filled out! */
+ return -EFAULT;
+
+ /* get the cpuid leaf containing the desired feature */
+ rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
+
+ /* check if the feature is enabled */
+ return (regs[feat->reg] >> feat->bit) & 1;
+}
+
const char *
rte_cpu_get_flag_name(enum rte_cpu_flag_t feature)
{
diff --git a/lib/librte_eal/common/arch/tile/rte_cpuflags.c b/lib/librte_eal/common/arch/tile/rte_cpuflags.c
index 4ca0a7b..a2b6c51 100644
--- a/lib/librte_eal/common/arch/tile/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/tile/rte_cpuflags.c
@@ -32,5 +32,16 @@
#include "rte_cpuflags.h"
+#include <errno.h>
+
const struct feature_entry rte_cpu_feature_table[] = {
};
+
+/*
+ * Checks if a particular flag is available on current machine.
+ */
+int
+rte_cpu_get_flag_enabled(__attribute__((unused)) enum rte_cpu_flag_t feature)
+{
+ return -ENOENT;
+}
diff --git a/lib/librte_eal/common/arch/x86/rte_cpuflags.c b/lib/librte_eal/common/arch/x86/rte_cpuflags.c
index 3346fde..0138257 100644
--- a/lib/librte_eal/common/arch/x86/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/x86/rte_cpuflags.c
@@ -33,6 +33,34 @@
#include "rte_cpuflags.h"
+#include <stdio.h>
+#include <errno.h>
+#include <stdint.h>
+
+enum cpu_register_t {
+ RTE_REG_EAX = 0,
+ RTE_REG_EBX,
+ RTE_REG_ECX,
+ RTE_REG_EDX,
+};
+
+typedef uint32_t cpuid_registers_t[4];
+
+/**
+ * Struct to hold a processor feature entry
+ */
+struct feature_entry {
+ uint32_t leaf; /**< cpuid leaf */
+ uint32_t subleaf; /**< cpuid subleaf */
+ uint32_t reg; /**< cpuid register */
+ uint32_t bit; /**< cpuid register bit */
+#define CPU_FLAG_NAME_MAX_LEN 64
+ char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
+};
+
+#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
+ [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
+
const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(SSE3, 0x00000001, 0, RTE_REG_ECX, 0)
FEAT_DEF(PCLMULQDQ, 0x00000001, 0, RTE_REG_ECX, 1)
@@ -128,6 +156,61 @@ const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(INVTSC, 0x80000007, 0, RTE_REG_EDX, 8)
};
+/*
+ * Execute CPUID instruction and get contents of a specific register
+ *
+ * This function, when compiled with GCC, will generate architecture-neutral
+ * code, as per GCC manual.
+ */
+static void
+rte_cpu_get_features(uint32_t leaf, uint32_t subleaf, cpuid_registers_t out)
+{
+#if defined(__i386__) && defined(__PIC__)
+ /* %ebx is a forbidden register if we compile with -fPIC or -fPIE */
+ asm volatile("movl %%ebx,%0 ; cpuid ; xchgl %%ebx,%0"
+ : "=r" (out[RTE_REG_EBX]),
+ "=a" (out[RTE_REG_EAX]),
+ "=c" (out[RTE_REG_ECX]),
+ "=d" (out[RTE_REG_EDX])
+ : "a" (leaf), "c" (subleaf));
+#else
+ asm volatile("cpuid"
+ : "=a" (out[RTE_REG_EAX]),
+ "=b" (out[RTE_REG_EBX]),
+ "=c" (out[RTE_REG_ECX]),
+ "=d" (out[RTE_REG_EDX])
+ : "a" (leaf), "c" (subleaf));
+#endif
+}
+
+int
+rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
+{
+ const struct feature_entry *feat;
+ cpuid_registers_t regs;
+
+ if (feature >= RTE_CPUFLAG_NUMFLAGS)
+ /* Flag does not match anything in the feature tables */
+ return -ENOENT;
+
+ feat = &rte_cpu_feature_table[feature];
+
+ if (!feat->leaf)
+ /* This entry in the table wasn't filled out! */
+ return -EFAULT;
+
+ rte_cpu_get_features(feat->leaf & 0xffff0000, 0, regs);
+ if (((regs[RTE_REG_EAX] ^ feat->leaf) & 0xffff0000) ||
+ regs[RTE_REG_EAX] < feat->leaf)
+ return 0;
+
+ /* get the cpuid leaf containing the desired feature */
+ rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
+
+ /* check if the feature is enabled */
+ return (regs[feat->reg] >> feat->bit) & 1;
+}
+
const char *
rte_cpu_get_flag_name(enum rte_cpu_flag_t feature)
{
diff --git a/lib/librte_eal/common/eal_common_cpuflags.c b/lib/librte_eal/common/eal_common_cpuflags.c
index 8c0576d..a4c5a29 100644
--- a/lib/librte_eal/common/eal_common_cpuflags.c
+++ b/lib/librte_eal/common/eal_common_cpuflags.c
@@ -30,6 +30,9 @@
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+
+#include <stdio.h>
+
#include <rte_common.h>
#include <rte_cpuflags.h>
diff --git a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h
index 2ec0c2e..373fd46 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h
@@ -37,35 +37,8 @@
extern "C" {
#endif
-#include <elf.h>
-#include <fcntl.h>
-#include <assert.h>
-#include <unistd.h>
-#include <string.h>
-
#include "generic/rte_cpuflags.h"
-extern const struct feature_entry rte_cpu_feature_table[];
-
-#ifndef AT_HWCAP
-#define AT_HWCAP 16
-#endif
-
-#ifndef AT_HWCAP2
-#define AT_HWCAP2 26
-#endif
-
-#ifndef AT_PLATFORM
-#define AT_PLATFORM 15
-#endif
-
-/* software based registers */
-enum cpu_register_t {
- REG_HWCAP = 0,
- REG_HWCAP2,
- REG_PLATFORM,
-};
-
/**
* Enumeration of all CPU features supported
*/
@@ -102,57 +75,6 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
};
-/*
- * Read AUXV software register and get cpu features for ARM
- */
-static inline void
-rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
- __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
-{
- int auxv_fd;
- Elf32_auxv_t auxv;
-
- auxv_fd = open("/proc/self/auxv", O_RDONLY);
- assert(auxv_fd);
- while (read(auxv_fd, &auxv,
- sizeof(Elf32_auxv_t)) == sizeof(Elf32_auxv_t)) {
- if (auxv.a_type == AT_HWCAP)
- out[REG_HWCAP] = auxv.a_un.a_val;
- else if (auxv.a_type == AT_HWCAP2)
- out[REG_HWCAP2] = auxv.a_un.a_val;
- else if (auxv.a_type == AT_PLATFORM) {
- if (!strcmp((const char *)auxv.a_un.a_val, "v7l"))
- out[REG_PLATFORM] = 0x0001;
- }
- }
-}
-
-/*
- * Checks if a particular flag is available on current machine.
- */
-static inline int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
-{
- const struct feature_entry *feat;
- cpuid_registers_t regs = {0};
-
- if (feature >= RTE_CPUFLAG_NUMFLAGS)
- /* Flag does not match anything in the feature tables */
- return -ENOENT;
-
- feat = &rte_cpu_feature_table[feature];
-
- if (!feat->leaf)
- /* This entry in the table wasn't filled out! */
- return -EFAULT;
-
- /* get the cpuid leaf containing the desired feature */
- rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
-
- /* check if the feature is enabled */
- return (regs[feat->reg] >> feat->bit) & 1;
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h
index b36040b..4cf4759 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h
@@ -37,35 +37,8 @@
extern "C" {
#endif
-#include <elf.h>
-#include <fcntl.h>
-#include <assert.h>
-#include <unistd.h>
-#include <string.h>
-
#include "generic/rte_cpuflags.h"
-extern const struct feature_entry rte_cpu_feature_table[];
-
-#ifndef AT_HWCAP
-#define AT_HWCAP 16
-#endif
-
-#ifndef AT_HWCAP2
-#define AT_HWCAP2 26
-#endif
-
-#ifndef AT_PLATFORM
-#define AT_PLATFORM 15
-#endif
-
-/* software based registers */
-enum cpu_register_t {
- REG_HWCAP = 0,
- REG_HWCAP2,
- REG_PLATFORM,
-};
-
/**
* Enumeration of all CPU features supported
*/
@@ -83,58 +56,6 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
};
-/*
- * Read AUXV software register and get cpu features for ARM
- */
-static inline void
-rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
- __attribute__((unused)) uint32_t subleaf,
- cpuid_registers_t out)
-{
- int auxv_fd;
- Elf64_auxv_t auxv;
-
- auxv_fd = open("/proc/self/auxv", O_RDONLY);
- assert(auxv_fd);
- while (read(auxv_fd, &auxv,
- sizeof(Elf64_auxv_t)) == sizeof(Elf64_auxv_t)) {
- if (auxv.a_type == AT_HWCAP) {
- out[REG_HWCAP] = auxv.a_un.a_val;
- } else if (auxv.a_type == AT_HWCAP2) {
- out[REG_HWCAP2] = auxv.a_un.a_val;
- } else if (auxv.a_type == AT_PLATFORM) {
- if (!strcmp((const char *)auxv.a_un.a_val, "aarch64"))
- out[REG_PLATFORM] = 0x0001;
- }
- }
-}
-
-/*
- * Checks if a particular flag is available on current machine.
- */
-static inline int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
-{
- const struct feature_entry *feat;
- cpuid_registers_t regs = {0};
-
- if (feature >= RTE_CPUFLAG_NUMFLAGS)
- /* Flag does not match anything in the feature tables */
- return -ENOENT;
-
- feat = &rte_cpu_feature_table[feature];
-
- if (!feat->leaf)
- /* This entry in the table wasn't filled out! */
- return -EFAULT;
-
- /* get the cpuid leaf containing the desired feature */
- rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
-
- /* check if the feature is enabled */
- return (regs[feat->reg] >> feat->bit) & 1;
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h b/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h
index 85c4c1a..04d4c27 100644
--- a/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h
@@ -37,25 +37,8 @@
extern "C" {
#endif
-#include <elf.h>
-#include <fcntl.h>
-#include <assert.h>
-#include <unistd.h>
-
#include "generic/rte_cpuflags.h"
-extern const struct feature_entry rte_cpu_feature_table[];
-
-/* Symbolic values for the entries in the auxiliary table */
-#define AT_HWCAP 16
-#define AT_HWCAP2 26
-
-/* software based registers */
-enum cpu_register_t {
- REG_HWCAP = 0,
- REG_HWCAP2,
-};
-
/**
* Enumeration of all CPU features supported
*/
@@ -98,53 +81,6 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
};
-/*
- * Read AUXV software register and get cpu features for Power
- */
-static inline void
-rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
- __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
-{
- int auxv_fd;
- Elf64_auxv_t auxv;
-
- auxv_fd = open("/proc/self/auxv", O_RDONLY);
- assert(auxv_fd);
- while (read(auxv_fd, &auxv,
- sizeof(Elf64_auxv_t)) == sizeof(Elf64_auxv_t)) {
- if (auxv.a_type == AT_HWCAP)
- out[REG_HWCAP] = auxv.a_un.a_val;
- else if (auxv.a_type == AT_HWCAP2)
- out[REG_HWCAP2] = auxv.a_un.a_val;
- }
-}
-
-/*
- * Checks if a particular flag is available on current machine.
- */
-static inline int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
-{
- const struct feature_entry *feat;
- cpuid_registers_t regs = {0};
-
- if (feature >= RTE_CPUFLAG_NUMFLAGS)
- /* Flag does not match anything in the feature tables */
- return -ENOENT;
-
- feat = &rte_cpu_feature_table[feature];
-
- if (!feat->leaf)
- /* This entry in the table wasn't filled out! */
- return -EFAULT;
-
- /* get the cpuid leaf containing the desired feature */
- rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
-
- /* check if the feature is enabled */
- return (regs[feat->reg] >> feat->bit) & 1;
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h b/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h
index a415857..994884b 100644
--- a/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h
@@ -37,18 +37,8 @@
extern "C" {
#endif
-#include <elf.h>
-#include <fcntl.h>
-#include <assert.h>
-#include <unistd.h>
-
#include "generic/rte_cpuflags.h"
-/* software based registers */
-enum cpu_register_t {
- REG_DUMMY = 0
-};
-
/**
* Enumeration of all CPU features supported
*/
@@ -56,25 +46,6 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS /**< This should always be the last! */
};
-/*
- * Read AUXV software register and get cpu features for Power
- */
-static inline void
-rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
- __attribute__((unused)) uint32_t subleaf,
- __attribute__((unused)) cpuid_registers_t out)
-{
-}
-
-/*
- * Checks if a particular flag is available on current machine.
- */
-static inline int
-rte_cpu_get_flag_enabled(__attribute__((unused)) enum rte_cpu_flag_t feature)
-{
- return -ENOENT;
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h b/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
index 120ea24..117fed2 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
@@ -38,15 +38,8 @@
extern "C" {
#endif
-#include <stdlib.h>
-#include <stdio.h>
-#include <errno.h>
-#include <stdint.h>
-
#include "generic/rte_cpuflags.h"
-extern const struct feature_entry rte_cpu_feature_table[];
-
enum rte_cpu_flag_t {
/* (EAX 01h) ECX features*/
RTE_CPUFLAG_SSE3 = 0, /**< SSE3 */
@@ -153,65 +146,6 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS, /**< This should always be the last! */
};
-enum cpu_register_t {
- RTE_REG_EAX = 0,
- RTE_REG_EBX,
- RTE_REG_ECX,
- RTE_REG_EDX,
-};
-
-static inline void
-rte_cpu_get_features(uint32_t leaf, uint32_t subleaf, cpuid_registers_t out)
-{
-#if defined(__i386__) && defined(__PIC__)
- /* %ebx is a forbidden register if we compile with -fPIC or -fPIE */
- asm volatile("movl %%ebx,%0 ; cpuid ; xchgl %%ebx,%0"
- : "=r" (out[RTE_REG_EBX]),
- "=a" (out[RTE_REG_EAX]),
- "=c" (out[RTE_REG_ECX]),
- "=d" (out[RTE_REG_EDX])
- : "a" (leaf), "c" (subleaf));
-#else
-
- asm volatile("cpuid"
- : "=a" (out[RTE_REG_EAX]),
- "=b" (out[RTE_REG_EBX]),
- "=c" (out[RTE_REG_ECX]),
- "=d" (out[RTE_REG_EDX])
- : "a" (leaf), "c" (subleaf));
-
-#endif
-}
-
-static inline int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
-{
- const struct feature_entry *feat;
- cpuid_registers_t regs;
-
-
- if (feature >= RTE_CPUFLAG_NUMFLAGS)
- /* Flag does not match anything in the feature tables */
- return -ENOENT;
-
- feat = &rte_cpu_feature_table[feature];
-
- if (!feat->leaf)
- /* This entry in the table wasn't filled out! */
- return -EFAULT;
-
- rte_cpu_get_features(feat->leaf & 0xffff0000, 0, regs);
- if (((regs[RTE_REG_EAX] ^ feat->leaf) & 0xffff0000) ||
- regs[RTE_REG_EAX] < feat->leaf)
- return 0;
-
- /* get the cpuid leaf containing the desired feature */
- rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
-
- /* check if the feature is enabled */
- return (regs[feat->reg] >> feat->bit) & 1;
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/generic/rte_cpuflags.h b/lib/librte_eal/common/include/generic/rte_cpuflags.h
index 3ca2e36..c1da357 100644
--- a/lib/librte_eal/common/include/generic/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/generic/rte_cpuflags.h
@@ -39,10 +39,7 @@
* Architecture specific API to determine available CPU features at runtime.
*/
-#include <stdlib.h>
-#include <stdio.h>
#include <errno.h>
-#include <stdint.h>
/**
* Enumeration of all CPU features supported
@@ -50,49 +47,6 @@
enum rte_cpu_flag_t;
/**
- * Enumeration of CPU registers
- */
-#ifdef __DOXYGEN__
-enum cpu_register_t;
-#endif
-
-typedef uint32_t cpuid_registers_t[4];
-
-#define CPU_FLAG_NAME_MAX_LEN 64
-
-/**
- * Struct to hold a processor feature entry
- */
-struct feature_entry {
- uint32_t leaf; /**< cpuid leaf */
- uint32_t subleaf; /**< cpuid subleaf */
- uint32_t reg; /**< cpuid register */
- uint32_t bit; /**< cpuid register bit */
- char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
-};
-
-#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
- [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
-
-/**
- * An array that holds feature entries
- *
- * Defined in arch-specific rte_cpuflags.h.
- */
-#ifdef __DOXYGEN__
-static const struct feature_entry cpu_feature_table[];
-#endif
-
-/**
- * Execute CPUID instruction and get contents of a specific register
- *
- * This function, when compiled with GCC, will generate architecture-neutral
- * code, as per GCC manual.
- */
-static inline void
-rte_cpu_get_features(uint32_t leaf, uint32_t subleaf, cpuid_registers_t out);
-
-/**
* Get name of CPU flag
*
* @param feature
@@ -114,10 +68,8 @@ rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
* 0 if flag is not available
* -ENOENT if flag is invalid
*/
-#ifdef __DOXYGEN__
-static inline int
+int
rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
-#endif
/**
* This function checks that the currently used CPU supports the CPU features
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index d8a5978..b06825a 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -142,7 +142,6 @@ DPDK_2.2 {
DPDK_2.3 {
global:
- rte_cpu_feature_table;
rte_cpu_get_flag_name;
} DPDK_2.2;
--
2.7.0
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags
2016-02-02 22:59 3% [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Thomas Monjalon
2016-02-02 23:10 1% ` [dpdk-dev] [PATCH v1 2/5] eal: move CPU flag functions out of headers Thomas Monjalon
@ 2016-02-02 23:51 0% ` Jan Viktorin
2016-02-03 13:38 0% ` Jerin Jacob
2 siblings, 0 replies; 200+ results
From: Jan Viktorin @ 2016-02-02 23:51 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
Hello Thomas,
the patch set fails when compiling for ARMv7 with the following (full
build.log is attached):
/var/lib/jenkins/jobs/dpdk-armv7-testing/workspace/lib/librte_eal/common/arch/arm/rte_cpuflags.c:114:22: error: ‘REG_PLATFORM’ undeclared here (not in a function)
FEAT_DEF(V7L, REG_PLATFORM, 0)
^
/var/lib/jenkins/jobs/dpdk-armv7-testing/workspace/lib/librte_eal/common/arch/arm/rte_cpuflags.c:71:26: note: in definition of macro ‘FEAT_DEF’
[RTE_CPUFLAG_##name] = {reg, bit, #name},
^
/var/lib/jenkins/jobs/dpdk-armv7-testing/workspace/lib/librte_eal/common/arch/arm/rte_cpuflags.c: In function ‘rte_cpu_get_features’:
/var/lib/jenkins/jobs/dpdk-armv7-testing/workspace/lib/librte_eal/common/arch/arm/rte_cpuflags.c:144:8: error: array subscript is not an integer
out[REG_PLATFORM] = 0x0001;
^
/var/lib/jenkins/jobs/dpdk-armv7-testing/workspace/lib/librte_eal/common/arch/arm/rte_cpuflags.c:144:5: error: statement with no effect [-Werror=unused-value]
out[REG_PLATFORM] = 0x0001;
^
cc1: all warnings being treated as errors
Regards
Jan
On Tue, 2 Feb 2016 23:59:48 +0100
Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> Following the work of Ferruh, I suggest this cleanup to remove as much
> as possible of the code from the cpuflags headers.
> The goal is to un-inline these functions (not performance sensitive)
> and remove the CPU flags table from the ABI (just added recently).
> The bonus is to stop mimic x86 in ARM and PPC implementations.
>
> WARNING: it has not been tested nor compiled on Tilera, ARM and POWER8.
> Please help, thank you.
>
> Thomas Monjalon (5):
> eal: get CPU flag name
> eal: move CPU flag functions out of headers
> eal/arm: adapt CPU flags check to the arch
> eal/ppc: adapt CPU flags check to the arch
> eal: remove compiler optimization workaround
>
> app/test/test_hash_scaling.c | 2 +
> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 +-
> lib/librte_eal/common/arch/arm/rte_cpuflags.c | 170 ++++++++++++++++-----
> lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c | 145 +++++++++++++-----
> lib/librte_eal/common/arch/tile/rte_cpuflags.c | 11 ++
> lib/librte_eal/common/arch/x86/rte_cpuflags.c | 91 +++++++++++
> lib/librte_eal/common/eal_common_cpuflags.c | 18 +--
> .../common/include/arch/arm/rte_cpuflags_32.h | 78 ----------
> .../common/include/arch/arm/rte_cpuflags_64.h | 79 ----------
> .../common/include/arch/ppc_64/rte_cpuflags.h | 64 --------
> .../common/include/arch/tile/rte_cpuflags.h | 29 ----
> .../common/include/arch/x86/rte_cpuflags.h | 66 --------
> .../common/include/generic/rte_cpuflags.h | 56 ++-----
> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 3 +-
> 14 files changed, 364 insertions(+), 450 deletions(-)
>
--
Jan Viktorin E-mail: Viktorin@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 2/7] lib/librte_ether: support l2 tunnel config
@ 2016-02-03 3:36 3% ` Stephen Hemminger
2016-02-03 8:08 3% ` Lu, Wenzhuo
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2016-02-03 3:36 UTC (permalink / raw)
To: Wenzhuo Lu; +Cc: dev
On Tue, 2 Feb 2016 14:57:00 +0800
Wenzhuo Lu <wenzhuo.lu@intel.com> wrote:
> +/**
> + * l2 tunnel configuration.
> + */
> +struct rte_eth_l2_tunnel {
> + enum rte_eth_l2_tunnel_type l2_tunnel_type;
> + uint16_t ether_type;
> +};
Building an API with an indirect (structure) parameter with only two
elements seems like overkill. If you are building it to support future
features, that won't work because it will break ABI.
Why not just?
int
rte_eth_dev_etag_enable(uint8_t port_id, uint16_t ether_type)
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 2/7] lib/librte_ether: support l2 tunnel config
2016-02-03 3:36 3% ` Stephen Hemminger
@ 2016-02-03 8:08 3% ` Lu, Wenzhuo
0 siblings, 0 replies; 200+ results
From: Lu, Wenzhuo @ 2016-02-03 8:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
Hi Stephen,
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Wednesday, February 3, 2016 11:36 AM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 2/7] lib/librte_ether: support l2 tunnel config
>
> On Tue, 2 Feb 2016 14:57:00 +0800
> Wenzhuo Lu <wenzhuo.lu@intel.com> wrote:
>
> > +/**
> > + * l2 tunnel configuration.
> > + */
> > +struct rte_eth_l2_tunnel {
> > + enum rte_eth_l2_tunnel_type l2_tunnel_type;
> > + uint16_t ether_type;
> > +};
>
> Building an API with an indirect (structure) parameter with only two elements
> seems like overkill. If you are building it to support future features, that won't
> work because it will break ABI.
>
> Why not just?
>
> int
> rte_eth_dev_etag_enable(uint8_t port_id, uint16_t ether_type)
I'm trying to make the rte ops can support future features, because there're some similar technology 802.1Qbg, 802.1Qbh, 802.1BR, VN-tag.
And after applying all the patches in this patch set, the struct rte_eth_l2_tunnel will be like this,
struct rte_eth_l2_tunnel {
enum rte_eth_l2_tunnel_type l2_tunnel_type;
uint16_t ether_type;
uint32_t tunnel_id; /* port tag id for e-tag */
};
If we want to support a new type of tunnel which can be described by ether type and tunnel id, we need not to extend this structure. We
only need to add new value for l2_tunnel_type. I think it's not an ABI change.
And I think using a l2 tunnel to cover all these tunnels can make interface simple :)
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir
@ 2016-02-03 8:32 4% ` Rahul Lakkireddy
0 siblings, 0 replies; 200+ results
From: Rahul Lakkireddy @ 2016-02-03 8:32 UTC (permalink / raw)
To: dev; +Cc: Kumar Sanghvi, Nirranjan Kirubaharan
Add a new raw packet flow that allows specifying generic flow input.
Add the ability to provide masks for fields in flow to allow range of
values.
Add a new behavior switch.
Add the ability to provide behavior arguments to allow rewriting matched
fields with new values. Ex: allows to provide new ip and port addresses
to rewrite the fields of packets matching a filter rule before NAT'ing.
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
---
doc/guides/rel_notes/release_2_3.rst | 3 +++
lib/librte_ether/rte_eth_ctrl.h | 15 ++++++++++++++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..19ce954 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,9 @@ API Changes
ABI Changes
-----------
+* New flow type ``RTE_ETH_FLOW_RAW_PKT`` had been introduced and hence
+ ``RTE_ETH_FLOW_MAX`` had been increased to 19.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index ce224ad..1bc0d03 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -74,7 +74,8 @@ extern "C" {
#define RTE_ETH_FLOW_IPV6_EX 15
#define RTE_ETH_FLOW_IPV6_TCP_EX 16
#define RTE_ETH_FLOW_IPV6_UDP_EX 17
-#define RTE_ETH_FLOW_MAX 18
+#define RTE_ETH_FLOW_RAW_PKT 18
+#define RTE_ETH_FLOW_MAX 19
/**
* Feature filter types
@@ -499,6 +500,9 @@ struct rte_eth_tunnel_flow {
struct ether_addr mac_addr; /**< Mac address to match. */
};
+/**< Max length of raw packet in bytes. */
+#define RTE_ETH_RAW_PKT_FLOW_MAX_LEN 256
+
/**
* An union contains the inputs for all types of flow
*/
@@ -514,6 +518,7 @@ union rte_eth_fdir_flow {
struct rte_eth_ipv6_flow ipv6_flow;
struct rte_eth_mac_vlan_flow mac_vlan_flow;
struct rte_eth_tunnel_flow tunnel_flow;
+ uint8_t raw_pkt_flow[RTE_ETH_RAW_PKT_FLOW_MAX_LEN];
};
/**
@@ -534,6 +539,8 @@ struct rte_eth_fdir_input {
uint16_t flow_type;
union rte_eth_fdir_flow flow;
/**< Flow fields to match, dependent on flow_type */
+ union rte_eth_fdir_flow flow_mask;
+ /**< Mask for the fields matched, dependent on flow */
struct rte_eth_fdir_flow_ext flow_ext;
/**< Additional fields to match */
};
@@ -545,6 +552,7 @@ enum rte_eth_fdir_behavior {
RTE_ETH_FDIR_ACCEPT = 0,
RTE_ETH_FDIR_REJECT,
RTE_ETH_FDIR_PASSTHRU,
+ RTE_ETH_FDIR_SWITCH,
};
/**
@@ -558,6 +566,9 @@ enum rte_eth_fdir_status {
RTE_ETH_FDIR_REPORT_FLEX_8, /**< Report 8 flex bytes. */
};
+/**< Max # of behavior arguments */
+#define RTE_ETH_BEHAVIOR_ARG_MAX_LEN 256
+
/**
* A structure used to define an action when match FDIR packet filter.
*/
@@ -569,6 +580,8 @@ struct rte_eth_fdir_action {
/**< If report_status is RTE_ETH_FDIR_REPORT_ID_FLEX_4 or
RTE_ETH_FDIR_REPORT_FLEX_8, flex_off specifies where the reported
flex bytes start from in flexible payload. */
+ uint8_t behavior_arg[RTE_ETH_BEHAVIOR_ARG_MAX_LEN];
+ /**< Extra arguments for behavior taken */
};
/**
--
2.5.3
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags
2016-02-02 22:59 3% [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Thomas Monjalon
2016-02-02 23:10 1% ` [dpdk-dev] [PATCH v1 2/5] eal: move CPU flag functions out of headers Thomas Monjalon
2016-02-02 23:51 0% ` [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Jan Viktorin
@ 2016-02-03 13:38 0% ` Jerin Jacob
2016-02-03 14:01 0% ` Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2016-02-03 13:38 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, viktorin
On Tue, Feb 02, 2016 at 11:59:48PM +0100, Thomas Monjalon wrote:
> Following the work of Ferruh, I suggest this cleanup to remove as much
> as possible of the code from the cpuflags headers.
> The goal is to un-inline these functions (not performance sensitive)
> and remove the CPU flags table from the ABI (just added recently).
> The bonus is to stop mimic x86 in ARM and PPC implementations.
>
> WARNING: it has not been tested nor compiled on Tilera, ARM and POWER8.
> Please help, thank you.
compilation errors on arm64 too.
arm64 toolchains are publicly available @
http://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu/
➜ [master] thunderx [dpdk-master] $ make
== Build lib
== Build lib/librte_compat
== Build lib/librte_eal
== Build lib/librte_eal/common
== Build lib/librte_eal/linuxapp
== Build lib/librte_eal/linuxapp/igb_uio
(cat /dev/null; echo
kernel//home/jerin/dpdk-master/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.ko;)
> /home/jerin/dpdk-master/build/build/lib/librte_eal/linuxapp/igb_uio/modules.order
Building modules, stage 2.
MODPOST 1 modules
== Build lib/librte_eal/linuxapp/eal
CC rte_cpuflags.o
/home/jerin/dpdk-master/lib/librte_eal/common/arch/arm/rte_cpuflags.c:83:20:
error: ‘REG_PLATFORM’ undeclared here (not in a function)
FEAT_DEF(AARCH64, REG_PLATFORM, 1)
^
/home/jerin/dpdk-master/lib/librte_eal/common/arch/arm/rte_cpuflags.c:71:26:
note: in definition of macro ‘FEAT_DEF’
[RTE_CPUFLAG_##name] = {reg, bit, #name},
^
/home/jerin/dpdk-master/lib/librte_eal/common/arch/arm/rte_cpuflags.c:
In function ‘rte_cpu_get_features’:
/home/jerin/dpdk-master/lib/librte_eal/common/arch/arm/rte_cpuflags.c:144:8:
error: array subscript is not an integer
out[REG_PLATFORM] = 0x0001;
^
/home/jerin/dpdk-master/lib/librte_eal/common/arch/arm/rte_cpuflags.c:144:5:
error: statement with no effect [-Werror=unused-value]
out[REG_PLATFORM] = 0x0001;
^
cc1: all warnings being treated as errors
/home/jerin/dpdk-master/mk/internal/rte.compile-pre.mk:126: recipe for
target 'rte_cpuflags.o' failed
make[5]: *** [rte_cpuflags.o] Error 1
/home/jerin/dpdk-master/mk/rte.subdir.mk:61: recipe for target 'eal'
failed
make[4]: *** [eal] Error 2
/home/jerin/dpdk-master/mk/rte.subdir.mk:61: recipe for target
'linuxapp' failed
make[3]: *** [linuxapp] Error 2
/home/jerin/dpdk-master/mk/rte.subdir.mk:61: recipe for target
'librte_eal' failed
make[2]: *** [librte_eal] Error 2
/home/jerin/dpdk-master/mk/rte.sdkbuild.mk:77: recipe for target 'lib'
failed
make[1]: *** [lib] Error 2
/home/jerin/dpdk-master/mk/rte.sdkroot.mk:123: recipe for target 'all'
failed
make: *** [all] Error 2
>
> Thomas Monjalon (5):
> eal: get CPU flag name
> eal: move CPU flag functions out of headers
> eal/arm: adapt CPU flags check to the arch
> eal/ppc: adapt CPU flags check to the arch
> eal: remove compiler optimization workaround
>
> app/test/test_hash_scaling.c | 2 +
> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 +-
> lib/librte_eal/common/arch/arm/rte_cpuflags.c | 170 ++++++++++++++++-----
> lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c | 145 +++++++++++++-----
> lib/librte_eal/common/arch/tile/rte_cpuflags.c | 11 ++
> lib/librte_eal/common/arch/x86/rte_cpuflags.c | 91 +++++++++++
> lib/librte_eal/common/eal_common_cpuflags.c | 18 +--
> .../common/include/arch/arm/rte_cpuflags_32.h | 78 ----------
> .../common/include/arch/arm/rte_cpuflags_64.h | 79 ----------
> .../common/include/arch/ppc_64/rte_cpuflags.h | 64 --------
> .../common/include/arch/tile/rte_cpuflags.h | 29 ----
> .../common/include/arch/x86/rte_cpuflags.h | 66 --------
> .../common/include/generic/rte_cpuflags.h | 56 ++-----
> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 3 +-
> 14 files changed, 364 insertions(+), 450 deletions(-)
>
> --
> 2.5.2
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags
2016-02-03 13:38 0% ` Jerin Jacob
@ 2016-02-03 14:01 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2016-02-03 14:01 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev, viktorin
2016-02-03 19:08, Jerin Jacob:
> On Tue, Feb 02, 2016 at 11:59:48PM +0100, Thomas Monjalon wrote:
> > Following the work of Ferruh, I suggest this cleanup to remove as much
> > as possible of the code from the cpuflags headers.
> > The goal is to un-inline these functions (not performance sensitive)
> > and remove the CPU flags table from the ABI (just added recently).
> > The bonus is to stop mimic x86 in ARM and PPC implementations.
> >
> > WARNING: it has not been tested nor compiled on Tilera, ARM and POWER8.
> > Please help, thank you.
>
> compilation errors on arm64 too.
Yes I forgot REG_PLATFORM.
> arm64 toolchains are publicly available @
> http://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu/
Yes I know, thank you.
I will test and make a v2.
Do you have any comment on the changes?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mempool: Reduce rte_mempool structure size
2016-02-02 23:02 2% [dpdk-dev] [PATCH] mempool: Reduce rte_mempool structure size Keith Wiles
@ 2016-02-03 17:11 0% ` Ananyev, Konstantin
0 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2016-02-03 17:11 UTC (permalink / raw)
To: Wiles, Keith, dev
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Keith Wiles
> Sent: Tuesday, February 02, 2016 11:03 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] mempool: Reduce rte_mempool structure size
>
> The rte_mempool structure is changed, which will cause an ABI change
> for this structure.
>
> Allow mempool cache support to be dynamic depending on if the
> mempool being created needs cache support. Saves about 1.5M of
> memory used by the rte_mempool structure. Performance does not seem
> to be effected running l3fwd and the test_mempool execution passed.
>
> Allocating small mempools which do not require cache can consume
> larges amounts of memory if you have a number of these mempools.
>
> Signed-off-by: Keith Wiles <keith.wiles@intel.com>
> ---
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
^ permalink raw reply [relevance 0%]
Results 1401-1600 of ~18000 next (newer) | prev (older) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2015-10-20 2:41 [dpdk-dev] [PATCH] doc: Add missing new line before code block Tetsuya Mukawa
2015-10-28 9:33 ` Mcnamara, John
2015-12-07 3:43 0% ` Thomas Monjalon
2015-10-25 21:59 [dpdk-dev] [PATCH v6 0/5] ethdev: add speed capabilities and refactor link API Marc Sune
2016-01-29 0:42 ` [dpdk-dev] [PATCH v7 " Marc Sune
2016-01-29 0:42 8% ` [dpdk-dev] [PATCH v7 4/5] doc: update with link changes Marc Sune
2015-11-05 18:31 [dpdk-dev] [RFC 0/5] virtio support for container Jianfeng Tan
2016-01-10 11:42 ` [dpdk-dev] [PATCH 0/4] " Jianfeng Tan
2016-01-10 11:42 2% ` [dpdk-dev] [PATCH 1/4] mem: add --single-file to create single mem-backed file Jianfeng Tan
2016-01-10 11:43 ` [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info Jianfeng Tan
2016-01-11 20:26 ` Rich Lane
2016-01-12 9:12 ` Tan, Jianfeng
2016-01-12 10:04 3% ` Pavel Fedin
2016-01-12 10:48 0% ` Tan, Jianfeng
2016-01-12 11:00 0% ` Pavel Fedin
2016-01-12 11:07 0% ` Sergio Gonzalez Monroy
2016-01-12 11:37 ` Pavel Fedin
2016-01-12 12:12 ` Sergio Gonzalez Monroy
2016-01-12 13:57 3% ` Pavel Fedin
2016-01-12 14:13 4% ` Sergio Gonzalez Monroy
2016-01-12 11:44 3% ` Sergio Gonzalez Monroy
2015-11-09 16:48 [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size Nelio Laranjeiro
2015-11-09 16:48 ` [dpdk-dev] [PATCH 2/2] doc: announce ABI change for RETA configuration Nelio Laranjeiro
2015-12-14 14:25 4% ` Thomas Monjalon
2015-12-14 15:09 7% ` Olga Shern
2015-12-15 5:32 4% ` Lu, Wenzhuo
2015-12-15 6:14 4% ` Thomas Monjalon
2015-11-10 17:29 ` [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size Mcnamara, John
2015-12-14 14:13 4% ` Thomas Monjalon
2015-12-14 14:54 7% ` Olga Shern
2015-12-15 6:11 4% ` Thomas Monjalon
2015-11-10 3:11 [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_fdir_flow Jingjing Wu
2015-11-12 3:10 ` Lu, Wenzhuo
2015-12-15 6:46 4% ` Thomas Monjalon
2015-11-10 3:49 [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_filter_conf Jingjing Wu
2015-11-12 3:11 ` Lu, Wenzhuo
2015-12-15 6:52 4% ` Thomas Monjalon
2015-12-14 14:35 4% ` Thomas Monjalon
2015-11-13 5:20 [dpdk-dev] [PATCH v4 2/2] vhost: Add VHOST PMD Tetsuya Mukawa
2015-11-24 9:00 ` [dpdk-dev] [PATCH v5 0/3] " Tetsuya Mukawa
2015-12-08 1:12 3% ` Tetsuya Mukawa
2015-12-08 2:03 0% ` Yuanhan Liu
2015-12-08 2:10 0% ` Tetsuya Mukawa
2015-11-20 12:46 [dpdk-dev] [PATCH v4] doc: add contributors guide John McNamara
2015-12-14 20:32 2% ` [dpdk-dev] [PATCH v2] " John McNamara
2015-12-14 20:45 2% ` [dpdk-dev] [PATCH v5] " John McNamara
2015-11-20 15:34 [dpdk-dev] [PATCH v9 0/3] User-space ethtool sample application Remy Horton
2015-12-07 13:48 3% ` [dpdk-dev] [PATCH v10 0/4] " Remy Horton
2015-12-07 13:48 4% ` [dpdk-dev] [PATCH v10 1/4] Remove ABI requirement for external library builds Remy Horton
2015-12-02 3:43 [dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support Yuanhan Liu
2015-12-02 3:43 ` [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request Yuanhan Liu
2015-12-02 13:53 ` Panu Matilainen
2015-12-06 23:07 3% ` Thomas Monjalon
2015-12-07 2:00 0% ` Yuanhan Liu
2015-12-07 2:03 0% ` Thomas Monjalon
2015-12-07 2:18 3% ` Yuanhan Liu
2015-12-07 2:49 0% ` Thomas Monjalon
2015-12-07 6:29 4% ` Panu Matilainen
2015-12-07 11:28 3% ` Thomas Monjalon
2015-12-07 11:41 4% ` Panu Matilainen
2015-12-07 13:55 4% ` Thomas Monjalon
2015-12-07 16:48 4% ` Panu Matilainen
2015-12-07 17:47 0% ` Thomas Monjalon
2015-12-02 16:50 [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range Panu Matilainen
2015-12-03 14:05 ` [dpdk-dev] [PATCH v2] " Panu Matilainen
2015-12-07 14:09 7% ` Panu Matilainen
2015-12-07 14:32 4% ` Thomas Monjalon
2015-12-07 16:08 4% ` Panu Matilainen
2015-12-07 22:38 4% ` Thomas Monjalon
2015-12-03 2:27 [dpdk-dev] [PATCH] vhost: reserve some spaces for virtio_net and vhost_virtqueue struct Yuanhan Liu
2015-12-07 23:54 0% ` Thomas Monjalon
2015-12-03 12:49 [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library Panu Matilainen
2015-12-03 13:51 ` [dpdk-dev] [PATCH v4] " Ferruh Yigit
2015-12-06 14:37 4% ` Thomas Monjalon
2015-12-03 14:59 [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script Neil Horman
2015-12-02 11:44 ` Neil Horman
2015-12-01 13:30 ` Neil Horman
2015-12-08 17:03 5% ` Robie Basak
2015-12-09 14:16 5% ` Neil Horman
2015-12-07 3:01 14% [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf Jijiang Liu
2015-12-07 3:16 7% ` Thomas Monjalon
2015-12-07 3:30 8% ` Liu, Jijiang
2015-12-07 3:40 4% ` Thomas Monjalon
2015-12-07 7:47 4% ` Liu, Jijiang
2015-12-07 11:43 4% ` Thomas Monjalon
2015-12-07 10:42 4% ` Chilikin, Andrey
2015-12-07 3:25 14% [dpdk-dev] [PATCH] vhost: note the ABI changes Yuanhan Liu
2015-12-14 0:33 4% ` Thomas Monjalon
2015-12-09 5:37 11% [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_flow Jijiang Liu
2015-12-09 5:42 4% ` Lu, Wenzhuo
2015-12-14 15:03 4% ` Thomas Monjalon
2015-12-15 1:17 4% ` Liu, Jijiang
2015-12-15 2:05 7% ` Liu, Jijiang
[not found] <mailman.9342.1448631305.2486.dev@dpdk.org>
2015-12-09 10:40 0% ` [dpdk-dev] dev Digest, Vol 68, Issue 68 Betts, Ian
2015-12-09 16:23 1% [dpdk-dev] [PATCH] doc: add patch submit cheatsheet Harry van Haaren
2015-12-09 17:27 1% ` [dpdk-dev] [PATCH v2] " Harry van Haaren
2015-12-14 10:03 1% ` [dpdk-dev] [PATCH v3] " Harry van Haaren
2015-12-10 14:01 4% [dpdk-dev] [RFC 0/3] ethdev: Enhancements to flow director filter Rahul Lakkireddy
2015-12-10 14:01 ` [dpdk-dev] [RFC 1/3] ethdev: add packet filter flow and new behavior switch to fdir Rahul Lakkireddy
2015-12-10 15:46 3% ` Chilikin, Andrey
2015-12-11 7:08 0% ` Rahul Lakkireddy
2015-12-10 14:01 4% ` [dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support Rahul Lakkireddy
2015-12-15 8:40 7% ` Rahul Lakkireddy
2015-12-15 8:55 4% ` Thomas Monjalon
2015-12-15 13:51 9% ` Rahul Lakkireddy
2015-12-15 13:57 4% ` Thomas Monjalon
2015-12-23 12:41 3% ` [dpdk-dev] [RFC v2 0/2] ethdev: Enhancements to flow director filter Rahul Lakkireddy
2016-01-11 13:50 0% ` Rahul Lakkireddy
2015-12-10 23:27 5% [dpdk-dev] [PATCH] doc: announce API change for rte_ether.h Stephen Hemminger
2015-12-11 9:28 0% ` Panu Matilainen
2015-12-11 16:33 0% ` Stephen Hemminger
2015-12-14 14:54 0% ` Thomas Monjalon
2015-12-14 15:30 0% ` Bruce Richardson
2015-12-14 15:41 0% ` Thomas Monjalon
2015-12-14 16:00 0% ` Bruce Richardson
2015-12-11 2:55 16% [dpdk-dev] [PATCH v2] doc: announce ABI change for struct rte_eth_conf Jijiang Liu
2015-12-13 23:35 [dpdk-dev] [PATCH 0/2] provide rte_pktmbuf_alloc_bulk API and call it in vhost dequeue Huawei Xie
2016-01-26 17:03 ` [dpdk-dev] [PATCH v6 " Huawei Xie
2016-01-26 17:03 ` [dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API Huawei Xie
2016-01-27 13:56 3% ` Panu Matilainen
2015-12-14 0:58 4% [dpdk-dev] [dpdk-announce] release candidate 2.2.0-rc4 Thomas Monjalon
2015-12-14 7:48 21% [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf Jijiang Liu
2015-12-14 9:19 4% ` Chilikin, Andrey
2015-12-14 15:10 4% ` Thomas Monjalon
2015-12-15 3:00 4% ` Liu, Jijiang
2015-12-15 8:50 4% ` Ivan Boule
2015-12-18 2:00 4% ` Liu, Jijiang
2015-12-24 13:28 4% ` Ivan Boule
2015-12-14 18:51 1% [dpdk-dev] [PATCH] doc: fix release notes for 2.2 John McNamara
2015-12-14 18:54 1% [dpdk-dev] Draft " Mcnamara, John
2015-12-15 7:21 9% [dpdk-dev] [PATCH] doc: announce ABI change for link speed Thomas Monjalon
2015-12-15 9:22 12% ` Olga Shern
2015-12-15 10:54 4% ` Adrien Mazarguil
2015-12-15 11:16 4% ` Jan Viktorin
2015-12-15 11:59 4% ` Matej Vido
2015-12-15 12:52 4% ` Thomas Monjalon
[not found] <2237946.VuMj3WOHya@xps13>
[not found] ` <1728569.LYxVzTTiFJ@xps13>
[not found] ` <D52B67DD-3646-4121-B2C2-73E5B27D898B@cesnet.cz>
2015-12-15 11:21 4% ` [dpdk-dev] Urgent - Fwd: " Jan Viktorin
2015-12-15 13:34 2% [dpdk-dev] [PATCH] doc: improve linux guide layout John McNamara
2015-12-15 13:55 15% [dpdk-dev] [PATCH] scripts: fix abi-validator regression when revision is a tag Panu Matilainen
2015-12-15 14:16 4% ` Neil Horman
2015-12-15 14:20 4% ` Thomas Monjalon
2015-12-15 14:10 12% [dpdk-dev] [PATCH] doc: announce ABI change for extending filtering support Rahul Lakkireddy
2015-12-15 14:27 7% ` Thomas Monjalon
2015-12-15 14:15 13% [dpdk-dev] [PATCH] doc: fix ABI announce change for RETA configuration Nelio Laranjeiro
2015-12-15 15:58 8% ` Zhang, Helin
2015-12-15 16:15 4% ` Thomas Monjalon
2015-12-17 11:16 [dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0 Thomas Monjalon
2015-12-17 11:16 5% ` [dpdk-dev] [PATCH 2/2] doc: init next release notes Thomas Monjalon
2015-12-21 13:26 [dpdk-dev] [PATCH 0/3] switch to using YY.MM version numbers Bruce Richardson
2015-12-21 13:26 8% ` [dpdk-dev] [PATCH 3/3] doc: rename release 2.3 to 16.04 Bruce Richardson
2015-12-25 8:29 [dpdk-dev] [PATCH 0/4] extend flow director's IP fields in i40e driver Jingjing Wu
2016-01-26 6:26 ` [dpdk-dev] [PATCH 00/12] extend flow director's " Jingjing Wu
2016-01-26 6:26 4% ` [dpdk-dev] [PATCH 07/12] librte_ether: extend rte_eth_fdir_flow to support tunnel format Jingjing Wu
2015-12-29 2:53 [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe Ziye Yang
2015-12-31 17:12 3% ` Stephen Hemminger
2016-01-13 11:55 3% ` Bruce Richardson
2016-01-13 12:22 3% ` Panu Matilainen
2016-01-28 21:38 4% ` Thomas Monjalon
2016-01-29 9:21 4% ` Panu Matilainen
2016-01-29 9:34 3% ` Thomas Monjalon
2016-01-29 10:10 3% ` Panu Matilainen
2016-01-29 12:47 0% ` Panu Matilainen
2015-12-31 6:53 [dpdk-dev] [PATCH 00/12] Add API to get packet type info Jianfeng Tan
2015-12-31 6:53 ` [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set Jianfeng Tan
2016-01-04 11:38 ` Adrien Mazarguil
2016-01-04 14:36 ` Ananyev, Konstantin
2016-01-05 16:14 ` Nélio Laranjeiro
2016-01-05 16:50 ` Ananyev, Konstantin
2016-01-06 10:00 ` Adrien Mazarguil
2016-01-06 14:29 4% ` Ananyev, Konstantin
2016-01-06 15:44 3% ` Adrien Mazarguil
2016-01-06 16:44 0% ` Ananyev, Konstantin
2016-01-06 17:22 0% ` Adrien Mazarguil
2016-01-07 10:24 0% ` Ananyev, Konstantin
2016-01-07 13:32 0% ` Adrien Mazarguil
2016-01-01 21:05 [dpdk-dev] [RFC 0/7] Support non-PCI devices Jan Viktorin
2016-01-01 21:05 ` [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface Jan Viktorin
2016-01-02 18:01 ` Stephen Hemminger
2016-01-02 18:35 ` Wiles, Keith
2016-01-02 18:52 3% ` Jan Viktorin
2016-01-02 19:13 0% ` Wiles, Keith
2016-01-02 19:14 0% ` Stephen Hemminger
2016-01-02 19:22 0% ` Wiles, Keith
2016-01-02 18:45 4% ` Jan Viktorin
2016-01-04 14:46 [dpdk-dev] [PATCH] vhost: remove lockless enqueue to the virtio ring Huawei Xie
2016-01-05 7:16 4% ` Xie, Huawei
2016-01-04 20:08 2% [dpdk-dev] [PATCH 00/14] Step towards PCI independency Jan Viktorin
[not found] ` <CALwxeUtxE5Gd+UvZOHz+fyHSjLi9Tjkc=99QHpag62KV+UP+NA@mail.gmail.com>
2016-01-11 17:29 ` Jan Viktorin
2016-01-13 14:07 3% ` David Marchand
2016-01-05 22:14 [dpdk-dev] [PATCH] vhost: fix leak of fds and mmaps Rich Lane
2016-01-07 2:31 3% ` Yuanhan Liu
2016-01-07 6:50 0% ` Xie, Huawei
2016-01-06 14:32 4% [dpdk-dev] [PATCH 0/3] ABI changes (RETA, cmdline) Nelio Laranjeiro
2016-01-06 14:32 11% ` [dpdk-dev] [PATCH 1/3] ethdev: change RETA type in rte_eth_rss_reta_entry64 Nelio Laranjeiro
2016-01-06 14:32 5% ` [dpdk-dev] [PATCH 2/3] cmdline: increase command line buffer Nelio Laranjeiro
2016-01-12 10:49 4% ` [dpdk-dev] [PATCH v2 0/3] ABI change for RETA, cmdline Nelio Laranjeiro
2016-01-12 10:49 5% ` [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer Nelio Laranjeiro
2016-01-12 12:46 3% ` Panu Matilainen
2016-01-15 8:44 3% ` Nélio Laranjeiro
2016-01-15 9:00 3% ` Panu Matilainen
2016-01-18 14:38 4% ` Olivier MATZ
2016-01-12 10:49 11% ` [dpdk-dev] [PATCH v2 2/3] ethdev: change RETA type in rte_eth_rss_reta_entry64 Nelio Laranjeiro
2016-01-11 7:07 [dpdk-dev] [PATCH 0/4] Support VxLAN & NVGRE checksum off-load on X550 Wenzhuo Lu
2016-01-11 7:07 ` [dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del Wenzhuo Lu
2016-01-11 7:40 ` Vincent JARDIN
2016-01-11 8:28 3% ` Lu, Wenzhuo
2016-01-11 8:41 3% ` Vincent JARDIN
2016-01-12 12:37 0% ` Thomas Monjalon
2016-01-13 2:50 0% ` Lu, Wenzhuo
2016-01-14 1:38 ` [dpdk-dev] [PATCH v2 0/6] Support VxLAN & NVGRE checksum off-load on X550 Wenzhuo Lu
2016-01-14 1:38 4% ` [dpdk-dev] [PATCH v2 1/6] lib/librte_ether: change function name of tunnel port config Wenzhuo Lu
2016-01-14 10:38 2% [dpdk-dev] Proposal for a big eal / ethdev cleanup David Marchand
2016-01-14 11:46 4% ` Jan Viktorin
2016-01-16 15:53 0% ` David Marchand
2016-01-18 15:49 3% ` Thomas Monjalon
2016-01-18 14:54 0% ` Declan Doherty
[not found] ` <20160118155834.04cb31f2@pcviktorin.fit.vutbr.cz>
2016-01-18 21:11 ` David Marchand
2016-01-19 10:29 ` Jan Viktorin
2016-01-19 10:59 4% ` David Marchand
2016-01-17 3:58 [dpdk-dev] [PATCH] cfgfile: support looking up sections by index Rich Lane
2016-01-19 4:41 ` [dpdk-dev] [PATCH v2] " Rich Lane
2016-01-21 7:42 3% ` Panu Matilainen
2016-01-20 11:25 [dpdk-dev] [PATCH v2] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR) Ananyev, Konstantin
2016-01-21 8:18 ` [dpdk-dev] [PATCH v3] " Wojciech Andralojc
2016-01-21 10:38 ` Panu Matilainen
2016-01-21 10:51 ` Ananyev, Konstantin
2016-01-22 10:05 3% ` Panu Matilainen
2016-01-22 11:05 0% ` Ananyev, Konstantin
2016-01-22 11:37 0% ` Andralojc, WojciechX
2016-01-20 14:28 [dpdk-dev] [PATCH] ethdev: expose link status and speed using xstats Harry van Haaren
2016-01-20 14:45 ` Van Haaren, Harry
2016-01-20 15:03 ` Kyle Larose
2016-01-20 15:13 ` Thomas Monjalon
2016-01-20 18:36 3% ` Stephen Hemminger
2016-01-20 17:18 [dpdk-dev] Future Direction for rte_eth_stats_get() David Harton (dharton)
2016-01-22 14:18 ` Tahhan, Maryam
2016-01-22 14:40 ` David Harton (dharton)
2016-01-22 14:48 ` Thomas Monjalon
2016-01-22 15:22 3% ` Van Haaren, Harry
2016-01-22 15:53 0% ` Jay Rolette
2016-01-22 16:04 0% ` David Harton (dharton)
2016-01-22 16:41 ` Van Haaren, Harry
2016-01-22 19:26 ` David Harton (dharton)
2016-02-01 16:47 3% ` David Harton (dharton)
2016-02-01 21:23 0% ` Matthew Hall
2016-02-02 11:40 3% ` Van Haaren, Harry
2016-01-22 1:37 [dpdk-dev] [PATCH 0/2] i40e setting ether type of VLANs Helin Zhang
2016-01-22 1:37 7% ` [dpdk-dev] [PATCH 1/2] ethdev: add vlan type for setting ether type Helin Zhang
2016-01-25 2:36 9% [dpdk-dev] [PATCH] PCI: ABI change request for adding new field in rte_pci_id structure Ziye Yang
2016-01-25 7:25 [dpdk-dev] [PATCH 0/4] Add tunnel filter support for IP in GRE on i40e Xutao Sun
2016-01-28 7:30 ` [dpdk-dev] [PATCH v2 " Xutao Sun
2016-01-28 7:30 ` [dpdk-dev] [PATCH v2 1/4] lib/ether: optimize the 'rte_eth_tunnel_filter_conf' structure Xutao Sun
2016-01-28 8:21 ` Thomas Monjalon
2016-01-28 9:05 3% ` Sun, Xutao
[not found] ` <1453976778-27807-1-git-send-email-xutao.sun@intel.com>
2016-01-28 10:26 13% ` [dpdk-dev] [PATCH v3 1/4] lib/ether: optimize the'rte_eth_tunnel_filter_conf' structure Xutao Sun
2016-01-25 14:11 3% [dpdk-dev] [PATCH 1/2] librte_pipeline: add support for packet redirection at action handlers Jasvinder Singh
2016-01-26 6:20 [dpdk-dev] [PATCH 00/12] extend flow director's fields in i40e driver Jingjing Wu
2016-01-26 6:20 4% ` [dpdk-dev] [PATCH 07/12] librte_ether: extend rte_eth_fdir_flow to support tunnel format Jingjing Wu
2016-01-26 16:15 [dpdk-dev] [PATCH V1 1/1] jobstats: added function abort for job Marcin Kerlin
2016-01-27 13:37 3% ` Panu Matilainen
2016-01-27 15:57 0% ` Jastrzebski, MichalX K
2016-01-28 7:41 3% ` Panu Matilainen
2016-01-27 8:37 3% [dpdk-dev] [PATCH] ethdev: fix byte order inconsistence between fdir flow and mask Jingjing Wu
2016-01-27 9:19 0% ` Thomas Monjalon
2016-01-28 5:55 0% ` Wu, Jingjing
2016-02-01 2:48 3% ` [dpdk-dev] [PATCH v2] " Jingjing Wu
[not found] <1453911849-16562-1-git-send-email-ferruh.yigit@intel.com>
2016-01-27 16:24 1% ` [dpdk-dev] [PATCH 2/3] rte_ctrl_if: add control interface library Ferruh Yigit
2016-01-27 17:39 [dpdk-dev] [PATCH 0/4] Add PCAP support to source and sink port Fan Zhang
2016-01-27 17:39 ` [dpdk-dev] [PATCH 1/4] lib/librte_port: add PCAP file support to source port Fan Zhang
2016-01-28 11:54 4% ` Panu Matilainen
2016-01-29 15:10 4% ` Zhang, Roy Fan
2016-01-28 8:40 4% [dpdk-dev] [PATCH 0/3] support setting i40e VF MAC address from DPDK host side Helin Zhang
2016-01-28 8:40 4% ` [dpdk-dev] [PATCH 1/3] i40e: add setting VF MAC address in DPDK PF host Helin Zhang
2016-01-28 19:02 7% [dpdk-dev] [RFC] ABI breakage for rte_mempool to reduce footprint Wiles, Keith
2016-01-28 20:07 7% [dpdk-dev] [RFC] Abi " Wiles, Keith
2016-01-29 7:03 [dpdk-dev] [PATCH 0/8] support E-tag offloading and forwarding on Intel X550 NIC Wenzhuo Lu
2016-02-02 6:56 ` [dpdk-dev] [PATCH v2 0/7] " Wenzhuo Lu
2016-02-02 6:57 ` [dpdk-dev] [PATCH v2 2/7] lib/librte_ether: support l2 tunnel config Wenzhuo Lu
2016-02-03 3:36 3% ` Stephen Hemminger
2016-02-03 8:08 3% ` Lu, Wenzhuo
2016-02-01 15:24 9% [dpdk-dev] [PATCH v1] doc: add example text to release notes John McNamara
2016-02-02 1:37 [dpdk-dev] rings PMD detaching Mauricio Vásquez
2016-02-02 5:41 3% ` David Marchand
2016-02-02 22:59 3% [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Thomas Monjalon
2016-02-02 23:10 1% ` [dpdk-dev] [PATCH v1 2/5] eal: move CPU flag functions out of headers Thomas Monjalon
2016-02-02 23:51 0% ` [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Jan Viktorin
2016-02-03 13:38 0% ` Jerin Jacob
2016-02-03 14:01 0% ` Thomas Monjalon
2016-02-02 23:02 2% [dpdk-dev] [PATCH] mempool: Reduce rte_mempool structure size Keith Wiles
2016-02-03 17:11 0% ` Ananyev, Konstantin
2016-02-03 8:32 [dpdk-dev] [PATCH 00/10] cxgbe: Add flow director support Rahul Lakkireddy
2016-02-03 8:32 4% ` [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir Rahul Lakkireddy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).