* 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, 0 replies; 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 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 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 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 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
0 siblings, 0 replies; 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 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 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 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 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%]
* [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%]
* [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 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%]
* 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%]
* 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] [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 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] [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%]
* [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 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%]
* 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] 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] 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 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 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 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%]
* [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%]
* [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 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%]
* 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%]
* 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%]
* [dpdk-dev] [PATCH 00/14] Step towards PCI independency
@ 2016-01-04 20:08 2% Jan Viktorin
0 siblings, 0 replies; 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] [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%]
* 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 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
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: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] [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] [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%]
* [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%]
* [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%]
* 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 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] 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%]
* 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: 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] 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] 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%]
* [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%]
* [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%]
* 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] 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 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] 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] [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%]
* 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] 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
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] [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
` (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] [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 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-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%]
* [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] [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%]
* 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 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 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
2 siblings, 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-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 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] 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] 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%]
* [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%]
* [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] 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] 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%]
* 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%]
* 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 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 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 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 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] 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 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 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 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 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
2 siblings, 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%]
* [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 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: 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%]
* [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%]
* 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%]
* 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] 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] [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%]
* [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%]
* [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%]
* 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] [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%]
* [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] [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] [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%]
* 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%]
* 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] 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%]
* [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] 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%]
* 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 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 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] vhost: reserve some spaces for virtio_net and vhost_virtqueue struct
2015-12-03 2:27 3% [dpdk-dev] [PATCH] vhost: reserve some spaces for virtio_net and vhost_virtqueue struct Yuanhan Liu
@ 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 v2] scripts: support any legal git revisions as abi validation range
2015-12-03 14:05 36% ` [dpdk-dev] [PATCH v2] " Panu Matilainen
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 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 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 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 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-03 14:05 36% ` [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 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 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%]
* [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] 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%]
* 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 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] 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] 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 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: 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] 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: 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%]
* [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: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] 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 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%]
* 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: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-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-02 13:53 4% ` Panu Matilainen
2015-12-02 14:31 5% ` Yuanhan Liu
@ 2015-12-06 23:07 3% ` Thomas Monjalon
2015-12-07 2:00 0% ` Yuanhan Liu
2015-12-07 6:29 4% ` Panu Matilainen
1 sibling, 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 v4] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 13:51 4% ` [dpdk-dev] [PATCH v4] " Ferruh Yigit
@ 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 v8 0/4] examples: add performance-thread
2015-12-05 21:21 0% ` Thomas Monjalon
@ 2015-12-06 6:17 0% ` Betts, Ian
0 siblings, 0 replies; 200+ results
From: Betts, Ian @ 2015-12-06 6:17 UTC (permalink / raw)
To: Thomas Monjalon, Stephen Hemminger, Glynn, Michael J; +Cc: dev
-----Original Message-----
From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
Sent: Saturday, December 5, 2015 9:21 PM
To: Stephen Hemminger; Glynn, Michael J; Betts, Ian
Cc: dev@dpdk.org; O'Driscoll, Tim; Richardson, Bruce
Subject: Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
> > > Intel may have some milestone to get it into DPDK 2.2 but really
> > > this seems too late...
> >
> > >>>Yes, sure it is too late to have enough discussions in 2.2
> > >>>timeframe
> > >Just to understand what we mean by too late...
> > >The original RFC was issued on 2nd September.
> > >Thus there have been some three months available for discussion, and for people to raise any questions or concerns.
> > >The first patch was available on 30th September, and a number of
> > >subsequent patch versions have been issued, meaning the code has been available for review for two month As mentioned in the reply to Stephen, there has been no adverse feedback during this period.
> > >/Ian
> >
> > Hi Thomas/Stephen
> >
> > I agree with Ian, how much time is expected for a discussion to happen?
> >
> > As Ian stated, the feature was stated in our 2.2 planned feature list, we created a RFC over 3 months ago, and there's been code available for review for over 2 months now! (not to mention several version updates, docs, etc.).
> > Given this, I believe that there has been ample time for the community to review and provide feedback rather than waiting until the eve of RC3 and then requesting more time.
> >
> > In addition, by making it a sample application first people can test
> > it, see if it's useful, and further enhance it. Based on usefulness
> > and feedback, we can then decide whether to make it a DPDK library
> > in a future release, make it a separate library somewhere else, or
> > do nothing further on it
> >
> > For these reasons, I believe it should be merged into RC3
I am not against this idea.
I just say that we have no time anymore for discussions.
There was no review probably because it is "just" an example.
Given that the code is huge, it would be better to have some good feedback for its integration. But it does not hurt to integrate anyway.
The only problem is the maintenance overload. When we change something in a library, every examples must be updated to keep them working.
That's why we must avoid keeping some useless examples.
So this one must be discussed during the 2.3 cycle and will see if we keep it, shrink it, revert it or move to a library.
> Since it is an example and well documented that is fine.
> Is there an explicit statement that ABI is not binding for examples?
>What do you mean by "binding"?
I think these are fair comments.
I do take the point about maintenance overhead, there is no value in dragging along
something that is not being used. After making it available and allowing time for
users to explore we can gauge the answer best.
Feedback should inform the direction, and whilst we do continue pathfinding activity internally,
in fact we had not planned any updates during the 2.3 cycle, precisely to allow time
to understand if/how the community would like to see it evolve.
So personally I see 2.4 as an appropriate target to implement whatever we decide.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
2015-12-05 19:47 3% ` Stephen Hemminger
@ 2015-12-05 21:21 0% ` Thomas Monjalon
2015-12-06 6:17 0% ` Betts, Ian
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-05 21:21 UTC (permalink / raw)
To: Stephen Hemminger, Glynn, Michael J, Betts, Ian; +Cc: dev
> > > Intel may have some milestone to get it into DPDK 2.2 but really this
> > > seems too late...
> >
> > >>>Yes, sure it is too late to have enough discussions in 2.2 timeframe
> > >Just to understand what we mean by too late...
> > >The original RFC was issued on 2nd September.
> > >Thus there have been some three months available for discussion, and for people to raise any questions or concerns.
> > >The first patch was available on 30th September, and a number of subsequent patch versions have been issued, meaning the code has been available for review for two month
> > >As mentioned in the reply to Stephen, there has been no adverse feedback during this period.
> > >/Ian
> >
> > Hi Thomas/Stephen
> >
> > I agree with Ian, how much time is expected for a discussion to happen?
> >
> > As Ian stated, the feature was stated in our 2.2 planned feature list, we created a RFC over 3 months ago, and there's been code available for review for over 2 months now! (not to mention several version updates, docs, etc.).
> > Given this, I believe that there has been ample time for the community to review and provide feedback rather than waiting until the eve of RC3 and then requesting more time.
> >
> > In addition, by making it a sample application first people can test it, see if it's useful, and further enhance it. Based on usefulness and feedback, we can then decide whether to make it a DPDK library in a future release, make it a separate library somewhere else, or do nothing further on it
> >
> > For these reasons, I believe it should be merged into RC3
I am not against this idea.
I just say that we have no time anymore for discussions.
There was no review probably because it is "just" an example.
Given that the code is huge, it would be better to have some good feedback
for its integration. But it does not hurt to integrate anyway.
The only problem is the maintenance overload. When we change something in
a library, every examples must be updated to keep them working.
That's why we must avoid keeping some useless examples.
So this one must be discussed during the 2.3 cycle and will see if we
keep it, shrink it, revert it or move to a library.
> Since it is an example and well documented that is fine.
> Is there an explicit statement that ABI is not binding for examples?
What do you mean by "binding"?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
@ 2015-12-05 19:47 3% ` Stephen Hemminger
2015-12-05 21:21 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2015-12-05 19:47 UTC (permalink / raw)
To: Glynn, Michael J; +Cc: dev, Betts, Ian
On Sat, 5 Dec 2015 17:53:04 +0000
"Glynn, Michael J" <michael.j.glynn@intel.com> wrote:
>
>
> -----Original Message-----
> From: Betts, Ian
> Sent: Saturday, December 5, 2015 12:07 PM
> To: Thomas Monjalon; Stephen Hemminger
> Cc: dev@dpdk.org; O'Driscoll, Tim; Richardson, Bruce; Glynn, Michael J
> Subject: RE: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
>
>
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Friday, December 4, 2015 6:34 PM
> To: Stephen Hemminger
> Cc: dev@dpdk.org; Betts, Ian
> Subject: Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
>
> > Intel may have some milestone to get it into DPDK 2.2 but really this
> > seems too late...
>
> >>>Yes, sure it is too late to have enough discussions in 2.2 timeframe
> >Just to understand what we mean by too late...
> >The original RFC was issued on 2nd September.
> >Thus there have been some three months available for discussion, and for people to raise any questions or concerns.
> >The first patch was available on 30th September, and a number of subsequent patch versions have been issued, meaning the code has been available for review for two month
> >As mentioned in the reply to Stephen, there has been no adverse feedback during this period.
> >/Ian
>
> Hi Thomas/Stephen
>
> I agree with Ian, how much time is expected for a discussion to happen?
>
> As Ian stated, the feature was stated in our 2.2 planned feature list, we created a RFC over 3 months ago, and there's been code available for review for over 2 months now! (not to mention several version updates, docs, etc.).
> Given this, I believe that there has been ample time for the community to review and provide feedback rather than waiting until the eve of RC3 and then requesting more time.
>
> In addition, by making it a sample application first people can test it, see if it's useful, and further enhance it. Based on usefulness and feedback, we can then decide whether to make it a DPDK library in a future release, make it a separate library somewhere else, or do nothing further on it
>
> For these reasons, I believe it should be merged into RC3
Since it is an example and well documented that is fine.
Is there an explicit statement that ABI is not binding for examples?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH resend] virtio: fix link state regression
2015-12-04 15:59 3% [dpdk-dev] [PATCH resend] " Stephen Hemminger
@ 2015-12-04 16:18 0% ` Iremonger, Bernard
0 siblings, 0 replies; 200+ results
From: Iremonger, Bernard @ 2015-12-04 16:18 UTC (permalink / raw)
To: Stephen Hemminger, Xie, Huawei, yuanhan.liu; +Cc: dev
Hi Stephen,
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Friday, December 4, 2015 3:59 PM
> To: Xie, Huawei <huawei.xie@intel.com>; yuanhan.liu@linux.intel.com;
> Iremonger, Bernard <bernard.iremonger@intel.com>
> Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>
> Subject: [PATCH resend] virtio: fix link state regression
>
> Support for link state interrupt was broken on virtio by
>
> commit bda66c418c85 ("ethdev: add device fields from PCI layer")
>
> This is caused because the actual value of drv_flags is not set until after the
> resource_init has figured out whether it is using UIO or direct I/O
> instructions.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
> ---
>
> There maybe other drivers with the same problem. It would have been
> better to move the structure elements (and break ABI) rather than assume it
> safe to copy them.
>
> drivers/net/virtio/virtio_ethdev.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_ethdev.c
> b/drivers/net/virtio/virtio_ethdev.c
> index 74c00ee..8e12804 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -1289,11 +1289,11 @@ eth_virtio_dev_init(struct rte_eth_dev
> *eth_dev)
>
> pci_dev = eth_dev->pci_dev;
>
> - rte_eth_copy_pci_info(eth_dev, pci_dev);
> -
> if (virtio_resource_init(pci_dev) < 0)
> return -1;
>
> + rte_eth_copy_pci_info(eth_dev, pci_dev);
> +
> hw->use_msix = virtio_has_msix(&pci_dev->addr);
> hw->io_base = (uint32_t)(uintptr_t)pci_dev-
> >mem_resource[0].addr;
>
> --
> 2.1.4
I think the call to rte_eth_copy_pci_info() needs to be a bit later.
After the following code:
/* If host does not support status then disable LSC */
if (!vtpci_with_feature(hw, VIRTIO_NET_F_STATUS))
pci_dev->driver->drv_flags &= ~RTE_PCI_DRV_INTR_LSC;
I have submitted a patch for this earlier today
http://dpdk.org/dev/patchwork/patch/9345/
Regards,
Bernard.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH resend] virtio: fix link state regression
@ 2015-12-04 15:59 3% Stephen Hemminger
2015-12-04 16:18 0% ` Iremonger, Bernard
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2015-12-04 15:59 UTC (permalink / raw)
To: huawei.xie, yuanhan.liu, bernard.iremonger; +Cc: dev
Support for link state interrupt was broken on virtio by
commit bda66c418c85 ("ethdev: add device fields from PCI layer")
This is caused because the actual value of drv_flags is not set
until after the resource_init has figured out whether it is using
UIO or direct I/O instructions.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
There maybe other drivers with the same problem. It would have
been better to move the structure elements (and break ABI) rather
than assume it safe to copy them.
drivers/net/virtio/virtio_ethdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 74c00ee..8e12804 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1289,11 +1289,11 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
pci_dev = eth_dev->pci_dev;
- rte_eth_copy_pci_info(eth_dev, pci_dev);
-
if (virtio_resource_init(pci_dev) < 0)
return -1;
+ rte_eth_copy_pci_info(eth_dev, pci_dev);
+
hw->use_msix = virtio_has_msix(&pci_dev->addr);
hw->io_base = (uint32_t)(uintptr_t)pci_dev->mem_resource[0].addr;
--
2.1.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] virtio: fix link state regression
2015-12-04 15:25 0% ` Iremonger, Bernard
@ 2015-12-04 15:27 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-04 15:27 UTC (permalink / raw)
To: Iremonger, Bernard; +Cc: dev
2015-12-04 15:25, Iremonger, Bernard:
> From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
> > On Thu, Dec 03, 2015 at 06:08:24PM -0800, Stephen Hemminger wrote:
> > > Support for link state interrupt was broken on virtio by
> > >
> > > commit bda66c418c85 ("ethdev: add device fields from PCI layer")
> > >
> > > This is caused because the actual value of drv_flags is not set until
> > > after the resource_init has figured out whether it is using UIO or
> > > direct I/O instructions.
> > >
> > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > ---
> > > There maybe other drivers with the same problem. It would have been
> > > better to move the structure elements (and break ABI) rather than
> > > assume it safe to copy them. Better to fail compiling.
> >
> > I see no patch content.
> >
> > --yliu
>
> I have submitted a patch for this issue.
>
> http://dpdk.org/dev/patchwork/patch/9345/
>
> I have checked the other drivers, I found an issue with the bonding PMD.
> I have submitted a patch for this.
>
> http://dpdk.org/dev/patchwork/patch/9342/
>
> The remaining drivers look fine to me.
Thank you Bernard for the quick response.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] virtio: fix link state regression
2015-12-04 3:29 0% ` Yuanhan Liu
@ 2015-12-04 15:25 0% ` Iremonger, Bernard
2015-12-04 15:27 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Iremonger, Bernard @ 2015-12-04 15:25 UTC (permalink / raw)
To: Yuanhan Liu, Stephen Hemminger; +Cc: dev
Hi Stephen, Yuanhan,
> -----Original Message-----
> From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
> Sent: Friday, December 4, 2015 3:30 AM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Xie, Huawei <huawei.xie@intel.com>; Iremonger, Bernard
> <bernard.iremonger@intel.com>; dev@dpdk.org
> Subject: Re: [PATCH] virtio: fix link state regression
>
> On Thu, Dec 03, 2015 at 06:08:24PM -0800, Stephen Hemminger wrote:
> > Support for link state interrupt was broken on virtio by
> >
> > commit bda66c418c85 ("ethdev: add device fields from PCI layer")
> >
> > This is caused because the actual value of drv_flags is not set until
> > after the resource_init has figured out whether it is using UIO or
> > direct I/O instructions.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > ---
> > There maybe other drivers with the same problem. It would have been
> > better to move the structure elements (and break ABI) rather than
> > assume it safe to copy them. Better to fail compiling.
>
> I see no patch content.
>
> --yliu
I have submitted a patch for this issue.
http://dpdk.org/dev/patchwork/patch/9345/
I have checked the other drivers, I found an issue with the bonding PMD.
I have submitted a patch for this.
http://dpdk.org/dev/patchwork/patch/9342/
The remaining drivers look fine to me.
Regards,
Bernard.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] virtio: fix link state regression
2015-12-04 2:08 3% [dpdk-dev] [PATCH] virtio: fix link state regression Stephen Hemminger
@ 2015-12-04 3:29 0% ` Yuanhan Liu
2015-12-04 15:25 0% ` Iremonger, Bernard
0 siblings, 1 reply; 200+ results
From: Yuanhan Liu @ 2015-12-04 3:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Thu, Dec 03, 2015 at 06:08:24PM -0800, Stephen Hemminger wrote:
> Support for link state interrupt was broken on virtio by
>
> commit bda66c418c85 ("ethdev: add device fields from PCI layer")
>
> This is caused because the actual value of drv_flags is not set
> until after the resource_init has figured out whether it is using
> UIO or direct I/O instructions.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> There maybe other drivers with the same problem. It would have
> been better to move the structure elements (and break ABI) rather
> than assume it safe to copy them. Better to fail compiling.
I see no patch content.
--yliu
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] virtio: fix link state regression
@ 2015-12-04 2:08 3% Stephen Hemminger
2015-12-04 3:29 0% ` Yuanhan Liu
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2015-12-04 2:08 UTC (permalink / raw)
To: huawei.xie, yuanhan.liu, bernard.iremonger; +Cc: dev
Support for link state interrupt was broken on virtio by
commit bda66c418c85 ("ethdev: add device fields from PCI layer")
This is caused because the actual value of drv_flags is not set
until after the resource_init has figured out whether it is using
UIO or direct I/O instructions.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
There maybe other drivers with the same problem. It would have
been better to move the structure elements (and break ABI) rather
than assume it safe to copy them. Better to fail compiling.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 0/3 v2] Minor abi-validator improvements
@ 2015-12-03 19:38 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-03 19:38 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
2015-09-24 06:23, Neil Horman:
> On Thu, Sep 24, 2015 at 10:50:56AM +0300, Panu Matilainen wrote:
> > For giggles, tried running abi-validator between 2.0 and 2.1 on
> > my Fedora 22 laptop, didn't work due to various build failures.
> > With this patch series the following now succeeds:
> >
> > EXTRA_CFLAGS="-Wno-error" scripts/validate-abi.sh v2.0.0 v2.1.0 x86_64-native-linuxapp-gcc
> >
> > Panu Matilainen (3):
> > scripts: permit passing extra compiler & linker flags to ABI validator
> > scripts: move two identical config fixups into a function
> > scripts: teach ABI validator about CONFIG_RTE_KNI_KMOD
> >
> > scripts/validate-abi.sh | 28 ++++++++++++++--------------
> > 1 file changed, 14 insertions(+), 14 deletions(-)
> >
>
> series
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size
@ 2015-12-03 16:32 4% ` Mcnamara, John
0 siblings, 0 replies; 200+ results
From: Mcnamara, John @ 2015-12-03 16:32 UTC (permalink / raw)
To: Olivier MATZ, Nelio Laranjeiro, dev
> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Friday, November 20, 2015 4:29 PM
> To: Mcnamara, John; Nelio Laranjeiro; dev@dpdk.org
> Cc: thomas.monjalon@6wind.com; Lu, Wenzhuo
> Subject: Re: [PATCH 1/2] doc: announce ABI change for cmdline buffer size
>
> Hi Nélio,
>
> On 11/10/2015 06:29 PM, Mcnamara, John wrote:
> >
> >
> >> -----Original Message-----
> >> From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> >> Sent: Monday, November 9, 2015 4:48 PM
> >> To: dev@dpdk.org
> >> Cc: olivier.matz@6wind.com; thomas.monjalon@6wind.com; Mcnamara,
> >> John; Lu, Wenzhuo
> >> Subject: [PATCH 1/2] doc: announce ABI change for cmdline buffer size
> >>
> >> 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>
> >
>
> While I'm not fundamentally opposed to change the buffer size, I'm
> wondering if the impacted commands shouldn't be reworked to have smaller
> lines. 256 is already a quite big value for a line:
>
> 01234567890123456789012345678901234567890123456789012345678901234567890123
> 45678901234567890123456789012345678901234567890123456789012345678901234567
> 89012345678901234567890123456789012345678901234567890123456789012345678901
> 2345678901234567890123456789012345
>
> For instance, we could change some commands to use contexts.
> Dummy example with reta config:
>
> testpmd> port config 0 rss reta
> testpmd-reta-config-0> add hash1 queue1
> testpmd-reta-config-0> add hash2 queue2
> testpmd-reta-config-0> del hash1 queue1
> testpmd-reta-config-0> show
> testpmd-reta-config-0> commit
> testpmd>
>
> What do you think?
Hi,
I think it is a good idea but my concern is that it won't get done unless someone commits to doing it.
And if they do it will be a non-trivial change since the commandline/runtime parsing in testpmd is a little crufty and it isn't set up to do this kind of sub-command parsing.
Also, we will still have to maintain backward compatibility (for users and testers) with the existing single line versions of the commands.
So, I'd like to make sure that this change isn't blocked on the assumption that it will be fixed with a more elegant solution if that solution is unlikely to happen.
However, I do think that we should avoid bolting on every increasing options to existing testpmd commands and should instead create new commands where it makes sense.
John.
--
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-03 13:44 4% ` Panu Matilainen
2015-12-03 13:49 4% ` Richardson, Bruce
@ 2015-12-03 15:46 4% ` Mcnamara, John
1 sibling, 0 replies; 200+ results
From: Mcnamara, John @ 2015-12-03 15:46 UTC (permalink / raw)
To: Panu Matilainen, Thomas Monjalon; +Cc: dev
> -----Original Message-----
> From: Panu Matilainen [mailto:pmatilai@redhat.com]
> Sent: Thursday, December 3, 2015 1:44 PM
> To: Thomas Monjalon; Mcnamara, John
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions
> as abi validation range
>
> On 12/03/2015 03:28 PM, Thomas Monjalon wrote:
> > 2015-12-03 12:14, Mcnamara, John:
> >> Also, if someone has some bandwidth it would be good to add an option
> >> to pass -j with an optional number to "make" in the script.
> >
> > We can use -j without any number:
> > "make will not limit the number of jobs that can run simultaneously".
> > It is a not so bad default.
> >
>
> Hmm, my memory associates an unlimited -j to make with sudden death by
> fork-bomb. But that was a long time ago and on a different codebase (the
> kernel maybe), with DPDK on current hardware it doesn't seem that bad at
> all.
>
> OTOH we can also simply ask the system for a reasonable value, eg $
> /usr/bin/getconf _NPROCESSORS_ONLN
Hi,
To be clear, it would be nice to be able to pass "-j" or "-j n" like you can do to directly to 'make'.
For a compile heavy codebase (no DPDK) "-j" can, as you say, choke your system but that would be up to the user to specify, or not.
John.
--
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
2015-12-03 1:31 0% ` Ferruh Yigit
2015-12-03 8:11 3% ` Christian Ehrhardt
@ 2015-12-03 14:59 0% ` Neil Horman
1 sibling, 0 replies; 200+ results
From: Neil Horman @ 2015-12-03 14:59 UTC (permalink / raw)
To: Robie Basak, dev
On Thu, Dec 03, 2015 at 01:31:33AM +0000, Ferruh Yigit wrote:
> On Wed, Dec 02, 2015 at 06:44:19AM -0500, Neil Horman wrote:
> > On Tue, Dec 01, 2015 at 12:37:37PM +0000, Robie Basak wrote:
> > > Re-sending this unsigned since the ML rejected my signed email.
> > >
> > > -1 from Ubuntu without further discussion since it will break us. Please
> > > don't commit this patch yet.
> > >
> > > I don't understand why we must have the complexity of so many shared
> > > libraries. From a distribution packaging perspective, all I see is that
> > > this multiplies potential work by twenty times and makes it awkward to
> > > work with without special tooling (which then needs maintaining).
> > >
> > 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.
> >
> > > understand why DPDK must be different to every other userspace library
> > > out there. If DPDK has a good need to be different then that's fair
> > > enough. But I feel that if DPDK is deviating from the norm then we need
> > > to frame the discussion from the perspective of "why DPDK must be
> > > different", rather than having me trying to explain why the norm is the
> > > right way to do it.
> > >
> > > On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
> > > > That's how Fedora and RHEL are shipping it already and nobody has so much
> > > > as noticed anything strange, much less complained about it. 20 libraries
> > > > is but a drop in the ocean on a average distro.
> > >
> > > No, it is 20 times the work from the perspective of DPDK package
> > > maintenance. Let me explain why.
> > >
> > > 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. 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.
> >
> >
> > > This works because of conventions around sonames, which DPDK breaks
> > > unless we treat it as twenty different libraries which changes our work
> > > from easy to painful.
> > >
> > > Usually a library transition is managed by hand by the package
> > > maintainer. It's not taxing because it's straightforward and well
> > > understood. Update and upload the new ABI source package, then find all
> > > reverse dependencies and sort them out, recursively. But if the
> > > maintainer must do it twenty times, then it becomes taxing and prone to
> > > error. And if the reverse dependency tree differs depending on the split
> > > library used by library consumers, then it gets far more complex to
> > > follow.
> > >
> > > Admittedly we could tool around this to make it easier, but that's extra
> > > work (both initially and in maintenance) and prone to error (because
> > > we'd only be doing it for DPDK).
> > >
> > 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)
> >
> > > 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.
> >
> >
> > > 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.
> >
> > > 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.
> >
> > Neil
> >
> I just sent a patch that fixes versioning in combined library, can you please check it: http://dpdk.org/dev/patchwork/patch/9259/
>
> Thanks,
> ferruh
>
>
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.
Regards
Neil
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2] scripts: support any legal git revisions as abi validation range
2015-12-02 16:50 36% [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range Panu Matilainen
2015-12-02 18:23 4% ` Neil Horman
2015-12-03 12:14 29% ` Mcnamara, John
@ 2015-12-03 14:05 36% ` Panu Matilainen
2015-12-07 14:09 7% ` Panu Matilainen
2015-12-07 22:38 4% ` Thomas Monjalon
2 siblings, 2 replies; 200+ results
From: Panu Matilainen @ 2015-12-03 14:05 UTC (permalink / raw)
To: dev
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)
doc/guides/contributing/versioning.rst | 20 ++++++++++++-------
scripts/validate-abi.sh | 36 ++++++++++++++++++++--------------
2 files changed, 34 insertions(+), 22 deletions(-)
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 653c7d0..015ebb7 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -468,16 +468,22 @@ utilities which can be installed via a package manager. For example::
The syntax of the ``validate-abi.sh`` utility is::
- ./scripts/validate-abi.sh <TAG1> <TAG2> <TARGET>
+ ./scripts/validate-abi.sh <REV1> <REV2> <TARGET>
-Where ``TAG1`` and ``TAG2`` are valid git tags on the local repo and target is
-the usual DPDK compilation target.
+Where ``REV1`` and ``REV2`` are valid gitrevisions(7)
+https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
+on the local repo and target is the usual DPDK compilation target.
-For example to test the current committed HEAD against a previous release tag
-we could add a temporary tag and run the utility as follows::
+For example:
- git tag MY_TEMP_TAG
- ./scripts/validate-abi.sh v2.0.0 MY_TEMP_TAG x86_64-native-linuxapp-gcc
+ # Check between the previous and latest commit:
+ ./scripts/validate-abi.sh HEAD~1 HEAD x86_64-native-linuxapp-gcc
+
+ # Check between two tags:
+ ./scripts/validate-abi.sh v2.0.0 v2.1.0 x86_64-native-linuxapp-gcc
+
+ # Check between git master and local topic-branch "vhost-hacking":
+ ./scripts/validate-abi.sh master vhost-hacking x86_64-native-linuxapp-gcc
After the validation script completes (it can take a while since it need to
compile both tags) it will create compatibility reports in the
diff --git a/scripts/validate-abi.sh b/scripts/validate-abi.sh
index 4476433..e49c425 100755
--- a/scripts/validate-abi.sh
+++ b/scripts/validate-abi.sh
@@ -33,7 +33,7 @@ TARGET=$3
ABI_DIR=`mktemp -d -p /tmp ABI.XXXXXX`
usage() {
- echo "$0 <TAG1> <TAG2> <TARGET>"
+ echo "$0 <REV1> <REV2> <TARGET>"
}
log() {
@@ -43,16 +43,15 @@ log() {
}
validate_tags() {
- git tag -l | grep -q "$TAG1"
- if [ $? -ne 0 ]
+
+ if [ -z "$HASH1" ]
then
- echo "$TAG1 is invalid"
+ echo "invalid revision: $TAG1"
return
fi
- git tag -l | grep -q "$TAG2"
- if [ $? -ne 0 ]
+ if [ -z "$HASH2" ]
then
- echo "$TAG2 is invalid"
+ echo "invalid revision: $TAG2"
return
fi
}
@@ -60,12 +59,12 @@ validate_tags() {
validate_args() {
if [ -z "$TAG1" ]
then
- echo "Must Specify TAG1"
+ echo "Must Specify REV1"
return
fi
if [ -z "$TAG2" ]
then
- echo "Must Specify TAG2"
+ echo "Must Specify REV2"
return
fi
if [ -z "$TARGET" ]
@@ -112,6 +111,9 @@ 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)
+
# Make sure our tags exist
res=$(validate_tags)
if [ -n "$res" ]
@@ -120,6 +122,10 @@ then
cleanup_and_exit 1
fi
+# Make hashes available in output for non-local reference
+TAG1="$TAG1 ($HASH1)"
+TAG2="$TAG2 ($HASH2)"
+
ABICHECK=`which abi-compliance-checker 2>/dev/null`
if [ $? -ne 0 ]
then
@@ -135,8 +141,8 @@ then
fi
log "INFO" "We're going to check and make sure that applications built"
-log "INFO" "against DPDK DSOs from tag $TAG1 will still run when executed"
-log "INFO" "against DPDK DSOs built from tag $TAG2."
+log "INFO" "against DPDK DSOs from version $TAG1 will still run when executed"
+log "INFO" "against DPDK DSOs built from version $TAG2."
log "INFO" ""
# Check to make sure we have a clean tree
@@ -152,7 +158,7 @@ cd $(dirname $0)/..
log "INFO" "Checking out version $TAG1 of the dpdk"
# Move to the old version of the tree
-git checkout $TAG1
+git checkout $HASH1
# Make sure we configure SHARED libraries
# Also turn off IGB and KNI as those require kernel headers to build
@@ -185,7 +191,7 @@ cd $TARGET/lib
log "INFO" "COLLECTING ABI INFORMATION FOR $TAG1"
for i in `ls *.so`
do
- $ABIDUMP $i -o $ABI_DIR/$i-ABI-0.dump -lver $TAG1
+ $ABIDUMP $i -o $ABI_DIR/$i-ABI-0.dump -lver $HASH1
done
cd ../..
@@ -194,7 +200,7 @@ git clean -f -d
git reset --hard
# Move to the new version of the tree
log "INFO" "Checking out version $TAG2 of the dpdk"
-git checkout $TAG2
+git checkout $HASH2
# Make sure we configure SHARED libraries
# Also turn off IGB and KNI as those require kernel headers to build
@@ -220,7 +226,7 @@ cd $TARGET/lib
log "INFO" "COLLECTING ABI INFORMATION FOR $TAG2"
for i in `ls *.so`
do
- $ABIDUMP $i -o $ABI_DIR/$i-ABI-1.dump -lver $TAG2
+ $ABIDUMP $i -o $ABI_DIR/$i-ABI-1.dump -lver $HASH2
done
cd ../..
--
2.5.0
^ permalink raw reply [relevance 36%]
* Re: [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 11:18 4% ` Ferruh Yigit
@ 2015-12-03 14:01 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2015-12-03 14:01 UTC (permalink / raw)
To: Christian Ehrhardt, dev
On Thu, Dec 03, 2015 at 11:18:27AM +0000, Ferruh Yigit wrote:
> On Thu, Dec 03, 2015 at 09:18:49AM +0100, Christian Ehrhardt wrote:
> > Hi Ferruh,
> > some minor bash improvements that could be made in the next revision:
> >
> > On Thu, Dec 3, 2015 at 2:22 AM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> > > diff --git a/scripts/merge_maps.sh b/scripts/merge_maps.sh
> > > new file mode 100755
> > > index 0000000..bc40dc8
> > > --- /dev/null
> > > +++ b/scripts/merge_maps.sh
> > > @@ -0,0 +1,29 @@
> > > +#!/bin/sh
> > > +
> > > +FILES=$(find $RTE_SDK -name "*.map" | grep -v build)
> > > +SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
> >
> > Guarding $RTE_SDK and $FILES with "" will help avoid some potential
> > issues due to words splitting.
I quoted them (not $FILES which grep requires multiple params), but that will not actually help with folder names contains spaces, for that case script is broken.
I fixed script using IFS and a few tricks but made script unnecessarly complex, so I revert back and leaving as it is unless required explicitly.
And I suspect if folder name has spaces this script won't be only thing broken.
Thanks,
ferruh
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v4] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 12:49 7% ` Panu Matilainen
@ 2015-12-03 13:51 4% ` Ferruh Yigit
2015-12-06 14:37 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-12-03 13:51 UTC (permalink / raw)
To: dev
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>
---
mk/rte.sharelib.mk | 6 +++++-
scripts/merge_maps.sh | 29 +++++++++++++++++++++++++++++
2 files changed, 34 insertions(+), 1 deletion(-)
create mode 100755 scripts/merge_maps.sh
diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
index 7bb7219..6029b71 100644
--- a/mk/rte.sharelib.mk
+++ b/mk/rte.sharelib.mk
@@ -40,6 +40,8 @@ LIB_ONE := lib$(RTE_LIBNAME).so
else
LIB_ONE := lib$(RTE_LIBNAME).a
endif
+COMBINED_MAP=$(BUILDDIR)/lib/libdpdk.map
+COMBINED_LDFLAGS += --version-script=$(COMBINED_MAP)
endif
.PHONY:sharelib
@@ -51,9 +53,10 @@ ifeq ($(LINK_USING_CC),1)
# Override the definition of LD here, since we're linking with CC
LD := $(CC) $(CPU_CFLAGS)
O_TO_S = $(LD) $(call linkerprefix,$(CPU_LDFLAGS)) \
+ $(call linkerprefix,$(COMBINED_LDFLAGS)) \
-shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
else
-O_TO_S = $(LD) $(CPU_LDFLAGS) \
+O_TO_S = $(LD) $(CPU_LDFLAGS) $(COMBINED_LDFLAGS) \
-shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
endif
@@ -79,6 +82,7 @@ ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
$(LIB_ONE): FORCE
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
+ @$(SRCDIR)/scripts/merge_maps.sh > $(COMBINED_MAP)
$(O_TO_S_DO)
else
$(LIB_ONE): FORCE
diff --git a/scripts/merge_maps.sh b/scripts/merge_maps.sh
new file mode 100755
index 0000000..edc88de
--- /dev/null
+++ b/scripts/merge_maps.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+FILES=$(find "$RTE_SDK"/lib "$RTE_SDK"/drivers -name "*_version.map")
+SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
+
+first=0
+prev_sym="none"
+
+for s in $SYMBOLS; do
+ echo "$s {"
+ echo " global:"
+ echo ""
+ for f in $FILES; do
+ sed -n "/$s {/,/}/p" "$f" | sed '/^$/d' | grep -v global | grep -v local | sed -e '1d' -e '$d'
+ done | sort -u
+ echo ""
+ if [ $first -eq 0 ]; then
+ first=1;
+ echo " local: *;";
+ fi
+ if [ "$prev_sym" = "none" ]; then
+ echo "};";
+ prev_sym=$s;
+ else
+ echo "} $prev_sym;";
+ prev_sym=$s;
+ fi
+ echo ""
+done
--
2.5.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-03 13:44 4% ` Panu Matilainen
@ 2015-12-03 13:49 4% ` Richardson, Bruce
2015-12-03 15:46 4% ` Mcnamara, John
1 sibling, 0 replies; 200+ results
From: Richardson, Bruce @ 2015-12-03 13:49 UTC (permalink / raw)
To: Panu Matilainen, Thomas Monjalon, Mcnamara, John; +Cc: dev
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
> Sent: Thursday, December 3, 2015 1:44 PM
> To: Thomas Monjalon <thomas.monjalon@6wind.com>; Mcnamara, John
> <john.mcnamara@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions
> as abi validation range
>
> On 12/03/2015 03:28 PM, Thomas Monjalon wrote:
> > 2015-12-03 12:14, Mcnamara, John:
> >> Also, if someone has some bandwidth it would be good to add an option
> >> to pass -j with an optional number to "make" in the script.
> >
> > We can use -j without any number:
> > "make will not limit the number of jobs that can run simultaneously".
> > It is a not so bad default.
> >
>
> Hmm, my memory associates an unlimited -j to make with sudden death by
> fork-bomb. But that was a long time ago and on a different codebase (the
> kernel maybe), with DPDK on current hardware it doesn't seem that bad at
> all.
>
> OTOH we can also simply ask the system for a reasonable value, eg $
> /usr/bin/getconf _NPROCESSORS_ONLN
>
> - Panu -
+1 to this.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-03 13:28 4% ` Thomas Monjalon
@ 2015-12-03 13:44 4% ` Panu Matilainen
2015-12-03 13:49 4% ` Richardson, Bruce
2015-12-03 15:46 4% ` Mcnamara, John
0 siblings, 2 replies; 200+ results
From: Panu Matilainen @ 2015-12-03 13:44 UTC (permalink / raw)
To: Thomas Monjalon, Mcnamara, John; +Cc: dev
On 12/03/2015 03:28 PM, Thomas Monjalon wrote:
> 2015-12-03 12:14, Mcnamara, John:
>> Also, if someone has some bandwidth it would be good to add an option
>> to pass -j with an optional number to "make" in the script.
>
> We can use -j without any number:
> "make will not limit the number of jobs that can run simultaneously".
> It is a not so bad default.
>
Hmm, my memory associates an unlimited -j to make with sudden death by
fork-bomb. But that was a long time ago and on a different codebase (the
kernel maybe), with DPDK on current hardware it doesn't seem that bad at
all.
OTOH we can also simply ask the system for a reasonable value, eg
$ /usr/bin/getconf _NPROCESSORS_ONLN
- Panu -
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-03 13:39 7% ` Panu Matilainen
@ 2015-12-03 13:41 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-03 13:41 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
2015-12-03 15:39, Panu Matilainen:
> > Also, if someone has some bandwidth it would be good to add an option
> > to pass -j with an optional number to "make" in the script.
>
> Can do, although I'm still waiting fo my previous, semi-related
> validate-abi patches from September to be applied...
Oh yes, sorry. I will apply it shortly.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-03 12:14 29% ` Mcnamara, John
2015-12-03 13:28 4% ` Thomas Monjalon
@ 2015-12-03 13:39 7% ` Panu Matilainen
2015-12-03 13:41 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-03 13:39 UTC (permalink / raw)
To: Mcnamara, John, dev
On 12/03/2015 02:14 PM, Mcnamara, John wrote:
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
>> Sent: Wednesday, December 2, 2015 4:51 PM
>> To: dev@dpdk.org
>> Subject: [dpdk-dev] [PATCH] scripts: support any legal git revisions as
>> abi validation range
>>
>> 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 mybrach <target>" etc in addition to validating
>> between tags. Makes it easier to run the validator for in-development
>> work.
>
> Hi Panu,
>
> +1 for this.
>
> You might also change the ABI validation section of the docs to go along
> with this. Something like the patch below. If not I'll submit it
> afterwards.
Good points, including changing the usage message to REV instead of TAG.
I'll send an improved version based on this, thanks.
>
> Also, if someone has some bandwidth it would be good to add an option
> to pass -j with an optional number to "make" in the script.
Can do, although I'm still waiting fo my previous, semi-related
validate-abi patches from September to be applied...
- Panu -
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-03 12:14 29% ` Mcnamara, John
@ 2015-12-03 13:28 4% ` Thomas Monjalon
2015-12-03 13:44 4% ` Panu Matilainen
2015-12-03 13:39 7% ` Panu Matilainen
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-03 13:28 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev
2015-12-03 12:14, Mcnamara, John:
> Also, if someone has some bandwidth it would be good to add an option
> to pass -j with an optional number to "make" in the script.
We can use -j without any number:
"make will not limit the number of jobs that can run simultaneously".
It is a not so bad default.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-03 12:42 0% ` Ananyev, Konstantin
@ 2015-12-03 13:20 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2015-12-03 13:20 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev
On Thu, Dec 03, 2015 at 12:42:13PM +0000, Ananyev, Konstantin wrote:
>
>
> > -----Original Message-----
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > Sent: Thursday, December 03, 2015 12:17 PM
> > To: Ananyev, Konstantin
> > Cc: Thomas Monjalon; dev@dpdk.org; viktorin@rehivetech.com
> > Subject: Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
> >
> > On Thu, Dec 03, 2015 at 11:02:07AM +0000, Ananyev, Konstantin wrote:
> >
> > Hi Konstantin,
> >
> > > Hi Jerin,
> > >
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > > Sent: Thursday, December 03, 2015 9:34 AM
> > > > To: Thomas Monjalon
> > > > Cc: dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
> > > >
> > > > On Wed, Dec 02, 2015 at 05:57:10PM +0100, Thomas Monjalon wrote:
> > > > > 2015-12-02 22:23, Jerin Jacob:
> > > > > > On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> > > > > > > 2015-12-02 20:04, Jerin Jacob:
> > > > > > > > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > > > > > > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > > > > > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > > > > > > > that lead to multiple definition and its not good.
> > > > > > > > > >
> > > > > > > > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > > > > > > > appears in both your patch and this header file.
> > > > > > > >
> > > > > > > > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > > > > > > > is fine(unlike inline function).
> > > > > > > >
> > > > > > > > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > > > > > > > something would break the ABI.
> > > > > > >
> > > > > > > Isn't it already broken in 2.2?
> > > > > >
> > > > > > Does it mean, You would like to have rte_128i(or similar) kind of
> > > > > > abstraction to represent 128bit SIMD variable in DPDK?
> > > > >
> > > > > If you are convinced that it is the best way to write a generic code, yes.
> > > >
> > > > I grep-ed through DPDK API list to see the dependency with SIMD in API
> > > > definition.I see only rte_lpm_lookupx4 API has SIMD dependency in API
> > > > definition.
> > > >
> > > > I believe that's the root cause of the problem. IMO, The
> > > > better way to fix this would be to remove __m128i from API and have more
> > > > general representation to remove the architecture dependency from API
> > > >
> > > > something like this,
> > > >
> > > > rte_lpm_lookupx4(const struct rte_lpm *lpm, uint32_t *ip, uint16_t
> > > > hop[4], uint16_t defv)
> > > >
> > > > instead of
> > > >
> > > > rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t
> > > > hop[4], uint16_t defv)
> > >
> > > The idea for that function was that rte_lpm_lookupx4() accepts 4 IPv4 addresses that are:
> > > 1. already in 128bit register
> > > 2. 'prepared' - byte swap is already done for them if needed.
> > >
> > > About ways to fix __m128i dependency: as I can see x86 and arm DPDK code
> > > already has xmm_t typedef:
> > >
> > > $ find lib -type f | xargs grep xmm_t | grep typedef
> > > lib/librte_eal/common/include/arch/x86/rte_vect.h:typedef __m128i xmm_t;
> > > lib/librte_eal/common/include/arch/arm/rte_vect.h:typedef int32x4_t xmm_t;
> > >
> > > Why not to change rte_lpm_lookupx4() to accept xmm_t as input parameter.
> > > As I understand it would solve the problem, and wouldn't introduce any API/ABI breakage, right?
> >
> > Yes, If we have API/ABI breakage concerns.
> >
> > IMO, Now this would call for some kind of rte_vect_* abstraction load,
> > store, set kind of SIMD operation on xmm_t in common test code to
> > aviod #ifdef's in app/test/test_lpm.c
>
> Yes, seems so.
>
> >
> > I guess we may not need those abstractions in
> > lib/librte_eal/common/include/arch/ directory.
> > keeping in app/test/xmmt_ops.h should be enough, right?
>
> That sounds ok to me.
> At least for now.
> For future the more generic question - do we like to have some
> generic layer abstraction for similar vector instrincts across different archs?
> From one side it might help people writing/using vector implementation of some stuff,
> from other side - there would be extra hassle creating/supporting it.
There are few such libaries avilable on web. example:
NEON -> SSE
https://software.intel.com/sites/default/files/managed/cf/f6/NEONvsSSE.h
SSE -> NEON
https://github.com/jratcliff63367/sse2neon/blob/master/SSE2NEON.h
but coming up with common abstraction will be difficult as it's not
one to one mapped all the time and performance criteria to choose
the instruction on given architecture to realize a certain logic etc
Jerin
>
> Konstantin
>
> >
> >
> > >
> > > Konstantin
> > >
> > > >
> > > > Now I am not sure why this API was created like this, from l3fwd.c
> > > > example, it looks to accommodate the IPV4 byte swap[1]. If it's true,
> > > > maybe we can have eal byte swap abstraction for optimized byte swap on
> > > > memory for 4 IP address in one shot
> > > >
> > > > or
> > > >
> > > > Have rte_lpm_lookupx4 take an argument for byte swap or not ?
> > > >
> > > > or
> > > >
> > > > something similar?
> > > >
> > > > Thoughts ?
> > > >
> > > > [1]
> > > > const __m128i bswap_mask = _mm_set_epi8(12, 13, 14, 15, 8, 9, 10, 11,
> > > > 4, 5, 6, 7, 0, 1, 2, 3);
> > > > /* Byte swap 4 IPV4 addresses. */
> > > > dip = _mm_shuffle_epi8(dip, bswap_mask);
> > > >
> > > > Jerin
> > > >
> > > > > I think the most important question is to know what is the best solution
> > > > > for performance and maintainability. The API/ABI questions will be considered
> > > > > after.
> > > > >
> > > > > Thanks for your involvement guys.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 1:22 4% [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library Ferruh Yigit
2015-12-03 1:36 4% ` Thomas Monjalon
2015-12-03 8:18 4% ` [dpdk-dev] [PATCH v2] " Christian Ehrhardt
@ 2015-12-03 12:49 7% ` Panu Matilainen
2015-12-03 13:51 4% ` [dpdk-dev] [PATCH v4] " Ferruh Yigit
2 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-03 12:49 UTC (permalink / raw)
To: Ferruh Yigit, dev
On 12/03/2015 03:22 AM, Ferruh Yigit wrote:
> 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>
> ---
> drivers/net/Makefile | 3 +++
> lib/Makefile | 3 +++
> mk/rte.sdkbuild.mk | 2 +-
> mk/rte.sharelib.mk | 3 +++
> scripts/merge_maps.sh | 29 +++++++++++++++++++++++++++++
> 5 files changed, 39 insertions(+), 1 deletion(-)
> create mode 100755 scripts/merge_maps.sh
>
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index cddcd57..d3c865b 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -51,5 +51,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
> DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
> DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
>
> +ifeq ($(COMBINED_BUILD),1)
> include $(RTE_SDK)/mk/rte.sharelib.mk
> +endif
> +
> include $(RTE_SDK)/mk/rte.subdir.mk
> diff --git a/lib/Makefile b/lib/Makefile
> index ef172ea..d0f7fb8 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -64,5 +64,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
> DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
> endif
>
> +ifeq ($(COMBINED_BUILD),1)
> include $(RTE_SDK)/mk/rte.sharelib.mk
> +endif
> +
> include $(RTE_SDK)/mk/rte.subdir.mk
> diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
> index 38ec7bd..d4e3abf 100644
> --- a/mk/rte.sdkbuild.mk
> +++ b/mk/rte.sdkbuild.mk
> @@ -94,7 +94,7 @@ $(ROOTDIRS-y):
> @echo "== Build $@"
> $(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
> @if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
> - $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
> + COMBINED_BUILD=1 $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
> fi
>
> %_clean:
> diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
> index 7bb7219..76ead09 100644
> --- a/mk/rte.sharelib.mk
> +++ b/mk/rte.sharelib.mk
> @@ -40,6 +40,8 @@ LIB_ONE := lib$(RTE_LIBNAME).so
> else
> LIB_ONE := lib$(RTE_LIBNAME).a
> endif
> +COMBINED_MAP=$(BUILDDIR)/lib/libdpdk.map
> +CPU_LDFLAGS += --version-script=$(COMBINED_MAP)
> endif
>
> .PHONY:sharelib
> @@ -79,6 +81,7 @@ ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
> ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> $(LIB_ONE): FORCE
> @[ -d $(dir $@) ] || mkdir -p $(dir $@)
> + @$(SRCDIR)/scripts/merge_maps.sh > $(COMBINED_MAP)
> $(O_TO_S_DO)
> else
> $(LIB_ONE): FORCE
> diff --git a/scripts/merge_maps.sh b/scripts/merge_maps.sh
> new file mode 100755
> index 0000000..bc40dc8
> --- /dev/null
> +++ b/scripts/merge_maps.sh
> @@ -0,0 +1,29 @@
> +#!/bin/sh
> +
> +FILES=$(find $RTE_SDK -name "*.map" | grep -v build)
> +SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
> +
> +first=0
> +prev_sym="none"
> +
> +for s in $SYMBOLS; do
> + echo "$s {"
> + echo " global:"
> + echo ""
> + for f in $FILES; do
> + sed -n "/$s {/,/}/p" $f | sed '/^$/d' | grep -v global | grep -v local | sed '1d' | sed '$d'
> + done | sort -u
> + echo ""
> + if [ $first -eq 0 ]; then
> + first=1;
> + echo " local: *;";
> + fi
> + if [ "$prev_sym" == "none" ]; then
> + echo "};";
> + prev_sym=$s;
> + else
> + echo "} $prev_sym;";
> + prev_sym=$s;
> + fi
> + echo ""
> +done
>
I'd still rather see the combined library replaced with a linker script,
but as long as it is there then +1 for this: with symbol versioning in
place, applications linked to it more likely refuse to start than
randomly crash when ABI changes, internal symbols are hidden etc. And
doesn't require manual updating of two maps since its all scripted.
- Panu -
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-03 12:17 3% ` Jerin Jacob
@ 2015-12-03 12:42 0% ` Ananyev, Konstantin
2015-12-03 13:20 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2015-12-03 12:42 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev
> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Thursday, December 03, 2015 12:17 PM
> To: Ananyev, Konstantin
> Cc: Thomas Monjalon; dev@dpdk.org; viktorin@rehivetech.com
> Subject: Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
>
> On Thu, Dec 03, 2015 at 11:02:07AM +0000, Ananyev, Konstantin wrote:
>
> Hi Konstantin,
>
> > Hi Jerin,
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > Sent: Thursday, December 03, 2015 9:34 AM
> > > To: Thomas Monjalon
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
> > >
> > > On Wed, Dec 02, 2015 at 05:57:10PM +0100, Thomas Monjalon wrote:
> > > > 2015-12-02 22:23, Jerin Jacob:
> > > > > On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> > > > > > 2015-12-02 20:04, Jerin Jacob:
> > > > > > > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > > > > > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > > > > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > > > > > > that lead to multiple definition and its not good.
> > > > > > > > >
> > > > > > > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > > > > > > appears in both your patch and this header file.
> > > > > > >
> > > > > > > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > > > > > > is fine(unlike inline function).
> > > > > > >
> > > > > > > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > > > > > > something would break the ABI.
> > > > > >
> > > > > > Isn't it already broken in 2.2?
> > > > >
> > > > > Does it mean, You would like to have rte_128i(or similar) kind of
> > > > > abstraction to represent 128bit SIMD variable in DPDK?
> > > >
> > > > If you are convinced that it is the best way to write a generic code, yes.
> > >
> > > I grep-ed through DPDK API list to see the dependency with SIMD in API
> > > definition.I see only rte_lpm_lookupx4 API has SIMD dependency in API
> > > definition.
> > >
> > > I believe that's the root cause of the problem. IMO, The
> > > better way to fix this would be to remove __m128i from API and have more
> > > general representation to remove the architecture dependency from API
> > >
> > > something like this,
> > >
> > > rte_lpm_lookupx4(const struct rte_lpm *lpm, uint32_t *ip, uint16_t
> > > hop[4], uint16_t defv)
> > >
> > > instead of
> > >
> > > rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t
> > > hop[4], uint16_t defv)
> >
> > The idea for that function was that rte_lpm_lookupx4() accepts 4 IPv4 addresses that are:
> > 1. already in 128bit register
> > 2. 'prepared' - byte swap is already done for them if needed.
> >
> > About ways to fix __m128i dependency: as I can see x86 and arm DPDK code
> > already has xmm_t typedef:
> >
> > $ find lib -type f | xargs grep xmm_t | grep typedef
> > lib/librte_eal/common/include/arch/x86/rte_vect.h:typedef __m128i xmm_t;
> > lib/librte_eal/common/include/arch/arm/rte_vect.h:typedef int32x4_t xmm_t;
> >
> > Why not to change rte_lpm_lookupx4() to accept xmm_t as input parameter.
> > As I understand it would solve the problem, and wouldn't introduce any API/ABI breakage, right?
>
> Yes, If we have API/ABI breakage concerns.
>
> IMO, Now this would call for some kind of rte_vect_* abstraction load,
> store, set kind of SIMD operation on xmm_t in common test code to
> aviod #ifdef's in app/test/test_lpm.c
Yes, seems so.
>
> I guess we may not need those abstractions in
> lib/librte_eal/common/include/arch/ directory.
> keeping in app/test/xmmt_ops.h should be enough, right?
That sounds ok to me.
At least for now.
For future the more generic question - do we like to have some
generic layer abstraction for similar vector instrincts across different archs?
>From one side it might help people writing/using vector implementation of some stuff,
from other side - there would be extra hassle creating/supporting it.
Konstantin
>
>
> >
> > Konstantin
> >
> > >
> > > Now I am not sure why this API was created like this, from l3fwd.c
> > > example, it looks to accommodate the IPV4 byte swap[1]. If it's true,
> > > maybe we can have eal byte swap abstraction for optimized byte swap on
> > > memory for 4 IP address in one shot
> > >
> > > or
> > >
> > > Have rte_lpm_lookupx4 take an argument for byte swap or not ?
> > >
> > > or
> > >
> > > something similar?
> > >
> > > Thoughts ?
> > >
> > > [1]
> > > const __m128i bswap_mask = _mm_set_epi8(12, 13, 14, 15, 8, 9, 10, 11,
> > > 4, 5, 6, 7, 0, 1, 2, 3);
> > > /* Byte swap 4 IPV4 addresses. */
> > > dip = _mm_shuffle_epi8(dip, bswap_mask);
> > >
> > > Jerin
> > >
> > > > I think the most important question is to know what is the best solution
> > > > for performance and maintainability. The API/ABI questions will be considered
> > > > after.
> > > >
> > > > Thanks for your involvement guys.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-03 11:02 3% ` Ananyev, Konstantin
@ 2015-12-03 12:17 3% ` Jerin Jacob
2015-12-03 12:42 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2015-12-03 12:17 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev
On Thu, Dec 03, 2015 at 11:02:07AM +0000, Ananyev, Konstantin wrote:
Hi Konstantin,
> Hi Jerin,
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > Sent: Thursday, December 03, 2015 9:34 AM
> > To: Thomas Monjalon
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
> >
> > On Wed, Dec 02, 2015 at 05:57:10PM +0100, Thomas Monjalon wrote:
> > > 2015-12-02 22:23, Jerin Jacob:
> > > > On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> > > > > 2015-12-02 20:04, Jerin Jacob:
> > > > > > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > > > > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > > > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > > > > > that lead to multiple definition and its not good.
> > > > > > > >
> > > > > > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > > > > > appears in both your patch and this header file.
> > > > > >
> > > > > > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > > > > > is fine(unlike inline function).
> > > > > >
> > > > > > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > > > > > something would break the ABI.
> > > > >
> > > > > Isn't it already broken in 2.2?
> > > >
> > > > Does it mean, You would like to have rte_128i(or similar) kind of
> > > > abstraction to represent 128bit SIMD variable in DPDK?
> > >
> > > If you are convinced that it is the best way to write a generic code, yes.
> >
> > I grep-ed through DPDK API list to see the dependency with SIMD in API
> > definition.I see only rte_lpm_lookupx4 API has SIMD dependency in API
> > definition.
> >
> > I believe that's the root cause of the problem. IMO, The
> > better way to fix this would be to remove __m128i from API and have more
> > general representation to remove the architecture dependency from API
> >
> > something like this,
> >
> > rte_lpm_lookupx4(const struct rte_lpm *lpm, uint32_t *ip, uint16_t
> > hop[4], uint16_t defv)
> >
> > instead of
> >
> > rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t
> > hop[4], uint16_t defv)
>
> The idea for that function was that rte_lpm_lookupx4() accepts 4 IPv4 addresses that are:
> 1. already in 128bit register
> 2. 'prepared' - byte swap is already done for them if needed.
>
> About ways to fix __m128i dependency: as I can see x86 and arm DPDK code
> already has xmm_t typedef:
>
> $ find lib -type f | xargs grep xmm_t | grep typedef
> lib/librte_eal/common/include/arch/x86/rte_vect.h:typedef __m128i xmm_t;
> lib/librte_eal/common/include/arch/arm/rte_vect.h:typedef int32x4_t xmm_t;
>
> Why not to change rte_lpm_lookupx4() to accept xmm_t as input parameter.
> As I understand it would solve the problem, and wouldn't introduce any API/ABI breakage, right?
Yes, If we have API/ABI breakage concerns.
IMO, Now this would call for some kind of rte_vect_* abstraction load,
store, set kind of SIMD operation on xmm_t in common test code to
aviod #ifdef's in app/test/test_lpm.c
I guess we may not need those abstractions in
lib/librte_eal/common/include/arch/ directory.
keeping in app/test/xmmt_ops.h should be enough, right?
>
> Konstantin
>
> >
> > Now I am not sure why this API was created like this, from l3fwd.c
> > example, it looks to accommodate the IPV4 byte swap[1]. If it's true,
> > maybe we can have eal byte swap abstraction for optimized byte swap on
> > memory for 4 IP address in one shot
> >
> > or
> >
> > Have rte_lpm_lookupx4 take an argument for byte swap or not ?
> >
> > or
> >
> > something similar?
> >
> > Thoughts ?
> >
> > [1]
> > const __m128i bswap_mask = _mm_set_epi8(12, 13, 14, 15, 8, 9, 10, 11,
> > 4, 5, 6, 7, 0, 1, 2, 3);
> > /* Byte swap 4 IPV4 addresses. */
> > dip = _mm_shuffle_epi8(dip, bswap_mask);
> >
> > Jerin
> >
> > > I think the most important question is to know what is the best solution
> > > for performance and maintainability. The API/ABI questions will be considered
> > > after.
> > >
> > > Thanks for your involvement guys.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-02 16:50 36% [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range Panu Matilainen
2015-12-02 18:23 4% ` Neil Horman
@ 2015-12-03 12:14 29% ` Mcnamara, John
2015-12-03 13:28 4% ` Thomas Monjalon
2015-12-03 13:39 7% ` Panu Matilainen
2015-12-03 14:05 36% ` [dpdk-dev] [PATCH v2] " Panu Matilainen
2 siblings, 2 replies; 200+ results
From: Mcnamara, John @ 2015-12-03 12:14 UTC (permalink / raw)
To: Panu Matilainen, dev
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
> Sent: Wednesday, December 2, 2015 4:51 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] scripts: support any legal git revisions as
> abi validation range
>
> 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 mybrach <target>" etc in addition to validating
> between tags. Makes it easier to run the validator for in-development
> work.
Hi Panu,
+1 for this.
You might also change the ABI validation section of the docs to go along
with this. Something like the patch below. If not I'll submit it
afterwards.
Also, if someone has some bandwidth it would be good to add an option
to pass -j with an optional number to "make" in the script.
John
$ git diff
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 653c7d0..5ce5f9d 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -465,19 +465,23 @@ utilities which can be installed via a package manager. For example::
sudo yum install abi-compliance-checker
sudo yum install abi-dumper
+ sudo yum install greadelf
The syntax of the ``validate-abi.sh`` utility is::
- ./scripts/validate-abi.sh <TAG1> <TAG2> <TARGET>
+ ./scripts/validate-abi.sh <REV1> <REV2> <TARGET>
-Where ``TAG1`` and ``TAG2`` are valid git tags on the local repo and target is
-the usual DPDK compilation target.
+Where ``REV1`` and ``REV2`` are valid `gitrevisions(7)
+<https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html>`_ on the
+local repo and ``TARGET`` is the usual DPDK compilation target.
-For example to test the current committed HEAD against a previous release tag
-we could add a temporary tag and run the utility as follows::
+For example::
- git tag MY_TEMP_TAG
- ./scripts/validate-abi.sh v2.0.0 MY_TEMP_TAG x86_64-native-linuxapp-gcc
+ # Check between the previous and latest commits:
+ ./scripts/validate-abi.sh HEAD~1 HEAD x86_64-native-linuxapp-gcc
+
+ # Check between two tags:
+ ./scripts/validate-abi.sh v2.1.0 v2.2.0 x86_64-native-linuxapp-gcc
After the validation script completes (it can take a while since it need to
compile both tags) it will create compatibility reports in the
^ permalink raw reply [relevance 29%]
* Re: [dpdk-dev] [PATCH v3] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 2:22 4% ` Thomas Monjalon
@ 2015-12-03 11:24 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2015-12-03 11:24 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Thu, Dec 03, 2015 at 03:22:39AM +0100, Thomas Monjalon wrote:
> 2015-12-03 02:15, Ferruh Yigit:
> > +ifeq ($(COMBINED_BUILD),1)
> > include $(RTE_SDK)/mk/rte.sharelib.mk
> > +endif
>
> I still don't understand what was the issue with this include but it
> seems not related to versioning.
> Please condider a separate patch with a detailed explanation of the bug.
>
Indeed this is related to the using versioning macros VERSION_SYMBOL, BIND_DEFAULT_SYMBOL
But let me try to fix this in different way
> [...]
> > +FILES=$(find $RTE_SDK -name "*_version.map")
>
> No, we can have several build directories in RTE_SDK.
>
"grep -v" was to remove build output .map files, not searching for _version.map, so it should be OK
but let me narrow search path to lib and drivers folders to be safe
Thanks,
ferruh
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 8:18 4% ` [dpdk-dev] [PATCH v2] " Christian Ehrhardt
@ 2015-12-03 11:18 4% ` Ferruh Yigit
2015-12-03 14:01 4% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-12-03 11:18 UTC (permalink / raw)
To: Christian Ehrhardt; +Cc: dev
On Thu, Dec 03, 2015 at 09:18:49AM +0100, Christian Ehrhardt wrote:
> Hi Ferruh,
> some minor bash improvements that could be made in the next revision:
>
> On Thu, Dec 3, 2015 at 2:22 AM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> > diff --git a/scripts/merge_maps.sh b/scripts/merge_maps.sh
> > new file mode 100755
> > index 0000000..bc40dc8
> > --- /dev/null
> > +++ b/scripts/merge_maps.sh
> > @@ -0,0 +1,29 @@
> > +#!/bin/sh
> > +
> > +FILES=$(find $RTE_SDK -name "*.map" | grep -v build)
> > +SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
>
> Guarding $RTE_SDK and $FILES with "" will help avoid some potential
> issues due to words splitting.
>
> [...]
> > + sed -n "/$s {/,/}/p" $f | sed '/^$/d' | grep -v global | grep -v local | sed '1d' | sed '$d'
>
> As above with $f
>
> [...]
> > + if [ "$prev_sym" == "none" ]; then
>
> Should be only one = as == is non standard and could fail in some environments.
>
Thank you Christian, I will update accordingly.
Regards,
ferruh
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-03 9:33 0% ` Jerin Jacob
@ 2015-12-03 11:02 3% ` Ananyev, Konstantin
2015-12-03 12:17 3% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2015-12-03 11:02 UTC (permalink / raw)
To: Jerin Jacob, Thomas Monjalon; +Cc: dev
Hi Jerin,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> Sent: Thursday, December 03, 2015 9:34 AM
> To: Thomas Monjalon
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
>
> On Wed, Dec 02, 2015 at 05:57:10PM +0100, Thomas Monjalon wrote:
> > 2015-12-02 22:23, Jerin Jacob:
> > > On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> > > > 2015-12-02 20:04, Jerin Jacob:
> > > > > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > > > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > > > > that lead to multiple definition and its not good.
> > > > > > >
> > > > > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > > > > appears in both your patch and this header file.
> > > > >
> > > > > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > > > > is fine(unlike inline function).
> > > > >
> > > > > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > > > > something would break the ABI.
> > > >
> > > > Isn't it already broken in 2.2?
> > >
> > > Does it mean, You would like to have rte_128i(or similar) kind of
> > > abstraction to represent 128bit SIMD variable in DPDK?
> >
> > If you are convinced that it is the best way to write a generic code, yes.
>
> I grep-ed through DPDK API list to see the dependency with SIMD in API
> definition.I see only rte_lpm_lookupx4 API has SIMD dependency in API
> definition.
>
> I believe that's the root cause of the problem. IMO, The
> better way to fix this would be to remove __m128i from API and have more
> general representation to remove the architecture dependency from API
>
> something like this,
>
> rte_lpm_lookupx4(const struct rte_lpm *lpm, uint32_t *ip, uint16_t
> hop[4], uint16_t defv)
>
> instead of
>
> rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t
> hop[4], uint16_t defv)
The idea for that function was that rte_lpm_lookupx4() accepts 4 IPv4 addresses that are:
1. already in 128bit register
2. 'prepared' - byte swap is already done for them if needed.
About ways to fix __m128i dependency: as I can see x86 and arm DPDK code
already has xmm_t typedef:
$ find lib -type f | xargs grep xmm_t | grep typedef
lib/librte_eal/common/include/arch/x86/rte_vect.h:typedef __m128i xmm_t;
lib/librte_eal/common/include/arch/arm/rte_vect.h:typedef int32x4_t xmm_t;
Why not to change rte_lpm_lookupx4() to accept xmm_t as input parameter.
As I understand it would solve the problem, and wouldn't introduce any API/ABI breakage, right?
Konstantin
>
> Now I am not sure why this API was created like this, from l3fwd.c
> example, it looks to accommodate the IPV4 byte swap[1]. If it's true,
> maybe we can have eal byte swap abstraction for optimized byte swap on
> memory for 4 IP address in one shot
>
> or
>
> Have rte_lpm_lookupx4 take an argument for byte swap or not ?
>
> or
>
> something similar?
>
> Thoughts ?
>
> [1]
> const __m128i bswap_mask = _mm_set_epi8(12, 13, 14, 15, 8, 9, 10, 11,
> 4, 5, 6, 7, 0, 1, 2, 3);
> /* Byte swap 4 IPV4 addresses. */
> dip = _mm_shuffle_epi8(dip, bswap_mask);
>
> Jerin
>
> > I think the most important question is to know what is the best solution
> > for performance and maintainability. The API/ABI questions will be considered
> > after.
> >
> > Thanks for your involvement guys.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] eal: don't crash if one pci device fails
2015-12-03 1:38 3% [dpdk-dev] [PATCH] eal: don't crash if one pci device fails Stephen Hemminger
2015-12-03 10:02 0% ` Bruce Richardson
@ 2015-12-03 10:08 0% ` David Marchand
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2015-12-03 10:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Thu, Dec 3, 2015 at 2:38 AM, Stephen Hemminger <
stephen@networkplumber.org> wrote:
> If there is a failure to setup one pci device, there maybe other
> devices that can be initialized. Don't call rte_exit which
> is a forced crash, pass the error back to the
> application to decide what it wants to do.
>
> Might be good idea to return a positive value for the
> number of devices found, but that would break ABI.
>
I don't see how this return code will help the application do something
after this.
You don't know which device probe failed with just this.
rte_eal_pci_probe() returning a != 0 value will trigger a rte_panic in
rte_eal_init() anyway.
So I suppose you want to use rte_eal_pci_probe out of rte_eal_init.
In such a case, why don't you use rte_eal_pci_probe_one ?
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] eal: don't crash if one pci device fails
2015-12-03 1:38 3% [dpdk-dev] [PATCH] eal: don't crash if one pci device fails Stephen Hemminger
@ 2015-12-03 10:02 0% ` Bruce Richardson
2015-12-03 10:08 0% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2015-12-03 10:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Wed, Dec 02, 2015 at 05:38:40PM -0800, Stephen Hemminger wrote:
> If there is a failure to setup one pci device, there maybe other
> devices that can be initialized. Don't call rte_exit which
> is a forced crash, pass the error back to the
> application to decide what it wants to do.
>
> Might be good idea to return a positive value for the
> number of devices found, but that would break ABI.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The return value from this function gets passed back to rte_eal_init() where
it will still cause an application to terminate. Therefore, I think the
commit message is a little misleading.
Otherwise all looks ok to me. Will help weed out multiple device failures on
a single pass too.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 16:57 3% ` Thomas Monjalon
2015-12-02 17:38 0% ` Jerin Jacob
@ 2015-12-03 9:33 0% ` Jerin Jacob
2015-12-03 11:02 3% ` Ananyev, Konstantin
1 sibling, 1 reply; 200+ results
From: Jerin Jacob @ 2015-12-03 9:33 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Wed, Dec 02, 2015 at 05:57:10PM +0100, Thomas Monjalon wrote:
> 2015-12-02 22:23, Jerin Jacob:
> > On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> > > 2015-12-02 20:04, Jerin Jacob:
> > > > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > > > that lead to multiple definition and its not good.
> > > > > >
> > > > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > > > appears in both your patch and this header file.
> > > >
> > > > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > > > is fine(unlike inline function).
> > > >
> > > > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > > > something would break the ABI.
> > >
> > > Isn't it already broken in 2.2?
> >
> > Does it mean, You would like to have rte_128i(or similar) kind of
> > abstraction to represent 128bit SIMD variable in DPDK?
>
> If you are convinced that it is the best way to write a generic code, yes.
I grep-ed through DPDK API list to see the dependency with SIMD in API
definition.I see only rte_lpm_lookupx4 API has SIMD dependency in API
definition.
I believe that's the root cause of the problem. IMO, The
better way to fix this would be to remove __m128i from API and have more
general representation to remove the architecture dependency from API
something like this,
rte_lpm_lookupx4(const struct rte_lpm *lpm, uint32_t *ip, uint16_t
hop[4], uint16_t defv)
instead of
rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t
hop[4], uint16_t defv)
Now I am not sure why this API was created like this, from l3fwd.c
example, it looks to accommodate the IPV4 byte swap[1]. If it's true,
maybe we can have eal byte swap abstraction for optimized byte swap on
memory for 4 IP address in one shot
or
Have rte_lpm_lookupx4 take an argument for byte swap or not ?
or
something similar?
Thoughts ?
[1]
const __m128i bswap_mask = _mm_set_epi8(12, 13, 14, 15, 8, 9, 10, 11,
4, 5, 6, 7, 0, 1, 2, 3);
/* Byte swap 4 IPV4 addresses. */
dip = _mm_shuffle_epi8(dip, bswap_mask);
Jerin
> I think the most important question is to know what is the best solution
> for performance and maintainability. The API/ABI questions will be considered
> after.
>
> Thanks for your involvement guys.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 1:22 4% [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library Ferruh Yigit
2015-12-03 1:36 4% ` Thomas Monjalon
@ 2015-12-03 8:18 4% ` Christian Ehrhardt
2015-12-03 11:18 4% ` Ferruh Yigit
2015-12-03 12:49 7% ` Panu Matilainen
2 siblings, 1 reply; 200+ results
From: Christian Ehrhardt @ 2015-12-03 8:18 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
Hi Ferruh,
some minor bash improvements that could be made in the next revision:
On Thu, Dec 3, 2015 at 2:22 AM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> diff --git a/scripts/merge_maps.sh b/scripts/merge_maps.sh
> new file mode 100755
> index 0000000..bc40dc8
> --- /dev/null
> +++ b/scripts/merge_maps.sh
> @@ -0,0 +1,29 @@
> +#!/bin/sh
> +
> +FILES=$(find $RTE_SDK -name "*.map" | grep -v build)
> +SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
Guarding $RTE_SDK and $FILES with "" will help avoid some potential
issues due to words splitting.
[...]
> + sed -n "/$s {/,/}/p" $f | sed '/^$/d' | grep -v global | grep -v local | sed '1d' | sed '$d'
As above with $f
[...]
> + if [ "$prev_sym" == "none" ]; then
Should be only one = as == is non standard and could fail in some environments.
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
2015-12-03 1:31 0% ` Ferruh Yigit
@ 2015-12-03 8:11 3% ` Christian Ehrhardt
2015-12-03 14:59 0% ` Neil Horman
1 sibling, 0 replies; 200+ results
From: Christian Ehrhardt @ 2015-12-03 8:11 UTC (permalink / raw)
To: Neil Horman, Robie Basak, dev
Hi Ferruh,
while not tackling the "soname for combined lib" which I felt to be
the center of all this discussion.
I like that with your patch the symbols in the combined lib are no
more anonymous, but versioned according to the maps the DPDK sub
libraries are maintaining anyway.
Some more technical feedback on your post.
I wonder if we would find a similar solution for the overall soname version.
Unfortunately all naive approaches that came to my mind so far
(summing up LIBABIVER, biggest of LIBABIVER, ...) all have all too
obvious faults.
And I didn't have time for a complex one yet.
I feel that - in favor of non-perfect, but simple solution - it might
be easier to carry one global LIBABIVER for the combined lib that is
increased on each DPDK release IF (very likely) one of the ABIs was
changed in the Release.
Something like a LIBABISUBVER could be increased on any release that
did change, but not break the old ABI.
Well, likely still too naive - I need more time to really get into all
that - like to better understand all the benefits and drawbacks of the
linker script approach.
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
On Thu, Dec 3, 2015 at 2:31 AM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> On Wed, Dec 02, 2015 at 06:44:19AM -0500, Neil Horman wrote:
>> On Tue, Dec 01, 2015 at 12:37:37PM +0000, Robie Basak wrote:
>> > Re-sending this unsigned since the ML rejected my signed email.
>> >
>> > -1 from Ubuntu without further discussion since it will break us. Please
>> > don't commit this patch yet.
>> >
>> > I don't understand why we must have the complexity of so many shared
>> > libraries. From a distribution packaging perspective, all I see is that
>> > this multiplies potential work by twenty times and makes it awkward to
>> > work with without special tooling (which then needs maintaining).
>> >
>> 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.
>>
>> > understand why DPDK must be different to every other userspace library
>> > out there. If DPDK has a good need to be different then that's fair
>> > enough. But I feel that if DPDK is deviating from the norm then we need
>> > to frame the discussion from the perspective of "why DPDK must be
>> > different", rather than having me trying to explain why the norm is the
>> > right way to do it.
>> >
>> > On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
>> > > That's how Fedora and RHEL are shipping it already and nobody has so much
>> > > as noticed anything strange, much less complained about it. 20 libraries
>> > > is but a drop in the ocean on a average distro.
>> >
>> > No, it is 20 times the work from the perspective of DPDK package
>> > maintenance. Let me explain why.
>> >
>> > 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. 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.
>>
>>
>> > This works because of conventions around sonames, which DPDK breaks
>> > unless we treat it as twenty different libraries which changes our work
>> > from easy to painful.
>> >
>> > Usually a library transition is managed by hand by the package
>> > maintainer. It's not taxing because it's straightforward and well
>> > understood. Update and upload the new ABI source package, then find all
>> > reverse dependencies and sort them out, recursively. But if the
>> > maintainer must do it twenty times, then it becomes taxing and prone to
>> > error. And if the reverse dependency tree differs depending on the split
>> > library used by library consumers, then it gets far more complex to
>> > follow.
>> >
>> > Admittedly we could tool around this to make it easier, but that's extra
>> > work (both initially and in maintenance) and prone to error (because
>> > we'd only be doing it for DPDK).
>> >
>> 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)
>>
>> > 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.
>>
>>
>> > 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.
>>
>> > 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.
>>
>> Neil
>>
> I just sent a patch that fixes versioning in combined library, can you please check it: http://dpdk.org/dev/patchwork/patch/9259/
>
> Thanks,
> ferruh
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 2:15 4% ` [dpdk-dev] [PATCH v3] " Ferruh Yigit
@ 2015-12-03 2:22 4% ` Thomas Monjalon
2015-12-03 11:24 4% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-03 2:22 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
2015-12-03 02:15, Ferruh Yigit:
> +ifeq ($(COMBINED_BUILD),1)
> include $(RTE_SDK)/mk/rte.sharelib.mk
> +endif
I still don't understand what was the issue with this include but it
seems not related to versioning.
Please condider a separate patch with a detailed explanation of the bug.
[...]
> +FILES=$(find $RTE_SDK -name "*_version.map")
No, we can have several build directories in RTE_SDK.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] vhost: reserve some spaces for virtio_net and vhost_virtqueue struct
@ 2015-12-03 2:27 3% Yuanhan Liu
2015-12-07 23:54 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Yuanhan Liu @ 2015-12-03 2:27 UTC (permalink / raw)
To: dev; +Cc: Michael S. Tsirkin, Victor Kaplansky
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? :)
---
lib/librte_vhost/rte_virtio_net.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
index 5687452..10dcb90 100644
--- a/lib/librte_vhost/rte_virtio_net.h
+++ b/lib/librte_vhost/rte_virtio_net.h
@@ -90,6 +90,7 @@ struct vhost_virtqueue {
int callfd; /**< Used to notify the guest (trigger interrupt). */
int kickfd; /**< Currently unused as polling mode is enabled. */
int enabled;
+ uint64_t reserved[16]; /**< Reserve some spaces for future extension. */
struct buf_vector buf_vec[BUF_VECTOR_MAX]; /**< for scatter RX. */
} __rte_cache_aligned;
@@ -128,6 +129,7 @@ struct virtio_net {
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 */
+ uint64_t reserved[64]; /**< Reserve some spaces for future extension. */
struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
} __rte_cache_aligned;
--
1.9.0
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 1:59 4% ` Ferruh Yigit
@ 2015-12-03 2:15 4% ` Ferruh Yigit
2015-12-03 2:22 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-12-03 2:15 UTC (permalink / raw)
To: dev
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>
---
drivers/net/Makefile | 3 +++
lib/Makefile | 3 +++
mk/rte.sdkbuild.mk | 2 +-
mk/rte.sharelib.mk | 3 +++
scripts/merge_maps.sh | 29 +++++++++++++++++++++++++++++
5 files changed, 39 insertions(+), 1 deletion(-)
create mode 100755 scripts/merge_maps.sh
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index cddcd57..d3c865b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -51,5 +51,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
+ifeq ($(COMBINED_BUILD),1)
include $(RTE_SDK)/mk/rte.sharelib.mk
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/lib/Makefile b/lib/Makefile
index ef172ea..d0f7fb8 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -64,5 +64,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
endif
+ifeq ($(COMBINED_BUILD),1)
include $(RTE_SDK)/mk/rte.sharelib.mk
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 38ec7bd..d4e3abf 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -94,7 +94,7 @@ $(ROOTDIRS-y):
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
@if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
- $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
+ COMBINED_BUILD=1 $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
fi
%_clean:
diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
index 7bb7219..76ead09 100644
--- a/mk/rte.sharelib.mk
+++ b/mk/rte.sharelib.mk
@@ -40,6 +40,8 @@ LIB_ONE := lib$(RTE_LIBNAME).so
else
LIB_ONE := lib$(RTE_LIBNAME).a
endif
+COMBINED_MAP=$(BUILDDIR)/lib/libdpdk.map
+CPU_LDFLAGS += --version-script=$(COMBINED_MAP)
endif
.PHONY:sharelib
@@ -79,6 +81,7 @@ ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
$(LIB_ONE): FORCE
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
+ @$(SRCDIR)/scripts/merge_maps.sh > $(COMBINED_MAP)
$(O_TO_S_DO)
else
$(LIB_ONE): FORCE
diff --git a/scripts/merge_maps.sh b/scripts/merge_maps.sh
new file mode 100755
index 0000000..4ace975
--- /dev/null
+++ b/scripts/merge_maps.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+FILES=$(find $RTE_SDK -name "*_version.map")
+SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
+
+first=0
+prev_sym="none"
+
+for s in $SYMBOLS; do
+ echo "$s {"
+ echo " global:"
+ echo ""
+ for f in $FILES; do
+ sed -n "/$s {/,/}/p" $f | sed '/^$/d' | grep -v global | grep -v local | sed '1d' | sed '$d'
+ done | sort -u
+ echo ""
+ if [ $first -eq 0 ]; then
+ first=1;
+ echo " local: *;";
+ fi
+ if [ "$prev_sym" == "none" ]; then
+ echo "};";
+ prev_sym=$s;
+ else
+ echo "} $prev_sym;";
+ prev_sym=$s;
+ fi
+ echo ""
+done
--
2.5.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 1:36 4% ` Thomas Monjalon
@ 2015-12-03 1:59 4% ` Ferruh Yigit
2015-12-03 2:15 4% ` [dpdk-dev] [PATCH v3] " Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-12-03 1:59 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Thu, Dec 03, 2015 at 02:36:53AM +0100, Thomas Monjalon wrote:
> Hi Ferruh,
>
> Thanks for working on it.
>
> 2015-12-03 01:22, Ferruh Yigit:
> > +ifeq ($(COMBINED_BUILD),1)
> > include $(RTE_SDK)/mk/rte.sharelib.mk
> > +endif
> [...]
> > @if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
> > - $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
> > + COMBINED_BUILD=1 $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
>
> What is it fixing?
> The badly named sharelib is for combined build only.
lib/Makefile and drivers/net/Makefile includes sharelib.mk _always_, this flag is to include sharelib.mk only when we are compiling combined library.
Previously this inclusion was not problem because there was not common variable, now we start using common CPU_LDFLAGS variable and sharedlib.mk shouldn't included when not compiling for combined lib.
>
> [...]
> > +FILES=$(find $RTE_SDK -name "*.map" | grep -v build)
>
> The build dir is not always "build/"
>
Thanks, I will fix this and send a new patch, I assume I can rely on "*_version.map" naming convention.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-02 16:38 4% ` Thomas Monjalon
@ 2015-12-03 1:49 0% ` Yuanhan Liu
0 siblings, 0 replies; 200+ results
From: Yuanhan Liu @ 2015-12-03 1:49 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On Wed, Dec 02, 2015 at 05:38:10PM +0100, Thomas Monjalon wrote:
> 2015-12-02 22:31, Yuanhan Liu:
> > Thomas, should I write an ABI deprecation note? Can I make it for
> > v2.2 release If I make one tomorrow? (Sorry that I'm not awared
> > of that it would be an ABI break).
>
> As Panu suggested, it would be better to reserve some room now
> in 2.2 which already breaks vhost ABI.
> Maybe we have a chance to keep the same vhost ABI in 2.3.
Got it. I will cook up one now.
--yliu
>
> The 2.2 release will probably be closed in less than 2 weeks.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] eal: don't crash if one pci device fails
@ 2015-12-03 1:38 3% Stephen Hemminger
2015-12-03 10:02 0% ` Bruce Richardson
2015-12-03 10:08 0% ` David Marchand
0 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2015-12-03 1:38 UTC (permalink / raw)
To: dev
If there is a failure to setup one pci device, there maybe other
devices that can be initialized. Don't call rte_exit which
is a forced crash, pass the error back to the
application to decide what it wants to do.
Might be good idea to return a positive value for the
number of devices found, but that would break ABI.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/common/eal_common_pci.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_pci.c b/lib/librte_eal/common/eal_common_pci.c
index dcfe947..594ef9c 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -391,12 +391,13 @@ rte_eal_pci_probe(void)
struct rte_pci_device *dev = NULL;
struct rte_devargs *devargs;
int probe_all = 0;
- int ret = 0;
+ int failed = 0;
if (rte_eal_devargs_type_count(RTE_DEVTYPE_WHITELISTED_PCI) == 0)
probe_all = 1;
TAILQ_FOREACH(dev, &pci_device_list, next) {
+ int ret = 0;
/* set devargs in PCI structure */
devargs = pci_devargs_lookup(dev);
@@ -409,13 +410,17 @@ rte_eal_pci_probe(void)
else if (devargs != NULL &&
devargs->type == RTE_DEVTYPE_WHITELISTED_PCI)
ret = pci_probe_all_drivers(dev);
- if (ret < 0)
- rte_exit(EXIT_FAILURE, "Requested device " PCI_PRI_FMT
- " cannot be used\n", dev->addr.domain, dev->addr.bus,
- dev->addr.devid, dev->addr.function);
+
+ if (ret < 0) {
+ RTE_LOG(ERR, EAL,
+ "Requested device " PCI_PRI_FMT " cannot be used\n",
+ dev->addr.domain, dev->addr.bus,
+ dev->addr.devid, dev->addr.function);
+ failed = ret;
+ }
}
- return 0;
+ return failed;
}
/* dump one device */
--
2.1.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 1:22 4% [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library Ferruh Yigit
@ 2015-12-03 1:36 4% ` Thomas Monjalon
2015-12-03 1:59 4% ` Ferruh Yigit
2015-12-03 8:18 4% ` [dpdk-dev] [PATCH v2] " Christian Ehrhardt
2015-12-03 12:49 7% ` Panu Matilainen
2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-03 1:36 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
Hi Ferruh,
Thanks for working on it.
2015-12-03 01:22, Ferruh Yigit:
> +ifeq ($(COMBINED_BUILD),1)
> include $(RTE_SDK)/mk/rte.sharelib.mk
> +endif
[...]
> @if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
> - $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
> + COMBINED_BUILD=1 $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
What is it fixing?
The badly named sharelib is for combined build only.
[...]
> +FILES=$(find $RTE_SDK -name "*.map" | grep -v build)
The build dir is not always "build/"
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
2015-12-02 11:44 3% ` Neil Horman
@ 2015-12-03 1:31 0% ` Ferruh Yigit
2015-12-03 8:11 3% ` Christian Ehrhardt
2015-12-03 14:59 0% ` Neil Horman
1 sibling, 2 replies; 200+ results
From: Ferruh Yigit @ 2015-12-03 1:31 UTC (permalink / raw)
To: Neil Horman; +Cc: dev
On Wed, Dec 02, 2015 at 06:44:19AM -0500, Neil Horman wrote:
> On Tue, Dec 01, 2015 at 12:37:37PM +0000, Robie Basak wrote:
> > Re-sending this unsigned since the ML rejected my signed email.
> >
> > -1 from Ubuntu without further discussion since it will break us. Please
> > don't commit this patch yet.
> >
> > I don't understand why we must have the complexity of so many shared
> > libraries. From a distribution packaging perspective, all I see is that
> > this multiplies potential work by twenty times and makes it awkward to
> > work with without special tooling (which then needs maintaining).
> >
> 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.
>
> > understand why DPDK must be different to every other userspace library
> > out there. If DPDK has a good need to be different then that's fair
> > enough. But I feel that if DPDK is deviating from the norm then we need
> > to frame the discussion from the perspective of "why DPDK must be
> > different", rather than having me trying to explain why the norm is the
> > right way to do it.
> >
> > On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
> > > That's how Fedora and RHEL are shipping it already and nobody has so much
> > > as noticed anything strange, much less complained about it. 20 libraries
> > > is but a drop in the ocean on a average distro.
> >
> > No, it is 20 times the work from the perspective of DPDK package
> > maintenance. Let me explain why.
> >
> > 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. 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.
>
>
> > This works because of conventions around sonames, which DPDK breaks
> > unless we treat it as twenty different libraries which changes our work
> > from easy to painful.
> >
> > Usually a library transition is managed by hand by the package
> > maintainer. It's not taxing because it's straightforward and well
> > understood. Update and upload the new ABI source package, then find all
> > reverse dependencies and sort them out, recursively. But if the
> > maintainer must do it twenty times, then it becomes taxing and prone to
> > error. And if the reverse dependency tree differs depending on the split
> > library used by library consumers, then it gets far more complex to
> > follow.
> >
> > Admittedly we could tool around this to make it easier, but that's extra
> > work (both initially and in maintenance) and prone to error (because
> > we'd only be doing it for DPDK).
> >
> 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)
>
> > 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.
>
>
> > 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.
>
> > 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.
>
> Neil
>
I just sent a patch that fixes versioning in combined library, can you please check it: http://dpdk.org/dev/patchwork/patch/9259/
Thanks,
ferruh
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library
@ 2015-12-03 1:22 4% Ferruh Yigit
2015-12-03 1:36 4% ` Thomas Monjalon
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Ferruh Yigit @ 2015-12-03 1:22 UTC (permalink / raw)
To: dev
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>
---
drivers/net/Makefile | 3 +++
lib/Makefile | 3 +++
mk/rte.sdkbuild.mk | 2 +-
mk/rte.sharelib.mk | 3 +++
scripts/merge_maps.sh | 29 +++++++++++++++++++++++++++++
5 files changed, 39 insertions(+), 1 deletion(-)
create mode 100755 scripts/merge_maps.sh
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index cddcd57..d3c865b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -51,5 +51,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
+ifeq ($(COMBINED_BUILD),1)
include $(RTE_SDK)/mk/rte.sharelib.mk
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/lib/Makefile b/lib/Makefile
index ef172ea..d0f7fb8 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -64,5 +64,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
endif
+ifeq ($(COMBINED_BUILD),1)
include $(RTE_SDK)/mk/rte.sharelib.mk
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 38ec7bd..d4e3abf 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -94,7 +94,7 @@ $(ROOTDIRS-y):
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
@if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
- $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
+ COMBINED_BUILD=1 $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
fi
%_clean:
diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
index 7bb7219..76ead09 100644
--- a/mk/rte.sharelib.mk
+++ b/mk/rte.sharelib.mk
@@ -40,6 +40,8 @@ LIB_ONE := lib$(RTE_LIBNAME).so
else
LIB_ONE := lib$(RTE_LIBNAME).a
endif
+COMBINED_MAP=$(BUILDDIR)/lib/libdpdk.map
+CPU_LDFLAGS += --version-script=$(COMBINED_MAP)
endif
.PHONY:sharelib
@@ -79,6 +81,7 @@ ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
$(LIB_ONE): FORCE
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
+ @$(SRCDIR)/scripts/merge_maps.sh > $(COMBINED_MAP)
$(O_TO_S_DO)
else
$(LIB_ONE): FORCE
diff --git a/scripts/merge_maps.sh b/scripts/merge_maps.sh
new file mode 100755
index 0000000..bc40dc8
--- /dev/null
+++ b/scripts/merge_maps.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+FILES=$(find $RTE_SDK -name "*.map" | grep -v build)
+SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
+
+first=0
+prev_sym="none"
+
+for s in $SYMBOLS; do
+ echo "$s {"
+ echo " global:"
+ echo ""
+ for f in $FILES; do
+ sed -n "/$s {/,/}/p" $f | sed '/^$/d' | grep -v global | grep -v local | sed '1d' | sed '$d'
+ done | sort -u
+ echo ""
+ if [ $first -eq 0 ]; then
+ first=1;
+ echo " local: *;";
+ fi
+ if [ "$prev_sym" == "none" ]; then
+ echo "};";
+ prev_sym=$s;
+ else
+ echo "} $prev_sym;";
+ prev_sym=$s;
+ fi
+ echo ""
+done
--
2.5.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 3/3] rte_sched: eliminate floating point in calculating byte clock
2015-12-02 16:48 0% ` Dumitrescu, Cristian
@ 2015-12-02 22:08 0% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2015-12-02 22:08 UTC (permalink / raw)
To: Dumitrescu, Cristian; +Cc: dev
On Wed, 2 Dec 2015 16:48:17 +0000
"Dumitrescu, Cristian" <cristian.dumitrescu@intel.com> wrote:
>
>
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Sunday, November 29, 2015 8:47 PM
> > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> > Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>
> > Subject: [PATCH 3/3] rte_sched: eliminate floating point in calculating byte
> > clock
> >
> > The old code was doing a floating point divide for each rte_dequeue()
> > which is very expensive. Change to using fixed point scaled inverse
> > multiply. To maintain equivalent precision, scaled math is used.
> > The application ABI is the same.
> >
> > This improved performance from 5Gbit/sec to 10 Gbit/sec when configured
> > for 10 Gbit/sec rate.
> >
> > There was some feedback from Cristian that he wanted a better
> > solution and was going to give one, but none was provided.
> > For 2.2 this is a better solution than existing code, if someone
> > has a better version I would love to see it.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > ---
> > lib/librte_sched/rte_sched.c | 23 ++++++++++++++++++-----
> > 1 file changed, 18 insertions(+), 5 deletions(-)
> >
> > diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
> > index 16acd6b..cfae136 100644
> > --- a/lib/librte_sched/rte_sched.c
> > +++ b/lib/librte_sched/rte_sched.c
> > @@ -47,6 +47,7 @@
> > #include "rte_bitmap.h"
> > #include "rte_sched_common.h"
> > #include "rte_approx.h"
> > +#include "rte_reciprocal.h"
> >
> > #ifdef __INTEL_COMPILER
> > #pragma warning(disable:2259) /* conversion may lose significant bits */
> > @@ -62,6 +63,11 @@
> > #define RTE_SCHED_PIPE_INVALID UINT32_MAX
> > #define RTE_SCHED_BMP_POS_INVALID UINT32_MAX
> >
> > +/* Scaling for cycles_per_byte calculation
> > + * Chosen so that minimum rate is 480 bit/sec
> > + */
> > +#define RTE_SCHED_TIME_SHIFT 8
>
> Stephen, can you please elaborate why we need to shift the dividend at all and why the shift value was picked as 8? Is 8 a hard constraint? How does this affect the scheduling precision/accuracy?
The shift value is a tradeoff for scaled math. The bigger the shift
the finer the resolution, but at the risk of overflow in the cycles_per_byte.
The value was chosen as a tradeoff based on current CPU clock rate (TSC)
and minimum rate.
> > +
> > struct rte_sched_subport {
> > /* Token bucket (TB) */
> > uint64_t tb_time; /* time of last update */
> > @@ -215,7 +221,7 @@ struct rte_sched_port {
> > uint64_t time_cpu_cycles; /* Current CPU time measured in CPU
> > cyles */
> > uint64_t time_cpu_bytes; /* Current CPU time measured in bytes
> > */
> > uint64_t time; /* Current NIC TX time measured in bytes */
> > - double cycles_per_byte; /* CPU cycles per byte */
> > + struct rte_reciprocal inv_cycles_per_byte; /* CPU cycles per byte */
> >
> > /* Scheduling loop detection */
> > uint32_t pipe_loop;
> > @@ -610,7 +616,7 @@ struct rte_sched_port *
> > rte_sched_port_config(struct rte_sched_port_params *params)
> > {
> > struct rte_sched_port *port = NULL;
> > - uint32_t mem_size, bmp_mem_size, n_queues_per_port, i;
> > + uint32_t mem_size, bmp_mem_size, n_queues_per_port, i,
> > cycles_per_byte;
> >
> > /* Check user parameters. Determine the amount of memory to
> > allocate */
> > mem_size = rte_sched_port_get_memory_footprint(params);
> > @@ -661,7 +667,10 @@ rte_sched_port_config(struct
> > rte_sched_port_params *params)
> > port->time_cpu_cycles = rte_get_tsc_cycles();
> > port->time_cpu_bytes = 0;
> > port->time = 0;
> > - port->cycles_per_byte = ((double) rte_get_tsc_hz()) / ((double)
> > params->rate);
> > +
> > + cycles_per_byte = (rte_get_tsc_hz() << RTE_SCHED_TIME_SHIFT)
> > + / params->rate;
> > + port->inv_cycles_per_byte = rte_reciprocal_value(cycles_per_byte);
> >
> > /* Scheduling loop detection */
> > port->pipe_loop = RTE_SCHED_PIPE_INVALID;
> > @@ -2088,11 +2097,15 @@ rte_sched_port_time_resync(struct
> > rte_sched_port *port)
> > {
> > uint64_t cycles = rte_get_tsc_cycles();
> > uint64_t cycles_diff = cycles - port->time_cpu_cycles;
> > - double bytes_diff = ((double) cycles_diff) / port->cycles_per_byte;
> > + uint64_t bytes_diff;
> > +
> > + /* Compute elapsed time in bytes */
> > + bytes_diff = rte_reciprocal_divide(cycles_diff <<
> > RTE_SCHED_TIME_SHIFT,
> > + port->inv_cycles_per_byte);
> >
> > /* Advance port time */
> > port->time_cpu_cycles = cycles;
> > - port->time_cpu_bytes += (uint64_t) bytes_diff;
> > + port->time_cpu_bytes += bytes_diff;
> > if (port->time < port->time_cpu_bytes)
> > port->time = port->time_cpu_bytes;
> >
> > --
> > 2.1.4
>
> Can you provide some insight into how you tested this code and the test vectors you used?
We tested with 10 gbit link and range of rates from 10k bit up to 10 gbit.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-02 16:50 36% [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range Panu Matilainen
@ 2015-12-02 18:23 4% ` Neil Horman
2015-12-03 12:14 29% ` Mcnamara, John
2015-12-03 14:05 36% ` [dpdk-dev] [PATCH v2] " Panu Matilainen
2 siblings, 0 replies; 200+ results
From: Neil Horman @ 2015-12-02 18:23 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
On Wed, Dec 02, 2015 at 06:50:47PM +0200, 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 mybrach <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>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 16:57 3% ` Thomas Monjalon
@ 2015-12-02 17:38 0% ` Jerin Jacob
2015-12-03 9:33 0% ` Jerin Jacob
1 sibling, 0 replies; 200+ results
From: Jerin Jacob @ 2015-12-02 17:38 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Wed, Dec 02, 2015 at 05:57:10PM +0100, Thomas Monjalon wrote:
> 2015-12-02 22:23, Jerin Jacob:
> > On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> > > 2015-12-02 20:04, Jerin Jacob:
> > > > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > > > that lead to multiple definition and its not good.
> > > > > >
> > > > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > > > appears in both your patch and this header file.
> > > >
> > > > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > > > is fine(unlike inline function).
> > > >
> > > > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > > > something would break the ABI.
> > >
> > > Isn't it already broken in 2.2?
> >
> > Does it mean, You would like to have rte_128i(or similar) kind of
> > abstraction to represent 128bit SIMD variable in DPDK?
>
> If you are convinced that it is the best way to write a generic code, yes.
> I think the most important question is to know what is the best solution
> for performance and maintainability. The API/ABI questions will be considered
IMO, a true portable platform-independent library may need rte_128i kind
of abstracttion to represent a 128bit SIMD variable. I can send an RFC
patch to see the changes required across the DPDK.
> after.
>
> Thanks for your involvement guys.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-02 16:58 0% ` Panu Matilainen
@ 2015-12-02 17:24 3% ` Michael S. Tsirkin
0 siblings, 0 replies; 200+ results
From: Michael S. Tsirkin @ 2015-12-02 17:24 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Victor Kaplansky
On Wed, Dec 02, 2015 at 06:58:03PM +0200, Panu Matilainen wrote:
> On 12/02/2015 05:09 PM, Yuanhan Liu wrote:
> >On Wed, Dec 02, 2015 at 04:48:14PM +0200, Panu Matilainen wrote:
> >...
> >>>>>diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
> >>>>>index 5687452..416dac2 100644
> >>>>>--- a/lib/librte_vhost/rte_virtio_net.h
> >>>>>+++ b/lib/librte_vhost/rte_virtio_net.h
> >>>>>@@ -127,6 +127,8 @@ struct virtio_net {
> >>>>> #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 */
> >>>>>+ uint64_t log_size; /**< Size of log area */
> >>>>>+ uint8_t *log_base; /**< Where dirty pages are logged */
> >>>>> void *priv; /**< private context */
> >>>>> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
> >>>>> } __rte_cache_aligned;
> >>>>
> >>>>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.
> >>>
> >>>I was thinking that adding a new field (instead of renaming it or
> >>>removing it) isn't an ABI break. So, I was wrong?
> >>
> >>Adding or removing a field in the middle of a public struct is
> >>always an ABI break. Adding to the end often is too, but not always.
> >>Renaming a field is an API break but not an ABI break - the compiler
> >>cares but the cpu does not.
> >
> >Good to know. Thanks.
> >
> >>
> >>>>
> >>>>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.
> >>>
> >>>It will not be compatible, unless we add exact same fields (not
> >>>something like uint8_t pad[xx]). Otherwise, the pad field renaming
> >>>is also an ABI break, right?
> >>
> >>There's no ABI (or API) break in changing reserved unused fields to
> >>something else, as long as care is taken with sizes and alignment.
> >
> >as long as we don't reference the reserved unused fields?
>
> That would be the definition of an unused field I think :)
> Call it "reserved" if you want, it doesn't really matter as long as its
> clear its something you shouldn't be using.
>
> >
> >>In any case padding is best added to the end of a struct to minimize
> >>risks and keep things simple.
> >
> >The thing is that isn't it a bit aweful to (always) add pads to
> >the end of a struct, especially when you don't know how many
> >need to be padded?
>
> Then you pad for what you think you need, plus a bit extra, and maybe some
> more for others who might want to extend it. What is a reasonable amount
> needs deciding case by case - if a struct is alloced in the millions then be
> (very) conservative, but if there are one or 50 such structs within an app
> lifetime then who cares if its bit larger?
>
> And yeah padding may be annoying, but that's pretty much the only option in
> a project where most of the structs are out in the open.
>
> - Panu -
Functions versioning is another option.
For a sufficiently widely used struct, it's a lot of work, padding
is easier. But it might be better than breaking ABI
if e.g. you didn't pad enough.
> >
> > --yliu
> >
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 16:53 0% ` Jerin Jacob
@ 2015-12-02 16:57 3% ` Thomas Monjalon
2015-12-02 17:38 0% ` Jerin Jacob
2015-12-03 9:33 0% ` Jerin Jacob
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2015-12-02 16:57 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev
2015-12-02 22:23, Jerin Jacob:
> On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> > 2015-12-02 20:04, Jerin Jacob:
> > > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > > that lead to multiple definition and its not good.
> > > > >
> > > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > > appears in both your patch and this header file.
> > >
> > > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > > is fine(unlike inline function).
> > >
> > > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > > something would break the ABI.
> >
> > Isn't it already broken in 2.2?
>
> Does it mean, You would like to have rte_128i(or similar) kind of
> abstraction to represent 128bit SIMD variable in DPDK?
If you are convinced that it is the best way to write a generic code, yes.
I think the most important question is to know what is the best solution
for performance and maintainability. The API/ABI questions will be considered
after.
Thanks for your involvement guys.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-02 15:09 0% ` Yuanhan Liu
@ 2015-12-02 16:58 0% ` Panu Matilainen
2015-12-02 17:24 3% ` Michael S. Tsirkin
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-02 16:58 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On 12/02/2015 05:09 PM, Yuanhan Liu wrote:
> On Wed, Dec 02, 2015 at 04:48:14PM +0200, Panu Matilainen wrote:
> ...
>>>>> diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
>>>>> index 5687452..416dac2 100644
>>>>> --- a/lib/librte_vhost/rte_virtio_net.h
>>>>> +++ b/lib/librte_vhost/rte_virtio_net.h
>>>>> @@ -127,6 +127,8 @@ struct virtio_net {
>>>>> #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 */
>>>>> + uint64_t log_size; /**< Size of log area */
>>>>> + uint8_t *log_base; /**< Where dirty pages are logged */
>>>>> void *priv; /**< private context */
>>>>> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
>>>>> } __rte_cache_aligned;
>>>>
>>>> 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.
>>>
>>> I was thinking that adding a new field (instead of renaming it or
>>> removing it) isn't an ABI break. So, I was wrong?
>>
>> Adding or removing a field in the middle of a public struct is
>> always an ABI break. Adding to the end often is too, but not always.
>> Renaming a field is an API break but not an ABI break - the compiler
>> cares but the cpu does not.
>
> Good to know. Thanks.
>
>>
>>>>
>>>> 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.
>>>
>>> It will not be compatible, unless we add exact same fields (not
>>> something like uint8_t pad[xx]). Otherwise, the pad field renaming
>>> is also an ABI break, right?
>>
>> There's no ABI (or API) break in changing reserved unused fields to
>> something else, as long as care is taken with sizes and alignment.
>
> as long as we don't reference the reserved unused fields?
That would be the definition of an unused field I think :)
Call it "reserved" if you want, it doesn't really matter as long as its
clear its something you shouldn't be using.
>
>> In any case padding is best added to the end of a struct to minimize
>> risks and keep things simple.
>
> The thing is that isn't it a bit aweful to (always) add pads to
> the end of a struct, especially when you don't know how many
> need to be padded?
Then you pad for what you think you need, plus a bit extra, and maybe
some more for others who might want to extend it. What is a reasonable
amount needs deciding case by case - if a struct is alloced in the
millions then be (very) conservative, but if there are one or 50 such
structs within an app lifetime then who cares if its bit larger?
And yeah padding may be annoying, but that's pretty much the only option
in a project where most of the structs are out in the open.
- Panu -
>
> --yliu
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 16:40 0% ` Thomas Monjalon
@ 2015-12-02 16:53 0% ` Jerin Jacob
2015-12-02 16:57 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2015-12-02 16:53 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> 2015-12-02 20:04, Jerin Jacob:
> > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > that lead to multiple definition and its not good.
> > > >
> > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > appears in both your patch and this header file.
> >
> > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > is fine(unlike inline function).
> >
> > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > something would break the ABI.
>
> Isn't it already broken in 2.2?
Does it mean, You would like to have rte_128i(or similar) kind of
abstraction to represent 128bit SIMD variable in DPDK?
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
@ 2015-12-02 16:50 36% Panu Matilainen
2015-12-02 18:23 4% ` Neil Horman
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Panu Matilainen @ 2015-12-02 16:50 UTC (permalink / raw)
To: dev
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 mybrach <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>
---
scripts/validate-abi.sh | 26 ++++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/scripts/validate-abi.sh b/scripts/validate-abi.sh
index 4476433..0e3ccd7 100755
--- a/scripts/validate-abi.sh
+++ b/scripts/validate-abi.sh
@@ -43,16 +43,15 @@ log() {
}
validate_tags() {
- git tag -l | grep -q "$TAG1"
- if [ $? -ne 0 ]
+
+ if [ -z "$HASH1" ]
then
- echo "$TAG1 is invalid"
+ echo "invalid revision: $TAG1"
return
fi
- git tag -l | grep -q "$TAG2"
- if [ $? -ne 0 ]
+ if [ -z "$HASH2" ]
then
- echo "$TAG2 is invalid"
+ echo "invalid revision: $TAG2"
return
fi
}
@@ -112,6 +111,9 @@ 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)
+
# Make sure our tags exist
res=$(validate_tags)
if [ -n "$res" ]
@@ -120,6 +122,10 @@ then
cleanup_and_exit 1
fi
+# Make hashes available in output for non-local reference
+TAG1="$TAG1 ($HASH1)"
+TAG2="$TAG2 ($HASH2)"
+
ABICHECK=`which abi-compliance-checker 2>/dev/null`
if [ $? -ne 0 ]
then
@@ -152,7 +158,7 @@ cd $(dirname $0)/..
log "INFO" "Checking out version $TAG1 of the dpdk"
# Move to the old version of the tree
-git checkout $TAG1
+git checkout $HASH1
# Make sure we configure SHARED libraries
# Also turn off IGB and KNI as those require kernel headers to build
@@ -185,7 +191,7 @@ cd $TARGET/lib
log "INFO" "COLLECTING ABI INFORMATION FOR $TAG1"
for i in `ls *.so`
do
- $ABIDUMP $i -o $ABI_DIR/$i-ABI-0.dump -lver $TAG1
+ $ABIDUMP $i -o $ABI_DIR/$i-ABI-0.dump -lver $HASH1
done
cd ../..
@@ -194,7 +200,7 @@ git clean -f -d
git reset --hard
# Move to the new version of the tree
log "INFO" "Checking out version $TAG2 of the dpdk"
-git checkout $TAG2
+git checkout $HASH2
# Make sure we configure SHARED libraries
# Also turn off IGB and KNI as those require kernel headers to build
@@ -220,7 +226,7 @@ cd $TARGET/lib
log "INFO" "COLLECTING ABI INFORMATION FOR $TAG2"
for i in `ls *.so`
do
- $ABIDUMP $i -o $ABI_DIR/$i-ABI-1.dump -lver $TAG2
+ $ABIDUMP $i -o $ABI_DIR/$i-ABI-1.dump -lver $HASH2
done
cd ../..
--
2.5.0
^ permalink raw reply [relevance 36%]
* Re: [dpdk-dev] [PATCH 3/3] rte_sched: eliminate floating point in calculating byte clock
@ 2015-12-02 16:48 0% ` Dumitrescu, Cristian
2015-12-02 22:08 0% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Dumitrescu, Cristian @ 2015-12-02 16:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Sunday, November 29, 2015 8:47 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>
> Subject: [PATCH 3/3] rte_sched: eliminate floating point in calculating byte
> clock
>
> The old code was doing a floating point divide for each rte_dequeue()
> which is very expensive. Change to using fixed point scaled inverse
> multiply. To maintain equivalent precision, scaled math is used.
> The application ABI is the same.
>
> This improved performance from 5Gbit/sec to 10 Gbit/sec when configured
> for 10 Gbit/sec rate.
>
> There was some feedback from Cristian that he wanted a better
> solution and was going to give one, but none was provided.
> For 2.2 this is a better solution than existing code, if someone
> has a better version I would love to see it.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> lib/librte_sched/rte_sched.c | 23 ++++++++++++++++++-----
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
> index 16acd6b..cfae136 100644
> --- a/lib/librte_sched/rte_sched.c
> +++ b/lib/librte_sched/rte_sched.c
> @@ -47,6 +47,7 @@
> #include "rte_bitmap.h"
> #include "rte_sched_common.h"
> #include "rte_approx.h"
> +#include "rte_reciprocal.h"
>
> #ifdef __INTEL_COMPILER
> #pragma warning(disable:2259) /* conversion may lose significant bits */
> @@ -62,6 +63,11 @@
> #define RTE_SCHED_PIPE_INVALID UINT32_MAX
> #define RTE_SCHED_BMP_POS_INVALID UINT32_MAX
>
> +/* Scaling for cycles_per_byte calculation
> + * Chosen so that minimum rate is 480 bit/sec
> + */
> +#define RTE_SCHED_TIME_SHIFT 8
Stephen, can you please elaborate why we need to shift the dividend at all and why the shift value was picked as 8? Is 8 a hard constraint? How does this affect the scheduling precision/accuracy?
> +
> struct rte_sched_subport {
> /* Token bucket (TB) */
> uint64_t tb_time; /* time of last update */
> @@ -215,7 +221,7 @@ struct rte_sched_port {
> uint64_t time_cpu_cycles; /* Current CPU time measured in CPU
> cyles */
> uint64_t time_cpu_bytes; /* Current CPU time measured in bytes
> */
> uint64_t time; /* Current NIC TX time measured in bytes */
> - double cycles_per_byte; /* CPU cycles per byte */
> + struct rte_reciprocal inv_cycles_per_byte; /* CPU cycles per byte */
>
> /* Scheduling loop detection */
> uint32_t pipe_loop;
> @@ -610,7 +616,7 @@ struct rte_sched_port *
> rte_sched_port_config(struct rte_sched_port_params *params)
> {
> struct rte_sched_port *port = NULL;
> - uint32_t mem_size, bmp_mem_size, n_queues_per_port, i;
> + uint32_t mem_size, bmp_mem_size, n_queues_per_port, i,
> cycles_per_byte;
>
> /* Check user parameters. Determine the amount of memory to
> allocate */
> mem_size = rte_sched_port_get_memory_footprint(params);
> @@ -661,7 +667,10 @@ rte_sched_port_config(struct
> rte_sched_port_params *params)
> port->time_cpu_cycles = rte_get_tsc_cycles();
> port->time_cpu_bytes = 0;
> port->time = 0;
> - port->cycles_per_byte = ((double) rte_get_tsc_hz()) / ((double)
> params->rate);
> +
> + cycles_per_byte = (rte_get_tsc_hz() << RTE_SCHED_TIME_SHIFT)
> + / params->rate;
> + port->inv_cycles_per_byte = rte_reciprocal_value(cycles_per_byte);
>
> /* Scheduling loop detection */
> port->pipe_loop = RTE_SCHED_PIPE_INVALID;
> @@ -2088,11 +2097,15 @@ rte_sched_port_time_resync(struct
> rte_sched_port *port)
> {
> uint64_t cycles = rte_get_tsc_cycles();
> uint64_t cycles_diff = cycles - port->time_cpu_cycles;
> - double bytes_diff = ((double) cycles_diff) / port->cycles_per_byte;
> + uint64_t bytes_diff;
> +
> + /* Compute elapsed time in bytes */
> + bytes_diff = rte_reciprocal_divide(cycles_diff <<
> RTE_SCHED_TIME_SHIFT,
> + port->inv_cycles_per_byte);
>
> /* Advance port time */
> port->time_cpu_cycles = cycles;
> - port->time_cpu_bytes += (uint64_t) bytes_diff;
> + port->time_cpu_bytes += bytes_diff;
> if (port->time < port->time_cpu_bytes)
> port->time = port->time_cpu_bytes;
>
> --
> 2.1.4
Can you provide some insight into how you tested this code and the test vectors you used?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 14:34 3% ` Jerin Jacob
@ 2015-12-02 16:40 0% ` Thomas Monjalon
2015-12-02 16:53 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-02 16:40 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev
2015-12-02 20:04, Jerin Jacob:
> On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > that lead to multiple definition and its not good.
> > >
> > But you will have similar issue since "typedef int32x4_t __m128i"
> > appears in both your patch and this header file.
>
> I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> is fine(unlike inline function).
>
> my intention to keep __m128i "as is" because changing the __m128i to rte_???
> something would break the ABI.
Isn't it already broken in 2.2?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-02 14:31 5% ` Yuanhan Liu
2015-12-02 14:48 4% ` Panu Matilainen
@ 2015-12-02 16:38 4% ` Thomas Monjalon
2015-12-03 1:49 0% ` Yuanhan Liu
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-02 16:38 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
2015-12-02 22:31, Yuanhan Liu:
> Thomas, should I write an ABI deprecation note? Can I make it for
> v2.2 release If I make one tomorrow? (Sorry that I'm not awared
> of that it would be an ABI break).
As Panu suggested, it would be better to reserve some room now
in 2.2 which already breaks vhost ABI.
Maybe we have a chance to keep the same vhost ABI in 2.3.
The 2.2 release will probably be closed in less than 2 weeks.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-02 14:48 4% ` Panu Matilainen
@ 2015-12-02 15:09 0% ` Yuanhan Liu
2015-12-02 16:58 0% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Yuanhan Liu @ 2015-12-02 15:09 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On Wed, Dec 02, 2015 at 04:48:14PM +0200, Panu Matilainen wrote:
...
> >>>diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
> >>>index 5687452..416dac2 100644
> >>>--- a/lib/librte_vhost/rte_virtio_net.h
> >>>+++ b/lib/librte_vhost/rte_virtio_net.h
> >>>@@ -127,6 +127,8 @@ struct virtio_net {
> >>> #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 */
> >>>+ uint64_t log_size; /**< Size of log area */
> >>>+ uint8_t *log_base; /**< Where dirty pages are logged */
> >>> void *priv; /**< private context */
> >>> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
> >>> } __rte_cache_aligned;
> >>
> >>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.
> >
> >I was thinking that adding a new field (instead of renaming it or
> >removing it) isn't an ABI break. So, I was wrong?
>
> Adding or removing a field in the middle of a public struct is
> always an ABI break. Adding to the end often is too, but not always.
> Renaming a field is an API break but not an ABI break - the compiler
> cares but the cpu does not.
Good to know. Thanks.
>
> >>
> >>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.
> >
> >It will not be compatible, unless we add exact same fields (not
> >something like uint8_t pad[xx]). Otherwise, the pad field renaming
> >is also an ABI break, right?
>
> There's no ABI (or API) break in changing reserved unused fields to
> something else, as long as care is taken with sizes and alignment.
as long as we don't reference the reserved unused fields?
> In any case padding is best added to the end of a struct to minimize
> risks and keep things simple.
The thing is that isn't it a bit aweful to (always) add pads to
the end of a struct, especially when you don't know how many
need to be padded?
--yliu
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/3] eal: introduce rte_vect_* abstractions
2015-12-02 13:43 3% ` Jan Viktorin
@ 2015-12-02 14:51 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2015-12-02 14:51 UTC (permalink / raw)
To: Jan Viktorin; +Cc: dev
On Wed, Dec 02, 2015 at 02:43:34PM +0100, Jan Viktorin wrote:
> On Mon, 30 Nov 2015 22:54:11 +0530
> Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
>
> > introduce rte_vect_* abstractions to remove SSE/AVX specific
> > code in the common code(i.e the test applications)
> >
> > The patch does not provide any functional change for IA, the goal is to
>
> Does IA mean Intel Architecture?
Yes.
>
> > have infrastructure to reuse the common vector-based test code across
> > all the architectures.
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
> > lib/librte_eal/common/include/arch/arm/rte_vect.h | 17 ++++++++++++++++-
> > lib/librte_eal/common/include/arch/x86/rte_vect.h | 8 ++++++++
> > 2 files changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> > index 21cdb4d..d300951 100644
> > --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> > +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> > @@ -33,13 +33,14 @@
> > #ifndef _RTE_VECT_ARM_H_
> > #define _RTE_VECT_ARM_H_
> >
> > -#include "arm_neon.h"
> > +#include <arm_neon.h>
> >
> > #ifdef __cplusplus
> > extern "C" {
> > #endif
> >
> > typedef int32x4_t xmm_t;
> > +typedef int32x4_t __m128i;
>
> As Jianbo pointed out recently, the __m128i type should be refactored in
> a general rte_vect API too. If we do something like
>
> #if SSE
> typedef __m128i rte_128i;
> #elif NEON
> typedef int32x4_y rte_128i;
> #endif
>
> does it make somebody angry? I am afraid that it will influence a lot of
> code. However, from the ABI point of view, it is OK, isn't it?
>
> >
> > #define XMM_SIZE (sizeof(xmm_t))
> > #define XMM_MASK (XMM_SIZE - 1)
> > @@ -53,6 +54,20 @@ typedef union rte_xmm {
> > double pd[XMM_SIZE / sizeof(double)];
> > } __attribute__((aligned(16))) rte_xmm_t;
> >
> > +/* rte_vect_* abstraction implementation using NEON */
> > +
> > +/* loads the __m128i value from address p(does not need to be 16-byte aligned)*/
> > +#define rte_vect_loadu_sil128(p) vld1q_s32((const int32_t *)p)
> > +
> > +/* sets the 4 signed 32-bit integer values and returns the __m128i variable */
> > +static inline __m128i __attribute__((always_inline))
> > +rte_vect_set_epi32(int i3, int i2, int i1, int i0)
> > +{
> > + int32_t data[4] = {i0, i1, i2, i3};
> > +
> > + return vld1q_s32(data);
> > +}
> > +
> > #ifdef __cplusplus
> > }
> > #endif
> > diff --git a/lib/librte_eal/common/include/arch/x86/rte_vect.h b/lib/librte_eal/common/include/arch/x86/rte_vect.h
> > index b698797..91c6523 100644
> > --- a/lib/librte_eal/common/include/arch/x86/rte_vect.h
> > +++ b/lib/librte_eal/common/include/arch/x86/rte_vect.h
> > @@ -125,6 +125,14 @@ typedef union rte_ymm {
> > })
> > #endif /* (defined(__ICC) && __ICC < 1210) */
> >
> > +/* rte_vect_* abstraction implementation using SSE */
> > +
> > +/* loads the __m128i value from address p(does not need to be 16-byte aligned)*/
> > +#define rte_vect_loadu_sil128(p) _mm_loadu_si128(p)
> > +
> > +/* sets the 4 signed 32-bit integer values and returns the __m128i variable */
> > +#define rte_vect_set_epi32(i3, i2, i1, i0) _mm_set_epi32(i3, i2, i1, i0)
> > +
> > #ifdef __cplusplus
> > }
> > #endif
>
> I like this approach. It is a question whether to inherit names from
> SSE. However, why to reinvent the wheel...
>
> We probably need other people to give their ideas about such
> generalization of the API.
Yes, I would like get the feedback from other people.
ret_vect_* abstraction only for the common code (i.e test code) which
typically used to call the SIMD DPDK API's across the architecture.
>
> I think, there should be an autotest of the rte_vect API. Is it
> possible to create one?
Yes
>
> Regards
> Jan
>
> --
> 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 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-02 14:31 5% ` Yuanhan Liu
@ 2015-12-02 14:48 4% ` Panu Matilainen
2015-12-02 15:09 0% ` Yuanhan Liu
2015-12-02 16:38 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-02 14:48 UTC (permalink / raw)
To: Yuanhan Liu, Thomas Monjalon; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On 12/02/2015 04:31 PM, Yuanhan Liu wrote:
> On Wed, Dec 02, 2015 at 03:53:45PM +0200, Panu Matilainen wrote:
>> On 12/02/2015 05:43 AM, Yuanhan Liu wrote:
>>> VHOST_USER_SET_LOG_BASE request is used to tell the backend (dpdk
>>> vhost-user) where we should log dirty pages, and how big the log
>>> buffer is.
>>>
>>> This request introduces a new payload:
>>>
>>> typedef struct VhostUserLog {
>>> uint64_t mmap_size;
>>> uint64_t mmap_offset;
>>> } VhostUserLog;
>>>
>>> Also, a fd is delivered from QEMU by ancillary data.
>>>
>>> With those info given, an area of memory is mmaped, assigned
>>> to dev->log_base, for logging dirty pages.
>>>
>>> Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
>>> ---
>>> lib/librte_vhost/rte_virtio_net.h | 2 ++
>>> lib/librte_vhost/vhost_user/vhost-net-user.c | 7 ++++-
>>> lib/librte_vhost/vhost_user/vhost-net-user.h | 6 ++++
>>> lib/librte_vhost/vhost_user/virtio-net-user.c | 44 +++++++++++++++++++++++++++
>>> lib/librte_vhost/vhost_user/virtio-net-user.h | 1 +
>>> 5 files changed, 59 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
>>> index 5687452..416dac2 100644
>>> --- a/lib/librte_vhost/rte_virtio_net.h
>>> +++ b/lib/librte_vhost/rte_virtio_net.h
>>> @@ -127,6 +127,8 @@ struct virtio_net {
>>> #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 */
>>> + uint64_t log_size; /**< Size of log area */
>>> + uint8_t *log_base; /**< Where dirty pages are logged */
>>> void *priv; /**< private context */
>>> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
>>> } __rte_cache_aligned;
>>
>> 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.
>
> I was thinking that adding a new field (instead of renaming it or
> removing it) isn't an ABI break. So, I was wrong?
Adding or removing a field in the middle of a public struct is always an
ABI break. Adding to the end often is too, but not always.
Renaming a field is an API break but not an ABI break - the compiler
cares but the cpu does not.
>>
>> 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.
>
> It will not be compatible, unless we add exact same fields (not
> something like uint8_t pad[xx]). Otherwise, the pad field renaming
> is also an ABI break, right?
There's no ABI (or API) break in changing reserved unused fields to
something else, as long as care is taken with sizes and alignment. In
any case padding is best added to the end of a struct to minimize risks
and keep things simple.
- Panu -
>
> Thomas, should I write an ABI deprecation note? Can I make it for
> v2.2 release If I make one tomorrow? (Sorry that I'm not awared
> of that it would be an ABI break).
>
> --yliu
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 13:13 0% ` Jianbo Liu
@ 2015-12-02 14:34 3% ` Jerin Jacob
2015-12-02 16:40 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2015-12-02 14:34 UTC (permalink / raw)
To: Jianbo Liu; +Cc: dev
On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > On Wed, Dec 02, 2015 at 05:49:41PM +0800, Jianbo Liu wrote:
> >> On 2 December 2015 at 16:03, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> >> > On Wed, Dec 02, 2015 at 02:54:52PM +0800, Jianbo Liu wrote:
> >> >> On 2 December 2015 at 00:41, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> >> >> > On Tue, Dec 01, 2015 at 01:41:15PM -0500, Jianbo Liu wrote:
> >> >> >> Adds ARM NEON support for lpm.
> >> >> >> And enables table/pipeline libraries which depend on lpm.
> >> >> >
> >> >> > I already sent the patch on the same yesterday.
> >> >> > We can converge the patches after the discussion.
> >> >> > Please check "[dpdk-dev] [PATCH 0/3] add lpm support for NEON" on ml
> >> >> >
> >> >> Yes, I have read your patch. But there are many differences, so I sent
> >> >> mine for your reviewing :)
> >> >>
> >> >> >
> >> >> >>
> >> >> >> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
> >> >> >> ---
> >> >> >> config/defconfig_arm-armv7a-linuxapp-gcc | 3 -
> >> >> >> config/defconfig_arm64-armv8a-linuxapp-gcc | 3 -
> >> >> >> lib/librte_eal/common/include/arch/arm/rte_vect.h | 28 ++++++++++
> >> >> >> lib/librte_lpm/rte_lpm.h | 68 ++++++++++++++++-------
> >> >> >> 4 files changed, 77 insertions(+), 25 deletions(-)
> >> >> >>
> >> >> >> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc
> >> >> >> index cbebd64..efffa1f 100644
> >> >> >> --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> >> >> >> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> >> >> >> @@ -53,9 +53,6 @@ CONFIG_RTE_LIBRTE_KNI=n
> >> >> >> CONFIG_RTE_EAL_IGB_UIO=n
> >> >> >>
> >> >> >> # fails to compile on ARM
> >> >> >> -CONFIG_RTE_LIBRTE_LPM=n
> >> >> >> -CONFIG_RTE_LIBRTE_TABLE=n
> >> >> >> -CONFIG_RTE_LIBRTE_PIPELINE=n
> >> >> >> CONFIG_RTE_SCHED_VECTOR=n
> >> >> >>
> >> >> >> # cannot use those on ARM
> >> >> >> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
> >> >> >> index 504f3ed..57f7941 100644
> >> >> >> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> >> >> >> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> >> >> >> @@ -51,7 +51,4 @@ CONFIG_RTE_LIBRTE_IVSHMEM=n
> >> >> >> CONFIG_RTE_LIBRTE_FM10K_PMD=n
> >> >> >> CONFIG_RTE_LIBRTE_I40E_PMD=n
> >> >> >>
> >> >> >> -CONFIG_RTE_LIBRTE_LPM=n
> >> >> >> -CONFIG_RTE_LIBRTE_TABLE=n
> >> >> >> -CONFIG_RTE_LIBRTE_PIPELINE=n
> >> >> >> CONFIG_RTE_SCHED_VECTOR=n
> >> >> >> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> >> >> >> index a33c054..7437711 100644
> >> >> >> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> >> >> >> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> >> >> >> @@ -41,6 +41,8 @@ extern "C" {
> >> >> >>
> >> >> >> typedef int32x4_t xmm_t;
> >> >> >>
> >> >> >> +typedef int32x4_t __m128i;
> >> >> >> +
> >> >> >> #define XMM_SIZE (sizeof(xmm_t))
> >> >> >> #define XMM_MASK (XMM_SIZE - 1)
> >> >> >>
> >> >> >> @@ -53,6 +55,32 @@ typedef union rte_xmm {
> >> >> >> double pd[XMM_SIZE / sizeof(double)];
> >> >> >> } __attribute__((aligned(16))) rte_xmm_t;
> >> >> >>
> >> >> >> +static __inline __m128i
> >> >> >> +_mm_set_epi32(int i3, int i2, int i1, int i0)
> >> >> >> +{
> >> >> >> + int32_t r[4] = {i0, i1, i2, i3};
> >> >> >> +
> >> >> >> + return vld1q_s32(r);
> >> >> >> +}
> >> >> >> +
> >> >> >> +static __inline __m128i
> >> >> >> +_mm_loadu_si128(__m128i *p)
> >> >> >> +{
> >> >> >> + return vld1q_s32((int32_t *)p);
> >> >> >> +}
> >> >> >> +
> >> >> >> +static __inline __m128i
> >> >> >> +_mm_set1_epi32(int i)
> >> >> >> +{
> >> >> >> + return vdupq_n_s32(i);
> >> >> >> +}
> >> >> >> +
> >> >> >> +static __inline __m128i
> >> >> >> +_mm_and_si128(__m128i a, __m128i b)
> >> >> >> +{
> >> >> >> + return vandq_s32(a, b);
> >> >> >> +}
> >> >> >> +
> >> >
> >> > IMO, it's not always good to emulate GCC defined intrinsics of
> >> > other architecture. What if a legacy DPDK application has such mappings
> >> > then BOOM, multiple definition, which one is correct? which one
> >> > to comment it out? Integration pain starts for DPDK library consumer:-(
> >> >
> >> They can include rte_vect.h in build/include directly, which is linked correctly
> >> to the one for that ARCH, so there is no need to worry about.
> >
> > I think you missed the point,I was trying to say that
> > legacy DPDK application and third party stacks uses SSE2NEON kind of
> > libraries
> > for quick integration, for example, something like this
> > https://github.com/jratcliff63367/sse2neon/blob/master/SSE2NEON.h
> >
> > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > that lead to multiple definition and its not good.
> >
> But you will have similar issue since "typedef int32x4_t __m128i"
> appears in both your patch and this header file.
I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
is fine(unlike inline function).
my intention to keep __m128i "as is" because changing the __m128i to rte_???
something would break the ABI.
>
> >>
> >>
> >> >> >
> >> >> > IMO, it makes sense to not emulate the SSE intrinsics with NEON
> >> >> > Let's create the rte_vect_* as required. look at the existing patch.
> >> >> >
> >> >> I thought of creating a layer of SIMD over all the platforms before.
> >> >> But can't you see it make things complicated, considering there are
> >> >> only few simple intrinsic to implement?
> >> >
> >> > Not true, There were, a lot of SSE intrinsics needs be to emulated for ACL NEON
> >> > implementation if I were to take this approach and emulation comes with
> >> > the cost.
> >> >
> >> No, I will not re-implement all the intrinsic like that .
> >> I only do with the simple intrinsic, such as load/store, as you said below.
> >
> > but you forced to add _mm_and_si128 also to the list and emulated
> > _mm_and_si128 intrinsic. Am just saying no emulation.
> >
> I means simple intrinsic, not load/store only.
> Depends on how you define emulation. Actually, these simple intrisinic
> could be only one NEON instruction, and will not bring cost.
>
> >
> >>
> >> > So my take is,
> >> > lets the each architecture implementation for specific SIMD version of DPDK
> >> > API in the library should have the freedom to implement the API in
> >> > NATIVE.
> >> >
> >> > And let's create only rte_vect_* abstraction only for using
> >> > that API/library. Which boils down to have very minimal rte_vect_*
> >> > abstraction to load, store, set not beyond that.
> >> >
> >> > This makes clear "contract" between DPDK library and the applications.
> >> > and make easy for remaning new architecture porting effort in DPDK.
> >> >
> >> Agree.
> >> But I reuse existing intrinsic names, and you recreate new ones.
> >> And I try to do as few changes as possible, and try to avoid any
> >> mistaken which may cause code un-compiled.
> >
> > Its trival to verify. Just compile it
> >
> >> I think it's design level question, we need to hear what others talk about it.
> >>
> >> > Imagine how your proposed function will look like if new architecture
> >> > wants to implement "optimized" version of rte_lpm_lookupx4
> >> >
> >> There is no optimization for this (simple) rte_lpm_lookupx4, otherwise
> >> you have done that in your patch.
> >> If there is for other new platform, defintely they should do like
> >> yours, as you did for NEON ACL.
> >>
> >> >
> >> >> If do so, we also need to explain to others how to use these interfaces.
> >> >> Besides, this patch did the smallest changes to the original code, and
> >> >> more likely to be accepted by others.
> >> >
> >> > other patch makes no changes to IA version of rte_lpm_lookupx4.I thought
> >> > that make reviewer easy to review the changes in architecture
> >> > perspective.
> >> >
> >> As I know, they don't enable LPM for PPC, and ARM is the first one to
> >> touch this issue.
> >>
> >> >>
> >> >> >
> >> >> >> #ifdef RTE_ARCH_ARM
> >> >> >> /* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */
> >> >> >> static __inline uint8x16_t
> >> >> >> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
> >> >> >> index c299ce2..c76c07d 100644
> >> >> >> --- a/lib/librte_lpm/rte_lpm.h
> >> >> >> +++ b/lib/librte_lpm/rte_lpm.h
> >> >> >> @@ -361,6 +361,47 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
> >> >> >> /* Mask four results. */
> >> >> >> #define RTE_LPM_MASKX4_RES UINT64_C(0x00ff00ff00ff00ff)
> >> >> >>
> >> >> >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> >> >> >
> >> >> > Separate out arm implementation to the different header file.
> >> >> > Too many ifdef looks odd in the header file and difficult to manage.
> >> >> >
> >> >> But there are many ifdefs already.
> >> >> And It seems unreasonable to add a new file only for one small function.
> >> >>
> >> >
> >> > small or big, its matter of each architecture to have
> >> > the freedom for the optimized version for the implementation.
> >> >
> >> > What if other architecture demands to write this function in assembly
> >> > or restructure it for performance improvement?
> >> >
> >> If there is such demands, should do like that.
> >> But I don't see any restructure in your patch, and you still follow
> >> the logic as x86, is it worth adding a new file?
> >
> > SIMD Logic on getting 4 indexes for tbl24[] is different.
> >
> > /* get 4 indexes for tbl24[]. */
> > i24 = _mm_srli_epi32(ip, CHAR_BIT);
> >
> > /* extract values from tbl24[] */
> > idx = _mm_cvtsi128_si64(i24);
> > i24 = _mm_srli_si128(i24, sizeof(uint64_t));
> >
> > tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> > tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >
> > idx = _mm_cvtsi128_si64(i24);
> >
> > tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> > tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >
> > VS
> >
> > /* extract values from tbl24[] */
> > idx = vgetq_lane_u64((uint64x2_t)i24, 0);
> >
> > tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> > tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >
> > idx = vgetq_lane_u64((uint64x2_t)i24, 1);
> >
> > tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> > tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >
> It's only the optimazation of part of code in that function. I did the
> similar in my patch.
> But, looking from the whole, this function is not restructured, and
> the logic is the same as x86.
>
> >>
> >> >
> >> >> >
> >> >> >> +static inline void
> >> >> >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t tbl[4])
> >> >> >> +{
> >> >> >> + uint32x4_t i24;
> >> >> >> + uint32_t idx[4];
> >> >> >> +
> >> >> >> + /* get 4 indexes for tbl24[]. */
> >> >> >> + i24 = vshrq_n_u32(vreinterpretq_u32_s32(ip), CHAR_BIT);
> >> >> >> + vst1q_u32(idx, i24);
> >> >> >> +
> >> >> >> + /* extract values from tbl24[] */
> >> >> >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[idx[0]];
> >> >> >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx[1]];
> >> >> >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[idx[2]];
> >> >> >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx[3]];
> >> >> >> +}
> >> >> >
> >> >> > Nice. There is an improvement in this portion code wrt my patch. This is
> >> >> > a candidate for convergence.
> >> >> >
> >> >> >
> >> >> >> +#else
> >> >> >> +static inline void
> >> >> >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, __m128i ip, uint16_t tbl[4])
> >> >> >> +{
> >> >> >> + __m128i i24;
> >> >> >> + uint64_t idx;
> >> >> >> +
> >> >> >> + /* get 4 indexes for tbl24[]. */
> >> >> >> + i24 = _mm_srli_epi32(ip, CHAR_BIT);
> >> >> >> +
> >> >> >> + /* extract values from tbl24[] */
> >> >> >> + idx = _mm_cvtsi128_si64(i24);
> >> >> >> + i24 = _mm_srli_si128(i24, sizeof(uint64_t));
> >> >> >> +
> >> >> >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> >> >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> >> >> +
> >> >> >> + idx = _mm_cvtsi128_si64(i24);
> >> >> >> +
> >> >> >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> >> >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> >> >> +}
> >> >> >> +#endif
> >> >> >> +
> >> >> >> /**
> >> >> >> * Lookup four IP addresses in an LPM table.
> >> >> >> *
> >> >> >> @@ -381,17 +422,19 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
> >> >> >> * if lookup would fail.
> >> >> >> */
> >> >> >> static inline void
> >> >> >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> >> >> >> +rte_lpm_lookupx4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t hop[4],
> >> >> >> + uint16_t defv)
> >> >> >
> >> >> > This would call for change in the change the ABI,
> >> >> > IMO, __m128i can be used to represent 128bit vector to avoid ABI chang
> >> >> >
> >> >> This redefine rte_lpm_lookupx4 is unncessary, I will remove it, so no
> >> >> ABI change.
> >> >> And there only one ifdef for ARM platforms left.
> >> >>
> >> >> >
> >> >> >> +#else
> >> >> > separate out arm implementation to the different header file. Too many
> >> >> > ifdef looks odd in the header file.
> >> >> >
> >> >> > Could you rebase your patch based on existing patch and send the
> >> >> > improvement portion as separate patch or I can send update patch with
> >> >> > your improvements and with your signoff.
> >> >> >
> >> >> >
> >> >> >> rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
> >> >> >> uint16_t defv)
> >> >> >> +#endif
> >> >> >> {
> >> >> >> - __m128i i24;
> >> >> >> rte_xmm_t i8;
> >> >> >> uint16_t tbl[4];
> >> >> >> - uint64_t idx, pt;
> >> >> >> -
> >> >> >> - const __m128i mask8 =
> >> >> >> - _mm_set_epi32(UINT8_MAX, UINT8_MAX, UINT8_MAX, UINT8_MAX);
> >> >> >> + uint64_t pt;
> >> >> >>
> >> >> >> + const __m128i mask8 = _mm_set1_epi32(UINT8_MAX);
> >> >> >> /*
> >> >> >> * RTE_LPM_VALID_EXT_ENTRY_BITMASK for 4 LPM entries
> >> >> >> * as one 64-bit value (0x0300030003000300).
> >> >> >> @@ -412,20 +455,7 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
> >> >> >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 32 |
> >> >> >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 48);
> >> >> >>
> >> >> >> - /* get 4 indexes for tbl24[]. */
> >> >> >> - i24 = _mm_srli_epi32(ip, CHAR_BIT);
> >> >> >> -
> >> >> >> - /* extract values from tbl24[] */
> >> >> >> - idx = _mm_cvtsi128_si64(i24);
> >> >> >> - i24 = _mm_srli_si128(i24, sizeof(uint64_t));
> >> >> >> -
> >> >> >> - tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> >> >> - tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> >> >> -
> >> >> >> - idx = _mm_cvtsi128_si64(i24);
> >> >> >> -
> >> >> >> - tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> >> >> - tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> >> >> + rte_lpm_tbl24_val4(lpm, ip, tbl);
> >> >> >>
> >> >> >> /* get 4 indexes for tbl8[]. */
> >> >> >> i8.x = _mm_and_si128(ip, mask8);
> >> >> >> --
> >> >> >> 1.8.3.1
> >> >> >>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-02 13:53 4% ` Panu Matilainen
@ 2015-12-02 14:31 5% ` Yuanhan Liu
2015-12-02 14:48 4% ` Panu Matilainen
2015-12-02 16:38 4% ` Thomas Monjalon
2015-12-06 23:07 3% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Yuanhan Liu @ 2015-12-02 14:31 UTC (permalink / raw)
To: Panu Matilainen, Thomas Monjalon
Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On Wed, Dec 02, 2015 at 03:53:45PM +0200, Panu Matilainen wrote:
> On 12/02/2015 05:43 AM, Yuanhan Liu wrote:
> >VHOST_USER_SET_LOG_BASE request is used to tell the backend (dpdk
> >vhost-user) where we should log dirty pages, and how big the log
> >buffer is.
> >
> >This request introduces a new payload:
> >
> > typedef struct VhostUserLog {
> > uint64_t mmap_size;
> > uint64_t mmap_offset;
> > } VhostUserLog;
> >
> >Also, a fd is delivered from QEMU by ancillary data.
> >
> >With those info given, an area of memory is mmaped, assigned
> >to dev->log_base, for logging dirty pages.
> >
> >Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> >---
> > lib/librte_vhost/rte_virtio_net.h | 2 ++
> > lib/librte_vhost/vhost_user/vhost-net-user.c | 7 ++++-
> > lib/librte_vhost/vhost_user/vhost-net-user.h | 6 ++++
> > lib/librte_vhost/vhost_user/virtio-net-user.c | 44 +++++++++++++++++++++++++++
> > lib/librte_vhost/vhost_user/virtio-net-user.h | 1 +
> > 5 files changed, 59 insertions(+), 1 deletion(-)
> >
> >diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
> >index 5687452..416dac2 100644
> >--- a/lib/librte_vhost/rte_virtio_net.h
> >+++ b/lib/librte_vhost/rte_virtio_net.h
> >@@ -127,6 +127,8 @@ struct virtio_net {
> > #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 */
> >+ uint64_t log_size; /**< Size of log area */
> >+ uint8_t *log_base; /**< Where dirty pages are logged */
> > void *priv; /**< private context */
> > struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
> > } __rte_cache_aligned;
>
> 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.
I was thinking that adding a new field (instead of renaming it or
removing it) isn't an ABI break. So, I was wrong?
>
> 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.
It will not be compatible, unless we add exact same fields (not
something like uint8_t pad[xx]). Otherwise, the pad field renaming
is also an ABI break, right?
Thomas, should I write an ABI deprecation note? Can I make it for
v2.2 release If I make one tomorrow? (Sorry that I'm not awared
of that it would be an ABI break).
--yliu
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
@ 2015-12-02 13:53 4% ` Panu Matilainen
2015-12-02 14:31 5% ` Yuanhan Liu
2015-12-06 23:07 3% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Panu Matilainen @ 2015-12-02 13:53 UTC (permalink / raw)
To: Yuanhan Liu, dev; +Cc: Victor Kaplansky, Michael S. Tsirkin
On 12/02/2015 05:43 AM, Yuanhan Liu wrote:
> VHOST_USER_SET_LOG_BASE request is used to tell the backend (dpdk
> vhost-user) where we should log dirty pages, and how big the log
> buffer is.
>
> This request introduces a new payload:
>
> typedef struct VhostUserLog {
> uint64_t mmap_size;
> uint64_t mmap_offset;
> } VhostUserLog;
>
> Also, a fd is delivered from QEMU by ancillary data.
>
> With those info given, an area of memory is mmaped, assigned
> to dev->log_base, for logging dirty pages.
>
> Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> ---
> lib/librte_vhost/rte_virtio_net.h | 2 ++
> lib/librte_vhost/vhost_user/vhost-net-user.c | 7 ++++-
> lib/librte_vhost/vhost_user/vhost-net-user.h | 6 ++++
> lib/librte_vhost/vhost_user/virtio-net-user.c | 44 +++++++++++++++++++++++++++
> lib/librte_vhost/vhost_user/virtio-net-user.h | 1 +
> 5 files changed, 59 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
> index 5687452..416dac2 100644
> --- a/lib/librte_vhost/rte_virtio_net.h
> +++ b/lib/librte_vhost/rte_virtio_net.h
> @@ -127,6 +127,8 @@ struct virtio_net {
> #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 */
> + uint64_t log_size; /**< Size of log area */
> + uint8_t *log_base; /**< Where dirty pages are logged */
> void *priv; /**< private context */
> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
> } __rte_cache_aligned;
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.
- Panu -
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/3] eal: introduce rte_vect_* abstractions
@ 2015-12-02 13:43 3% ` Jan Viktorin
2015-12-02 14:51 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Jan Viktorin @ 2015-12-02 13:43 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev
On Mon, 30 Nov 2015 22:54:11 +0530
Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> introduce rte_vect_* abstractions to remove SSE/AVX specific
> code in the common code(i.e the test applications)
>
> The patch does not provide any functional change for IA, the goal is to
Does IA mean Intel Architecture?
> have infrastructure to reuse the common vector-based test code across
> all the architectures.
>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> lib/librte_eal/common/include/arch/arm/rte_vect.h | 17 ++++++++++++++++-
> lib/librte_eal/common/include/arch/x86/rte_vect.h | 8 ++++++++
> 2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> index 21cdb4d..d300951 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> @@ -33,13 +33,14 @@
> #ifndef _RTE_VECT_ARM_H_
> #define _RTE_VECT_ARM_H_
>
> -#include "arm_neon.h"
> +#include <arm_neon.h>
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> typedef int32x4_t xmm_t;
> +typedef int32x4_t __m128i;
As Jianbo pointed out recently, the __m128i type should be refactored in
a general rte_vect API too. If we do something like
#if SSE
typedef __m128i rte_128i;
#elif NEON
typedef int32x4_y rte_128i;
#endif
does it make somebody angry? I am afraid that it will influence a lot of
code. However, from the ABI point of view, it is OK, isn't it?
>
> #define XMM_SIZE (sizeof(xmm_t))
> #define XMM_MASK (XMM_SIZE - 1)
> @@ -53,6 +54,20 @@ typedef union rte_xmm {
> double pd[XMM_SIZE / sizeof(double)];
> } __attribute__((aligned(16))) rte_xmm_t;
>
> +/* rte_vect_* abstraction implementation using NEON */
> +
> +/* loads the __m128i value from address p(does not need to be 16-byte aligned)*/
> +#define rte_vect_loadu_sil128(p) vld1q_s32((const int32_t *)p)
> +
> +/* sets the 4 signed 32-bit integer values and returns the __m128i variable */
> +static inline __m128i __attribute__((always_inline))
> +rte_vect_set_epi32(int i3, int i2, int i1, int i0)
> +{
> + int32_t data[4] = {i0, i1, i2, i3};
> +
> + return vld1q_s32(data);
> +}
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/librte_eal/common/include/arch/x86/rte_vect.h b/lib/librte_eal/common/include/arch/x86/rte_vect.h
> index b698797..91c6523 100644
> --- a/lib/librte_eal/common/include/arch/x86/rte_vect.h
> +++ b/lib/librte_eal/common/include/arch/x86/rte_vect.h
> @@ -125,6 +125,14 @@ typedef union rte_ymm {
> })
> #endif /* (defined(__ICC) && __ICC < 1210) */
>
> +/* rte_vect_* abstraction implementation using SSE */
> +
> +/* loads the __m128i value from address p(does not need to be 16-byte aligned)*/
> +#define rte_vect_loadu_sil128(p) _mm_loadu_si128(p)
> +
> +/* sets the 4 signed 32-bit integer values and returns the __m128i variable */
> +#define rte_vect_set_epi32(i3, i2, i1, i0) _mm_set_epi32(i3, i2, i1, i0)
> +
> #ifdef __cplusplus
> }
> #endif
I like this approach. It is a question whether to inherit names from
SSE. However, why to reinvent the wheel...
We probably need other people to give their ideas about such
generalization of the API.
I think, there should be an autotest of the rte_vect API. Is it
possible to create one?
Regards
Jan
--
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] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
@ 2015-12-02 13:13 0% ` Jianbo Liu
2015-12-02 14:34 3% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Jianbo Liu @ 2015-12-02 13:13 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev
On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> On Wed, Dec 02, 2015 at 05:49:41PM +0800, Jianbo Liu wrote:
>> On 2 December 2015 at 16:03, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
>> > On Wed, Dec 02, 2015 at 02:54:52PM +0800, Jianbo Liu wrote:
>> >> On 2 December 2015 at 00:41, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
>> >> > On Tue, Dec 01, 2015 at 01:41:15PM -0500, Jianbo Liu wrote:
>> >> >> Adds ARM NEON support for lpm.
>> >> >> And enables table/pipeline libraries which depend on lpm.
>> >> >
>> >> > I already sent the patch on the same yesterday.
>> >> > We can converge the patches after the discussion.
>> >> > Please check "[dpdk-dev] [PATCH 0/3] add lpm support for NEON" on ml
>> >> >
>> >> Yes, I have read your patch. But there are many differences, so I sent
>> >> mine for your reviewing :)
>> >>
>> >> >
>> >> >>
>> >> >> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
>> >> >> ---
>> >> >> config/defconfig_arm-armv7a-linuxapp-gcc | 3 -
>> >> >> config/defconfig_arm64-armv8a-linuxapp-gcc | 3 -
>> >> >> lib/librte_eal/common/include/arch/arm/rte_vect.h | 28 ++++++++++
>> >> >> lib/librte_lpm/rte_lpm.h | 68 ++++++++++++++++-------
>> >> >> 4 files changed, 77 insertions(+), 25 deletions(-)
>> >> >>
>> >> >> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc
>> >> >> index cbebd64..efffa1f 100644
>> >> >> --- a/config/defconfig_arm-armv7a-linuxapp-gcc
>> >> >> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
>> >> >> @@ -53,9 +53,6 @@ CONFIG_RTE_LIBRTE_KNI=n
>> >> >> CONFIG_RTE_EAL_IGB_UIO=n
>> >> >>
>> >> >> # fails to compile on ARM
>> >> >> -CONFIG_RTE_LIBRTE_LPM=n
>> >> >> -CONFIG_RTE_LIBRTE_TABLE=n
>> >> >> -CONFIG_RTE_LIBRTE_PIPELINE=n
>> >> >> CONFIG_RTE_SCHED_VECTOR=n
>> >> >>
>> >> >> # cannot use those on ARM
>> >> >> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
>> >> >> index 504f3ed..57f7941 100644
>> >> >> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
>> >> >> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
>> >> >> @@ -51,7 +51,4 @@ CONFIG_RTE_LIBRTE_IVSHMEM=n
>> >> >> CONFIG_RTE_LIBRTE_FM10K_PMD=n
>> >> >> CONFIG_RTE_LIBRTE_I40E_PMD=n
>> >> >>
>> >> >> -CONFIG_RTE_LIBRTE_LPM=n
>> >> >> -CONFIG_RTE_LIBRTE_TABLE=n
>> >> >> -CONFIG_RTE_LIBRTE_PIPELINE=n
>> >> >> CONFIG_RTE_SCHED_VECTOR=n
>> >> >> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h
>> >> >> index a33c054..7437711 100644
>> >> >> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
>> >> >> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
>> >> >> @@ -41,6 +41,8 @@ extern "C" {
>> >> >>
>> >> >> typedef int32x4_t xmm_t;
>> >> >>
>> >> >> +typedef int32x4_t __m128i;
>> >> >> +
>> >> >> #define XMM_SIZE (sizeof(xmm_t))
>> >> >> #define XMM_MASK (XMM_SIZE - 1)
>> >> >>
>> >> >> @@ -53,6 +55,32 @@ typedef union rte_xmm {
>> >> >> double pd[XMM_SIZE / sizeof(double)];
>> >> >> } __attribute__((aligned(16))) rte_xmm_t;
>> >> >>
>> >> >> +static __inline __m128i
>> >> >> +_mm_set_epi32(int i3, int i2, int i1, int i0)
>> >> >> +{
>> >> >> + int32_t r[4] = {i0, i1, i2, i3};
>> >> >> +
>> >> >> + return vld1q_s32(r);
>> >> >> +}
>> >> >> +
>> >> >> +static __inline __m128i
>> >> >> +_mm_loadu_si128(__m128i *p)
>> >> >> +{
>> >> >> + return vld1q_s32((int32_t *)p);
>> >> >> +}
>> >> >> +
>> >> >> +static __inline __m128i
>> >> >> +_mm_set1_epi32(int i)
>> >> >> +{
>> >> >> + return vdupq_n_s32(i);
>> >> >> +}
>> >> >> +
>> >> >> +static __inline __m128i
>> >> >> +_mm_and_si128(__m128i a, __m128i b)
>> >> >> +{
>> >> >> + return vandq_s32(a, b);
>> >> >> +}
>> >> >> +
>> >
>> > IMO, it's not always good to emulate GCC defined intrinsics of
>> > other architecture. What if a legacy DPDK application has such mappings
>> > then BOOM, multiple definition, which one is correct? which one
>> > to comment it out? Integration pain starts for DPDK library consumer:-(
>> >
>> They can include rte_vect.h in build/include directly, which is linked correctly
>> to the one for that ARCH, so there is no need to worry about.
>
> I think you missed the point,I was trying to say that
> legacy DPDK application and third party stacks uses SSE2NEON kind of
> libraries
> for quick integration, for example, something like this
> https://github.com/jratcliff63367/sse2neon/blob/master/SSE2NEON.h
>
> AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> that lead to multiple definition and its not good.
>
But you will have similar issue since "typedef int32x4_t __m128i"
appears in both your patch and this header file.
>>
>>
>> >> >
>> >> > IMO, it makes sense to not emulate the SSE intrinsics with NEON
>> >> > Let's create the rte_vect_* as required. look at the existing patch.
>> >> >
>> >> I thought of creating a layer of SIMD over all the platforms before.
>> >> But can't you see it make things complicated, considering there are
>> >> only few simple intrinsic to implement?
>> >
>> > Not true, There were, a lot of SSE intrinsics needs be to emulated for ACL NEON
>> > implementation if I were to take this approach and emulation comes with
>> > the cost.
>> >
>> No, I will not re-implement all the intrinsic like that .
>> I only do with the simple intrinsic, such as load/store, as you said below.
>
> but you forced to add _mm_and_si128 also to the list and emulated
> _mm_and_si128 intrinsic. Am just saying no emulation.
>
I means simple intrinsic, not load/store only.
Depends on how you define emulation. Actually, these simple intrisinic
could be only one NEON instruction, and will not bring cost.
>
>>
>> > So my take is,
>> > lets the each architecture implementation for specific SIMD version of DPDK
>> > API in the library should have the freedom to implement the API in
>> > NATIVE.
>> >
>> > And let's create only rte_vect_* abstraction only for using
>> > that API/library. Which boils down to have very minimal rte_vect_*
>> > abstraction to load, store, set not beyond that.
>> >
>> > This makes clear "contract" between DPDK library and the applications.
>> > and make easy for remaning new architecture porting effort in DPDK.
>> >
>> Agree.
>> But I reuse existing intrinsic names, and you recreate new ones.
>> And I try to do as few changes as possible, and try to avoid any
>> mistaken which may cause code un-compiled.
>
> Its trival to verify. Just compile it
>
>> I think it's design level question, we need to hear what others talk about it.
>>
>> > Imagine how your proposed function will look like if new architecture
>> > wants to implement "optimized" version of rte_lpm_lookupx4
>> >
>> There is no optimization for this (simple) rte_lpm_lookupx4, otherwise
>> you have done that in your patch.
>> If there is for other new platform, defintely they should do like
>> yours, as you did for NEON ACL.
>>
>> >
>> >> If do so, we also need to explain to others how to use these interfaces.
>> >> Besides, this patch did the smallest changes to the original code, and
>> >> more likely to be accepted by others.
>> >
>> > other patch makes no changes to IA version of rte_lpm_lookupx4.I thought
>> > that make reviewer easy to review the changes in architecture
>> > perspective.
>> >
>> As I know, they don't enable LPM for PPC, and ARM is the first one to
>> touch this issue.
>>
>> >>
>> >> >
>> >> >> #ifdef RTE_ARCH_ARM
>> >> >> /* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */
>> >> >> static __inline uint8x16_t
>> >> >> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
>> >> >> index c299ce2..c76c07d 100644
>> >> >> --- a/lib/librte_lpm/rte_lpm.h
>> >> >> +++ b/lib/librte_lpm/rte_lpm.h
>> >> >> @@ -361,6 +361,47 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
>> >> >> /* Mask four results. */
>> >> >> #define RTE_LPM_MASKX4_RES UINT64_C(0x00ff00ff00ff00ff)
>> >> >>
>> >> >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
>> >> >
>> >> > Separate out arm implementation to the different header file.
>> >> > Too many ifdef looks odd in the header file and difficult to manage.
>> >> >
>> >> But there are many ifdefs already.
>> >> And It seems unreasonable to add a new file only for one small function.
>> >>
>> >
>> > small or big, its matter of each architecture to have
>> > the freedom for the optimized version for the implementation.
>> >
>> > What if other architecture demands to write this function in assembly
>> > or restructure it for performance improvement?
>> >
>> If there is such demands, should do like that.
>> But I don't see any restructure in your patch, and you still follow
>> the logic as x86, is it worth adding a new file?
>
> SIMD Logic on getting 4 indexes for tbl24[] is different.
>
> /* get 4 indexes for tbl24[]. */
> i24 = _mm_srli_epi32(ip, CHAR_BIT);
>
> /* extract values from tbl24[] */
> idx = _mm_cvtsi128_si64(i24);
> i24 = _mm_srli_si128(i24, sizeof(uint64_t));
>
> tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>
> idx = _mm_cvtsi128_si64(i24);
>
> tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>
> VS
>
> /* extract values from tbl24[] */
> idx = vgetq_lane_u64((uint64x2_t)i24, 0);
>
> tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>
> idx = vgetq_lane_u64((uint64x2_t)i24, 1);
>
> tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>
It's only the optimazation of part of code in that function. I did the
similar in my patch.
But, looking from the whole, this function is not restructured, and
the logic is the same as x86.
>>
>> >
>> >> >
>> >> >> +static inline void
>> >> >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t tbl[4])
>> >> >> +{
>> >> >> + uint32x4_t i24;
>> >> >> + uint32_t idx[4];
>> >> >> +
>> >> >> + /* get 4 indexes for tbl24[]. */
>> >> >> + i24 = vshrq_n_u32(vreinterpretq_u32_s32(ip), CHAR_BIT);
>> >> >> + vst1q_u32(idx, i24);
>> >> >> +
>> >> >> + /* extract values from tbl24[] */
>> >> >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[idx[0]];
>> >> >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx[1]];
>> >> >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[idx[2]];
>> >> >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx[3]];
>> >> >> +}
>> >> >
>> >> > Nice. There is an improvement in this portion code wrt my patch. This is
>> >> > a candidate for convergence.
>> >> >
>> >> >
>> >> >> +#else
>> >> >> +static inline void
>> >> >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, __m128i ip, uint16_t tbl[4])
>> >> >> +{
>> >> >> + __m128i i24;
>> >> >> + uint64_t idx;
>> >> >> +
>> >> >> + /* get 4 indexes for tbl24[]. */
>> >> >> + i24 = _mm_srli_epi32(ip, CHAR_BIT);
>> >> >> +
>> >> >> + /* extract values from tbl24[] */
>> >> >> + idx = _mm_cvtsi128_si64(i24);
>> >> >> + i24 = _mm_srli_si128(i24, sizeof(uint64_t));
>> >> >> +
>> >> >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> >> >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> >> >> +
>> >> >> + idx = _mm_cvtsi128_si64(i24);
>> >> >> +
>> >> >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> >> >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> >> >> +}
>> >> >> +#endif
>> >> >> +
>> >> >> /**
>> >> >> * Lookup four IP addresses in an LPM table.
>> >> >> *
>> >> >> @@ -381,17 +422,19 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
>> >> >> * if lookup would fail.
>> >> >> */
>> >> >> static inline void
>> >> >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
>> >> >> +rte_lpm_lookupx4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t hop[4],
>> >> >> + uint16_t defv)
>> >> >
>> >> > This would call for change in the change the ABI,
>> >> > IMO, __m128i can be used to represent 128bit vector to avoid ABI chang
>> >> >
>> >> This redefine rte_lpm_lookupx4 is unncessary, I will remove it, so no
>> >> ABI change.
>> >> And there only one ifdef for ARM platforms left.
>> >>
>> >> >
>> >> >> +#else
>> >> > separate out arm implementation to the different header file. Too many
>> >> > ifdef looks odd in the header file.
>> >> >
>> >> > Could you rebase your patch based on existing patch and send the
>> >> > improvement portion as separate patch or I can send update patch with
>> >> > your improvements and with your signoff.
>> >> >
>> >> >
>> >> >> rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
>> >> >> uint16_t defv)
>> >> >> +#endif
>> >> >> {
>> >> >> - __m128i i24;
>> >> >> rte_xmm_t i8;
>> >> >> uint16_t tbl[4];
>> >> >> - uint64_t idx, pt;
>> >> >> -
>> >> >> - const __m128i mask8 =
>> >> >> - _mm_set_epi32(UINT8_MAX, UINT8_MAX, UINT8_MAX, UINT8_MAX);
>> >> >> + uint64_t pt;
>> >> >>
>> >> >> + const __m128i mask8 = _mm_set1_epi32(UINT8_MAX);
>> >> >> /*
>> >> >> * RTE_LPM_VALID_EXT_ENTRY_BITMASK for 4 LPM entries
>> >> >> * as one 64-bit value (0x0300030003000300).
>> >> >> @@ -412,20 +455,7 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
>> >> >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 32 |
>> >> >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 48);
>> >> >>
>> >> >> - /* get 4 indexes for tbl24[]. */
>> >> >> - i24 = _mm_srli_epi32(ip, CHAR_BIT);
>> >> >> -
>> >> >> - /* extract values from tbl24[] */
>> >> >> - idx = _mm_cvtsi128_si64(i24);
>> >> >> - i24 = _mm_srli_si128(i24, sizeof(uint64_t));
>> >> >> -
>> >> >> - tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> >> >> - tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> >> >> -
>> >> >> - idx = _mm_cvtsi128_si64(i24);
>> >> >> -
>> >> >> - tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> >> >> - tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> >> >> + rte_lpm_tbl24_val4(lpm, ip, tbl);
>> >> >>
>> >> >> /* get 4 indexes for tbl8[]. */
>> >> >> i8.x = _mm_and_si128(ip, mask8);
>> >> >> --
>> >> >> 1.8.3.1
>> >> >>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
@ 2015-12-02 11:44 3% ` Neil Horman
2015-12-03 1:31 0% ` Ferruh Yigit
0 siblings, 2 replies; 200+ results
From: Neil Horman @ 2015-12-02 11:44 UTC (permalink / raw)
To: Robie Basak; +Cc: dev
On Tue, Dec 01, 2015 at 12:37:37PM +0000, Robie Basak wrote:
> Re-sending this unsigned since the ML rejected my signed email.
>
> -1 from Ubuntu without further discussion since it will break us. Please
> don't commit this patch yet.
>
> I don't understand why we must have the complexity of so many shared
> libraries. From a distribution packaging perspective, all I see is that
> this multiplies potential work by twenty times and makes it awkward to
> work with without special tooling (which then needs maintaining).
>
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.
> understand why DPDK must be different to every other userspace library
> out there. If DPDK has a good need to be different then that's fair
> enough. But I feel that if DPDK is deviating from the norm then we need
> to frame the discussion from the perspective of "why DPDK must be
> different", rather than having me trying to explain why the norm is the
> right way to do it.
>
> On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
> > That's how Fedora and RHEL are shipping it already and nobody has so much
> > as noticed anything strange, much less complained about it. 20 libraries
> > is but a drop in the ocean on a average distro.
>
> No, it is 20 times the work from the perspective of DPDK package
> maintenance. Let me explain why.
>
> 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. 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.
> This works because of conventions around sonames, which DPDK breaks
> unless we treat it as twenty different libraries which changes our work
> from easy to painful.
>
> Usually a library transition is managed by hand by the package
> maintainer. It's not taxing because it's straightforward and well
> understood. Update and upload the new ABI source package, then find all
> reverse dependencies and sort them out, recursively. But if the
> maintainer must do it twenty times, then it becomes taxing and prone to
> error. And if the reverse dependency tree differs depending on the split
> library used by library consumers, then it gets far more complex to
> follow.
>
> Admittedly we could tool around this to make it easier, but that's extra
> work (both initially and in maintenance) and prone to error (because
> we'd only be doing it for DPDK).
>
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)
> 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.
> 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.
> 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.
Neil
^ permalink raw reply [relevance 3%]
Results 12601-12800 of ~19000 next (older) | prev (newer) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2015-09-24 7:34 [dpdk-dev] [PATCH 0/3] Minor abi-validator improvements Panu Matilainen
2015-09-24 7:50 ` [dpdk-dev] [PATCH 0/3 v2] " Panu Matilainen
2015-09-24 10:23 ` Neil Horman
2015-12-03 19:38 4% ` Thomas Monjalon
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-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-11-20 16:28 ` Olivier MATZ
2015-12-03 16:32 4% ` 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-11-24 14:31 [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script Panu Matilainen
2015-12-01 12:37 ` Robie Basak
2015-12-02 11:44 3% ` 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-03 1:31 0% ` Ferruh Yigit
2015-12-03 8:11 3% ` Christian Ehrhardt
2015-12-03 14:59 0% ` Neil Horman
2015-11-29 18:46 [dpdk-dev] [PATCH 0/3] sched: patches for 2.2 Stephen Hemminger
2015-11-29 18:46 ` [dpdk-dev] [PATCH 3/3] rte_sched: eliminate floating point in calculating byte clock Stephen Hemminger
2015-12-02 16:48 0% ` Dumitrescu, Cristian
2015-12-02 22:08 0% ` Stephen Hemminger
2015-11-30 17:24 [dpdk-dev] [PATCH 0/3] add lpm support for NEON Jerin Jacob
2015-11-30 17:24 ` [dpdk-dev] [PATCH 1/3] eal: introduce rte_vect_* abstractions Jerin Jacob
2015-12-02 13:43 3% ` Jan Viktorin
2015-12-02 14:51 0% ` Jerin Jacob
2015-12-01 18:41 [dpdk-dev] [PATCH 0/4] support acl/lpm/table/pipeline libs for armv7 and armv8 Jianbo Liu
2015-12-01 18:41 ` [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs Jianbo Liu
2015-12-01 16:41 ` Jerin Jacob
[not found] ` <CAP4Qi3-5ofDU-2-4KsxFzMC1OpTsc5WjmxcFT2Eu_URA0UBzDw@mail.gmail.com>
2015-12-02 8:03 ` Jerin Jacob
2015-12-02 9:49 ` Jianbo Liu
2015-12-02 10:39 ` Jerin Jacob
2015-12-02 13:13 0% ` Jianbo Liu
2015-12-02 14:34 3% ` Jerin Jacob
2015-12-02 16:40 0% ` Thomas Monjalon
2015-12-02 16:53 0% ` Jerin Jacob
2015-12-02 16:57 3% ` Thomas Monjalon
2015-12-02 17:38 0% ` Jerin Jacob
2015-12-03 9:33 0% ` Jerin Jacob
2015-12-03 11:02 3% ` Ananyev, Konstantin
2015-12-03 12:17 3% ` Jerin Jacob
2015-12-03 12:42 0% ` Ananyev, Konstantin
2015-12-03 13:20 0% ` Jerin Jacob
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 4% ` Panu Matilainen
2015-12-02 14:31 5% ` Yuanhan Liu
2015-12-02 14:48 4% ` Panu Matilainen
2015-12-02 15:09 0% ` Yuanhan Liu
2015-12-02 16:58 0% ` Panu Matilainen
2015-12-02 17:24 3% ` Michael S. Tsirkin
2015-12-02 16:38 4% ` Thomas Monjalon
2015-12-03 1:49 0% ` Yuanhan Liu
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 36% [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range Panu Matilainen
2015-12-02 18:23 4% ` Neil Horman
2015-12-03 12:14 29% ` Mcnamara, John
2015-12-03 13:28 4% ` Thomas Monjalon
2015-12-03 13:44 4% ` Panu Matilainen
2015-12-03 13:49 4% ` Richardson, Bruce
2015-12-03 15:46 4% ` Mcnamara, John
2015-12-03 13:39 7% ` Panu Matilainen
2015-12-03 13:41 4% ` Thomas Monjalon
2015-12-03 14:05 36% ` [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 1:22 4% [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library Ferruh Yigit
2015-12-03 1:36 4% ` Thomas Monjalon
2015-12-03 1:59 4% ` Ferruh Yigit
2015-12-03 2:15 4% ` [dpdk-dev] [PATCH v3] " Ferruh Yigit
2015-12-03 2:22 4% ` Thomas Monjalon
2015-12-03 11:24 4% ` Ferruh Yigit
2015-12-03 8:18 4% ` [dpdk-dev] [PATCH v2] " Christian Ehrhardt
2015-12-03 11:18 4% ` Ferruh Yigit
2015-12-03 14:01 4% ` Ferruh Yigit
2015-12-03 12:49 7% ` Panu Matilainen
2015-12-03 13:51 4% ` [dpdk-dev] [PATCH v4] " Ferruh Yigit
2015-12-06 14:37 4% ` Thomas Monjalon
2015-12-03 1:38 3% [dpdk-dev] [PATCH] eal: don't crash if one pci device fails Stephen Hemminger
2015-12-03 10:02 0% ` Bruce Richardson
2015-12-03 10:08 0% ` David Marchand
2015-12-03 2:27 3% [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 16:21 [dpdk-dev] [PATCH v7 2/4] examples: add lthread subsystem for performance-thread Ian Betts
2015-12-04 10:34 ` [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread Ian Betts
2015-12-04 18:03 ` Stephen Hemminger
2015-12-04 18:33 ` Thomas Monjalon
2015-12-05 12:06 ` Betts, Ian
2015-12-05 17:53 ` Glynn, Michael J
2015-12-05 19:47 3% ` Stephen Hemminger
2015-12-05 21:21 0% ` Thomas Monjalon
2015-12-06 6:17 0% ` Betts, Ian
2015-12-04 2:08 3% [dpdk-dev] [PATCH] virtio: fix link state regression Stephen Hemminger
2015-12-04 3:29 0% ` Yuanhan Liu
2015-12-04 15:25 0% ` Iremonger, Bernard
2015-12-04 15:27 0% ` Thomas Monjalon
2015-12-04 15:59 3% [dpdk-dev] [PATCH resend] " Stephen Hemminger
2015-12-04 16:18 0% ` Iremonger, Bernard
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-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-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
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
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-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
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).