[dpdk-dev] [PATCH 00/13] Fixes and tweaks

[dpdk-dev] [PATCH 00/13] Fixes and tweaks

[Michał Mirosław]

This is a loose set of small fixes accumulated here at Atende Software
to be upstreamed. Please consider and apply each one separately.

Best Regards,
Michal Mirosław

---
Michał Mirosław (11):
  EAL: count nr_overcommit_hugepages as available
  mbuf: rte_pktmbuf_free_bulk()
  rte_ether: set PKT_RX_VLAN_STRIPPED in rte_vlan_strip()
  acl: allow zero verdict
  acl: fix acl_flow_data comments
  PMD/af_packet: guard against buffer overruns in RX path
  PMD/af_packet: guard against buffer overruns in TX path
  KNI: provided netif name's source is user-space
  KNI: guard against unterminated dev_info.name leading to BUG in
    alloc_netdev()
  i40e: return -errno when intr setup fails
  i40e: improve message grepability

Paweł Małachowski (1):
  null: fake PMD capabilities

Piotr Bartosiewicz (1):
  pcap: fix timestamps in output pcap file

 drivers/net/af_packet/rte_eth_af_packet.c       |  29 ++--
 drivers/net/i40e/i40e_ethdev.c                  | 203 +++++++++---------------
 drivers/net/null/rte_eth_null.c                 |  13 +-
 drivers/net/pcap/rte_eth_pcap.c                 |   2 +-
 lib/librte_acl/acl_run.h                        |   4 +-
 lib/librte_acl/rte_acl.c                        |   3 +-
 lib/librte_acl/rte_acl.h                        |   2 -
 lib/librte_eal/linuxapp/eal/eal_hugepage_info.c |  43 +++--
 lib/librte_eal/linuxapp/eal/eal_interrupts.c    |   2 +-
 lib/librte_eal/linuxapp/kni/kni_misc.c          |  10 +-
 lib/librte_mbuf/rte_mbuf.h                      |  15 ++
 lib/librte_net/rte_ether.h                      |   2 +-
 lib/librte_table/rte_table_acl.c                |   2 +-
 13 files changed, 169 insertions(+), 161 deletions(-)

-- 
2.10.2

[dpdk-dev] [PATCH 02/13] mbuf: rte_pktmbuf_free_bulk()

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>

---
 lib/librte_mbuf/rte_mbuf.h | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index ead7c6e..a95d99f 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -1248,6 +1248,21 @@ static inline void rte_pktmbuf_free(struct rte_mbuf *m)
 }
 
 /**
+ * Free multiple packet mbufs back into their original mempool(s).
+ *
+ * @param mp
+ *   Pointer to array of packet mbufs to be freed.
+ * @param n
+ *   Count of packet mbufs to free.
+ */
+static inline void rte_pktmbuf_free_bulk(struct rte_mbuf **mp, uint32_t n)
+{
+	uint32_t i;
+	for (i = 0; i < n; ++i)
+		rte_pktmbuf_free(mp[i]);
+}
+
+/**
  * Creates a "clone" of the given packet mbuf.
  *
  * Walks through all segments of the given packet mbuf, and for each of them:
-- 
2.10.2

Re: [dpdk-dev] [PATCH 02/13] mbuf: rte_pktmbuf_free_bulk()

[Stephen Hemminger]

On Tue, 13 Dec 2016 02:08:15 +0100 (CET)
Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:

> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> 
> ---
>  lib/librte_mbuf/rte_mbuf.h | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index ead7c6e..a95d99f 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -1248,6 +1248,21 @@ static inline void rte_pktmbuf_free(struct rte_mbuf *m)
>  }
>  
>  /**
> + * Free multiple packet mbufs back into their original mempool(s).
> + *
> + * @param mp
> + *   Pointer to array of packet mbufs to be freed.
> + * @param n
> + *   Count of packet mbufs to free.
> + */
> +static inline void rte_pktmbuf_free_bulk(struct rte_mbuf **mp, uint32_t n)
> +{
> +	uint32_t i;
> +	for (i = 0; i < n; ++i)
> +		rte_pktmbuf_free(mp[i]);
> +}

Why not do something smarter that uses mempool_put_bulk?

Re: [dpdk-dev] [PATCH 02/13] mbuf: rte_pktmbuf_free_bulk()

[Michał Mirosław]

On Tue, Dec 13, 2016 at 01:41:11PM -0800, Stephen Hemminger wrote:
> On Tue, 13 Dec 2016 02:08:15 +0100 (CET)
> Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
> 
> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > 
> > ---
> >  lib/librte_mbuf/rte_mbuf.h | 15 +++++++++++++++
> >  1 file changed, 15 insertions(+)
> > 
> > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > index ead7c6e..a95d99f 100644
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -1248,6 +1248,21 @@ static inline void rte_pktmbuf_free(struct rte_mbuf *m)
> >  }
> >  
> >  /**
> > + * Free multiple packet mbufs back into their original mempool(s).
> > + *
> > + * @param mp
> > + *   Pointer to array of packet mbufs to be freed.
> > + * @param n
> > + *   Count of packet mbufs to free.
> > + */
> > +static inline void rte_pktmbuf_free_bulk(struct rte_mbuf **mp, uint32_t n)
> > +{
> > +	uint32_t i;
> > +	for (i = 0; i < n; ++i)
> > +		rte_pktmbuf_free(mp[i]);
> > +}
> 
> Why not do something smarter that uses mempool_put_bulk?

I haven't noticed there even is something like it implemented. I'll have
a look. It can be implemented in another patch, though.

Best Regards,
Michał Mirosław

[dpdk-dev] [PATCH 01/13] EAL: count nr_overcommit_hugepages as available

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>

---
 lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 43 ++++++++++++++++++-------
 1 file changed, 32 insertions(+), 11 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
index 18858e2..f391e07 100644
--- a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
+++ b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
@@ -61,30 +61,38 @@
 
 static const char sys_dir_path[] = "/sys/kernel/mm/hugepages";
 
+static int get_hp_sysfs_value(const char *subdir, const char *file, long unsigned *val)
+{
+	char path[PATH_MAX];
+
+	snprintf(path, sizeof(path), "%s/%s/%s",
+			sys_dir_path, subdir, file);
+	return eal_parse_sysfs_value(path, val);
+}
+
 /* this function is only called from eal_hugepage_info_init which itself
  * is only called from a primary process */
 static uint32_t
 get_num_hugepages(const char *subdir)
 {
-	char path[PATH_MAX];
-	long unsigned resv_pages, num_pages = 0;
+	long unsigned resv_pages, num_pages, over_pages, surplus_pages;
 	const char *nr_hp_file = "free_hugepages";
 	const char *nr_rsvd_file = "resv_hugepages";
+	const char *nr_over_file = "nr_overcommit_hugepages";
+	const char *nr_splus_file = "surplus_hugepages";
 
 	/* first, check how many reserved pages kernel reports */
-	snprintf(path, sizeof(path), "%s/%s/%s",
-			sys_dir_path, subdir, nr_rsvd_file);
-	if (eal_parse_sysfs_value(path, &resv_pages) < 0)
+	if (get_hp_sysfs_value(subdir, nr_rsvd_file, &resv_pages) < 0)
 		return 0;
 
-	snprintf(path, sizeof(path), "%s/%s/%s",
-			sys_dir_path, subdir, nr_hp_file);
-	if (eal_parse_sysfs_value(path, &num_pages) < 0)
+	if (get_hp_sysfs_value(subdir, nr_hp_file, &num_pages) < 0)
 		return 0;
 
-	if (num_pages == 0)
-		RTE_LOG(WARNING, EAL, "No free hugepages reported in %s\n",
-				subdir);
+	if (get_hp_sysfs_value(subdir, nr_over_file, &over_pages) < 0)
+		over_pages = 0;
+
+	if (get_hp_sysfs_value(subdir, nr_splus_file, &surplus_pages) < 0)
+		surplus_pages = 0;
 
 	/* adjust num_pages */
 	if (num_pages >= resv_pages)
@@ -92,6 +100,19 @@ get_num_hugepages(const char *subdir)
 	else if (resv_pages)
 		num_pages = 0;
 
+	if (over_pages >= surplus_pages)
+		over_pages -= surplus_pages;
+	else
+		over_pages = 0;
+
+	if (num_pages == 0 && over_pages == 0)
+		RTE_LOG(WARNING, EAL, "No available hugepages reported in %s\n",
+				subdir);
+
+	num_pages += over_pages;
+	if (num_pages < over_pages) /* overflow */
+		num_pages = UINT32_MAX;
+
 	/* we want to return a uint32_t and more than this looks suspicious
 	 * anyway ... */
 	if (num_pages > UINT32_MAX)
-- 
2.10.2

[dpdk-dev] [PATCH v2 01/13] EAL: count nr_overcommit_hugepages as available

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 43 ++++++++++++++++++-------
 1 file changed, 32 insertions(+), 11 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
index 18858e2..b68f060 100644
--- a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
+++ b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
@@ -61,30 +61,38 @@
 
 static const char sys_dir_path[] = "/sys/kernel/mm/hugepages";
 
+static int get_hp_sysfs_value(const char *subdir, const char *file, unsigned long *val)
+{
+	char path[PATH_MAX];
+
+	snprintf(path, sizeof(path), "%s/%s/%s",
+			sys_dir_path, subdir, file);
+	return eal_parse_sysfs_value(path, val);
+}
+
 /* this function is only called from eal_hugepage_info_init which itself
  * is only called from a primary process */
 static uint32_t
 get_num_hugepages(const char *subdir)
 {
-	char path[PATH_MAX];
-	long unsigned resv_pages, num_pages = 0;
+	unsigned long resv_pages, num_pages, over_pages, surplus_pages;
 	const char *nr_hp_file = "free_hugepages";
 	const char *nr_rsvd_file = "resv_hugepages";
+	const char *nr_over_file = "nr_overcommit_hugepages";
+	const char *nr_splus_file = "surplus_hugepages";
 
 	/* first, check how many reserved pages kernel reports */
-	snprintf(path, sizeof(path), "%s/%s/%s",
-			sys_dir_path, subdir, nr_rsvd_file);
-	if (eal_parse_sysfs_value(path, &resv_pages) < 0)
+	if (get_hp_sysfs_value(subdir, nr_rsvd_file, &resv_pages) < 0)
 		return 0;
 
-	snprintf(path, sizeof(path), "%s/%s/%s",
-			sys_dir_path, subdir, nr_hp_file);
-	if (eal_parse_sysfs_value(path, &num_pages) < 0)
+	if (get_hp_sysfs_value(subdir, nr_hp_file, &num_pages) < 0)
 		return 0;
 
-	if (num_pages == 0)
-		RTE_LOG(WARNING, EAL, "No free hugepages reported in %s\n",
-				subdir);
+	if (get_hp_sysfs_value(subdir, nr_over_file, &over_pages) < 0)
+		over_pages = 0;
+
+	if (get_hp_sysfs_value(subdir, nr_splus_file, &surplus_pages) < 0)
+		surplus_pages = 0;
 
 	/* adjust num_pages */
 	if (num_pages >= resv_pages)
@@ -92,6 +100,19 @@ get_num_hugepages(const char *subdir)
 	else if (resv_pages)
 		num_pages = 0;
 
+	if (over_pages >= surplus_pages)
+		over_pages -= surplus_pages;
+	else
+		over_pages = 0;
+
+	if (num_pages == 0 && over_pages == 0)
+		RTE_LOG(WARNING, EAL, "No available hugepages reported in %s\n",
+				subdir);
+
+	num_pages += over_pages;
+	if (num_pages < over_pages) /* overflow */
+		num_pages = UINT32_MAX;
+
 	/* we want to return a uint32_t and more than this looks suspicious
 	 * anyway ... */
 	if (num_pages > UINT32_MAX)
-- 
2.10.2

Re: [dpdk-dev] [PATCH v2 01/13] EAL: count nr_overcommit_hugepages as available

[Thomas Monjalon]

13/12/2016 02:28, Michał Mirosław:
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> ---
>  lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 43 ++++++++++++++++++-------
>  1 file changed, 32 insertions(+), 11 deletions(-)

There is neither explanation nor comments for this patch.
Michal, please check with Sergio (mem maintainer) what can be done.

Re: [dpdk-dev] [PATCH v2 01/13] EAL: count nr_overcommit_hugepages as available

[Michał Mirosław]

On Sun, Apr 30, 2017 at 05:53:55PM +0200, Thomas Monjalon wrote:
> 13/12/2016 02:28, Michał Mirosław:
> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > ---
> >  lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 43 ++++++++++++++++++-------
> >  1 file changed, 32 insertions(+), 11 deletions(-)
> There is neither explanation nor comments for this patch.
> Michal, please check with Sergio (mem maintainer) what can be done.

I think the patch needs to be rebased and verified on new version. I won't
be able to come back to this in next two weeks, but if you have any comments,
please send them in.

Best Regards,
Michał Mirosław

Re: [dpdk-dev] [PATCH v2 01/13] EAL: count nr_overcommit_hugepages as available

[Ferruh Yigit]

On 5/4/2017 7:43 PM, mirq-linux at rere.qmqm.pl (Michał Mirosław) wrote:
> On Sun, Apr 30, 2017 at 05:53:55PM +0200, Thomas Monjalon wrote:
>> 13/12/2016 02:28, Micha? Miros?aw:
>>> Signed-off-by: Micha? Miros?aw <michal.miroslaw at atendesoftware.pl>
>>> ---
>>>  lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 43 ++++++++++++++++++-------
>>>  1 file changed, 32 insertions(+), 11 deletions(-)
>> There is neither explanation nor comments for this patch.
>> Michal, please check with Sergio (mem maintainer) what can be done.
> 
> I think the patch needs to be rebased and verified on new version. I won't
> be able to come back to this in next two weeks, but if you have any comments,
> please send them in.

Hi Michal,

This patch is waiting for an update for a long time, I am updating it's status
as "Change Requested", if this is still relevant please sent a patch on top of
latest repo.

For reference, patch: https://patches.dpdk.org/patch/17888/

Thanks,
ferruh

[dpdk-dev] [PATCH 05/13] acl: fix acl_flow_data comments

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 lib/librte_acl/acl_run.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_acl/acl_run.h b/lib/librte_acl/acl_run.h
index 024f393..a862ff6 100644
--- a/lib/librte_acl/acl_run.h
+++ b/lib/librte_acl/acl_run.h
@@ -69,10 +69,10 @@ struct acl_flow_data {
 	uint32_t            trie;
 	/* current trie index (0 to N-1) */
 	uint32_t            cmplt_size;
+	/* maximum number of packets to process */
 	uint32_t            total_packets;
-	uint32_t            categories;
 	/* number of result categories per packet. */
-	/* maximum number of packets to process */
+	uint32_t            categories;
 	const uint64_t     *trans;
 	const uint8_t     **data;
 	uint32_t           *results;
-- 
2.10.2

Re: [dpdk-dev] [PATCH 05/13] acl: fix acl_flow_data comments

[Ananyev, Konstantin]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> Sent: Tuesday, December 13, 2016 1:08 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH 05/13] acl: fix acl_flow_data comments
> 
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> ---
>  lib/librte_acl/acl_run.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_acl/acl_run.h b/lib/librte_acl/acl_run.h
> index 024f393..a862ff6 100644
> --- a/lib/librte_acl/acl_run.h
> +++ b/lib/librte_acl/acl_run.h
> @@ -69,10 +69,10 @@ struct acl_flow_data {
>  	uint32_t            trie;
>  	/* current trie index (0 to N-1) */
>  	uint32_t            cmplt_size;
> +	/* maximum number of packets to process */
>  	uint32_t            total_packets;
> -	uint32_t            categories;
>  	/* number of result categories per packet. */
> -	/* maximum number of packets to process */
> +	uint32_t            categories;
>  	const uint64_t     *trans;
>  	const uint8_t     **data;
>  	uint32_t           *results;
> --

Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>

> 2.10.2

Re: [dpdk-dev] [PATCH 05/13] acl: fix acl_flow_data comments

[Thomas Monjalon]

> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> 
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>

Applied, thanks

[dpdk-dev] [PATCH 03/13] rte_ether: set PKT_RX_VLAN_STRIPPED in rte_vlan_strip()

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>

---
 lib/librte_net/rte_ether.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
index ff3d065..26a8843 100644
--- a/lib/librte_net/rte_ether.h
+++ b/lib/librte_net/rte_ether.h
@@ -357,7 +357,7 @@ static inline int rte_vlan_strip(struct rte_mbuf *m)
 		return -1;
 
 	struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 1);
-	m->ol_flags |= PKT_RX_VLAN_PKT;
+	m->ol_flags |= PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED;
 	m->vlan_tci = rte_be_to_cpu_16(vh->vlan_tci);
 
 	/* Copy ether header over rather than moving whole packet */
-- 
2.10.2

Re: [dpdk-dev] [PATCH 03/13] rte_ether: set PKT_RX_VLAN_STRIPPED in rte_vlan_strip()

[Thomas Monjalon]

It is fixing the introduction of the new flag PKT_RX_VLAN_STRIPPED.

Fixes: b37b528d957c ("mbuf: add new Rx flags for stripped VLAN")

This patch is applying the flag to the software emulation case
(currently only for virtio).
So the comment of this flag should be changed:

/**
 * A vlan has been stripped by the hardware and its tci is saved in
 * mbuf->vlan_tci. This can only happen if vlan stripping is enabled
 * in the RX configuration of the PMD.
 */
#define PKT_RX_VLAN_STRIPPED (1ULL << 6)                                                                         


> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
[...]
> --- a/lib/librte_net/rte_ether.h
> +++ b/lib/librte_net/rte_ether.h
> @@ -357,7 +357,7 @@ static inline int rte_vlan_strip(struct rte_mbuf *m)
>  		return -1;
>  
>  	struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 1);
> -	m->ol_flags |= PKT_RX_VLAN_PKT;
> +	m->ol_flags |= PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED;
>  	m->vlan_tci = rte_be_to_cpu_16(vh->vlan_tci);
>  
>  	/* Copy ether header over rather than moving whole packet */

I think this flag should also be removed in the function rte_vlan_insert().

Re: [dpdk-dev] [PATCH 03/13] rte_ether: set PKT_RX_VLAN_STRIPPED in rte_vlan_strip()

[Olivier MATZ]

Hi,

On Mon, 30 Jan 2017 10:54:08 +0100, Thomas Monjalon
<thomas.monjalon@6wind.com> wrote:
> It is fixing the introduction of the new flag PKT_RX_VLAN_STRIPPED.
> 
> Fixes: b37b528d957c ("mbuf: add new Rx flags for stripped VLAN")
> 
> This patch is applying the flag to the software emulation case
> (currently only for virtio).
> So the comment of this flag should be changed:
> 
> /**
>  * A vlan has been stripped by the hardware and its tci is saved in
>  * mbuf->vlan_tci. This can only happen if vlan stripping is enabled
>  * in the RX configuration of the PMD.
>  */
> #define PKT_RX_VLAN_STRIPPED (1ULL <<
> 6)                                                                         
> 
> 
> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>  
> [...]
> > --- a/lib/librte_net/rte_ether.h
> > +++ b/lib/librte_net/rte_ether.h
> > @@ -357,7 +357,7 @@ static inline int rte_vlan_strip(struct
> > rte_mbuf *m) return -1;
> >  
> >  	struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 1);
> > -	m->ol_flags |= PKT_RX_VLAN_PKT;
> > +	m->ol_flags |= PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED;
> >  	m->vlan_tci = rte_be_to_cpu_16(vh->vlan_tci);
> >  
> >  	/* Copy ether header over rather than moving whole packet
> > */  
> 
> I think this flag should also be removed in the function
> rte_vlan_insert().

Agree with Thomas, I think rte_vlan_insert() should be updated too.

But I don't think the comment of the mbuf flag should be changed:
"stripped by the hardware" is a bit ambiguous for virtual drivers, but
we can understand that for virtual drivers the same work is done in
software.

Regards,
Olivier

Re: [dpdk-dev] [PATCH 03/13] rte_ether: set PKT_RX_VLAN_STRIPPED in rte_vlan_strip()

[Thomas Monjalon]

09/02/2017 16:56, Olivier MATZ:
> Hi,
> 
> On Mon, 30 Jan 2017 10:54:08 +0100, Thomas Monjalon
> <thomas.monjalon@6wind.com> wrote:
> > It is fixing the introduction of the new flag PKT_RX_VLAN_STRIPPED.
> > 
> > Fixes: b37b528d957c ("mbuf: add new Rx flags for stripped VLAN")
> > 
> > This patch is applying the flag to the software emulation case
> > (currently only for virtio).
> > So the comment of this flag should be changed:
> > 
> > /**
> >  * A vlan has been stripped by the hardware and its tci is saved in
> >  * mbuf->vlan_tci. This can only happen if vlan stripping is enabled
> >  * in the RX configuration of the PMD.
> >  */
> > #define PKT_RX_VLAN_STRIPPED (1ULL <<
> > 6)                                                                         
> > 
> > 
> > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>  
> > [...]
> > > --- a/lib/librte_net/rte_ether.h
> > > +++ b/lib/librte_net/rte_ether.h
> > > @@ -357,7 +357,7 @@ static inline int rte_vlan_strip(struct
> > > rte_mbuf *m) return -1;
> > >  
> > >  	struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 1);
> > > -	m->ol_flags |= PKT_RX_VLAN_PKT;
> > > +	m->ol_flags |= PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED;
> > >  	m->vlan_tci = rte_be_to_cpu_16(vh->vlan_tci);
> > >  
> > >  	/* Copy ether header over rather than moving whole packet
> > > */  
> > 
> > I think this flag should also be removed in the function
> > rte_vlan_insert().
> 
> Agree with Thomas, I think rte_vlan_insert() should be updated too.
> 
> But I don't think the comment of the mbuf flag should be changed:
> "stripped by the hardware" is a bit ambiguous for virtual drivers, but
> we can understand that for virtual drivers the same work is done in
> software.

No more comment?

Olivier, the author is not replying.
I think we should have updated the patch ourself.
How risky it is for 17.05?
Should it wait for 17.08?

Re: [dpdk-dev] [PATCH 03/13] rte_ether: set PKT_RX_VLAN_STRIPPED in rte_vlan_strip()

[Olivier MATZ]

Hi Thomas,

On Sun, 30 Apr 2017 17:58:45 +0200, Thomas Monjalon <thomas@monjalon.net> wrote:
> 09/02/2017 16:56, Olivier MATZ:
> > Hi,
> > 
> > On Mon, 30 Jan 2017 10:54:08 +0100, Thomas Monjalon
> > <thomas.monjalon@6wind.com> wrote:  
> > > It is fixing the introduction of the new flag PKT_RX_VLAN_STRIPPED.
> > > 
> > > Fixes: b37b528d957c ("mbuf: add new Rx flags for stripped VLAN")
> > > 
> > > This patch is applying the flag to the software emulation case
> > > (currently only for virtio).
> > > So the comment of this flag should be changed:
> > > 
> > > /**
> > >  * A vlan has been stripped by the hardware and its tci is saved in
> > >  * mbuf->vlan_tci. This can only happen if vlan stripping is enabled
> > >  * in the RX configuration of the PMD.
> > >  */
> > > #define PKT_RX_VLAN_STRIPPED (1ULL <<
> > > 6)                                                                         
> > > 
> > >   
> > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>    
> > > [...]  
> > > > --- a/lib/librte_net/rte_ether.h
> > > > +++ b/lib/librte_net/rte_ether.h
> > > > @@ -357,7 +357,7 @@ static inline int rte_vlan_strip(struct
> > > > rte_mbuf *m) return -1;
> > > >  
> > > >  	struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 1);
> > > > -	m->ol_flags |= PKT_RX_VLAN_PKT;
> > > > +	m->ol_flags |= PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED;
> > > >  	m->vlan_tci = rte_be_to_cpu_16(vh->vlan_tci);
> > > >  
> > > >  	/* Copy ether header over rather than moving whole packet
> > > > */    
> > > 
> > > I think this flag should also be removed in the function
> > > rte_vlan_insert().  
> > 
> > Agree with Thomas, I think rte_vlan_insert() should be updated too.
> > 
> > But I don't think the comment of the mbuf flag should be changed:
> > "stripped by the hardware" is a bit ambiguous for virtual drivers, but
> > we can understand that for virtual drivers the same work is done in
> > software.  
> 
> No more comment?
> 
> Olivier, the author is not replying.
> I think we should have updated the patch ourself.
> How risky it is for 17.05?
> Should it wait for 17.08?

I don't feel it's too risky for 17.05.
It's used in virtio and af_packet drivers, only when using vlan offload.

FYI, for 17.08, I plan to put the mbuf vlan flag subject on the table
again: when I introduced the new flag VLAN_STRIPPED, we acted that another
flag or pkt_type had to be introduced, but it was not really finished.

Olivier

[dpdk-dev] [PATCH v2] net: fix stripped VLAN flag for offload emulation

[Thomas Monjalon]

From: Michał Mirosław <michal.miroslaw@atendesoftware.pl>

Apply the new flag PKT_RX_VLAN_STRIPPED to the software emulation case
(currently only for virtio and af_packet).

Fixes: b37b528d957c ("mbuf: add new Rx flags for stripped VLAN")
Cc: stable@dpdk.org

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
v2: add explanations and update rte_vlan_insert()
---
 lib/librte_net/rte_ether.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
index ff3d06540..5edf66c3f 100644
--- a/lib/librte_net/rte_ether.h
+++ b/lib/librte_net/rte_ether.h
@@ -357,7 +357,7 @@ static inline int rte_vlan_strip(struct rte_mbuf *m)
 		return -1;
 
 	struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 1);
-	m->ol_flags |= PKT_RX_VLAN_PKT;
+	m->ol_flags |= PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED;
 	m->vlan_tci = rte_be_to_cpu_16(vh->vlan_tci);
 
 	/* Copy ether header over rather than moving whole packet */
@@ -407,6 +407,8 @@ static inline int rte_vlan_insert(struct rte_mbuf **m)
 	vh = (struct vlan_hdr *) (nh + 1);
 	vh->vlan_tci = rte_cpu_to_be_16((*m)->vlan_tci);
 
+	(*m)->ol_flags &= ~PKT_RX_VLAN_STRIPPED;
+
 	return 0;
 }
 
-- 
2.12.2

Re: [dpdk-dev] [PATCH v2] net: fix stripped VLAN flag for offload emulation

[Olivier Matz]

Hi Thomas,

On Fri,  5 May 2017 00:36:13 +0200, Thomas Monjalon <thomas@monjalon.net> wrote:
> From: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> 
> Apply the new flag PKT_RX_VLAN_STRIPPED to the software emulation case
> (currently only for virtio and af_packet).
> 
> Fixes: b37b528d957c ("mbuf: add new Rx flags for stripped VLAN")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> v2: add explanations and update rte_vlan_insert()
> ---
>  lib/librte_net/rte_ether.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
> index ff3d06540..5edf66c3f 100644
> --- a/lib/librte_net/rte_ether.h
> +++ b/lib/librte_net/rte_ether.h
> @@ -357,7 +357,7 @@ static inline int rte_vlan_strip(struct rte_mbuf *m)
>  		return -1;
>  
>  	struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 1);
> -	m->ol_flags |= PKT_RX_VLAN_PKT;
> +	m->ol_flags |= PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED;
>  	m->vlan_tci = rte_be_to_cpu_16(vh->vlan_tci);
>  
>  	/* Copy ether header over rather than moving whole packet */
> @@ -407,6 +407,8 @@ static inline int rte_vlan_insert(struct rte_mbuf **m)
>  	vh = (struct vlan_hdr *) (nh + 1);
>  	vh->vlan_tci = rte_cpu_to_be_16((*m)->vlan_tci);
>  
> +	(*m)->ol_flags &= ~PKT_RX_VLAN_STRIPPED;
> +
>  	return 0;
>  }
>  

Having disymetric flags looks strange at first glance, but I think
you are right and PKT_RX_VLAN_PKT should be kept in rte_vlan_strip()
for compat purpose. As I said previously in the thread, I think
there is some work remaining to clean-up the vlan offload flags,
we should do this for 17.08.


Acked-by: Olivier Matz <olivier.matz@6wind.com>

Re: [dpdk-dev] [dpdk-stable] [PATCH v2] net: fix stripped VLAN flag for offload emulation

[Thomas Monjalon]

05/05/2017 12:02, Olivier Matz:
> Hi Thomas,
> 
> On Fri,  5 May 2017 00:36:13 +0200, Thomas Monjalon <thomas@monjalon.net> wrote:
> > From: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > 
> > Apply the new flag PKT_RX_VLAN_STRIPPED to the software emulation case
> > (currently only for virtio and af_packet).
> > 
> > Fixes: b37b528d957c ("mbuf: add new Rx flags for stripped VLAN")
> > Cc: stable@dpdk.org
> > 
> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > ---
> > v2: add explanations and update rte_vlan_insert()
> > ---
> >  lib/librte_net/rte_ether.h | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
> > index ff3d06540..5edf66c3f 100644
> > --- a/lib/librte_net/rte_ether.h
> > +++ b/lib/librte_net/rte_ether.h
> > @@ -357,7 +357,7 @@ static inline int rte_vlan_strip(struct rte_mbuf *m)
> >  		return -1;
> >  
> >  	struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 1);
> > -	m->ol_flags |= PKT_RX_VLAN_PKT;
> > +	m->ol_flags |= PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED;
> >  	m->vlan_tci = rte_be_to_cpu_16(vh->vlan_tci);
> >  
> >  	/* Copy ether header over rather than moving whole packet */
> > @@ -407,6 +407,8 @@ static inline int rte_vlan_insert(struct rte_mbuf **m)
> >  	vh = (struct vlan_hdr *) (nh + 1);
> >  	vh->vlan_tci = rte_cpu_to_be_16((*m)->vlan_tci);
> >  
> > +	(*m)->ol_flags &= ~PKT_RX_VLAN_STRIPPED;
> > +
> >  	return 0;
> >  }
> >  
> 
> Having disymetric flags looks strange at first glance, but I think
> you are right and PKT_RX_VLAN_PKT should be kept in rte_vlan_strip()
> for compat purpose. As I said previously in the thread, I think
> there is some work remaining to clean-up the vlan offload flags,
> we should do this for 17.08.
> 
> 
> Acked-by: Olivier Matz <olivier.matz@6wind.com>

Applied, thanks

[dpdk-dev] [PATCH 06/13] null: fake PMD capabilities

[Michał Mirosław]

From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>

Thanks to that change we can use Null PMD for testing purposes.

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 drivers/net/null/rte_eth_null.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 836d982..f32ba2a 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
 	return 0;
 }
 
+static void
+eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
+
 
 static void
 eth_dev_info(struct rte_eth_dev *dev,
@@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,
 	dev_info->pci_dev = NULL;
 	dev_info->reta_size = internals->reta_size;
 	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
+	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking packets in /dev/null */
+	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
+	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;
 }
 
 static void
@@ -477,7 +483,12 @@ static const struct eth_dev_ops ops = {
 	.reta_update = eth_rss_reta_update,
 	.reta_query = eth_rss_reta_query,
 	.rss_hash_update = eth_rss_hash_update,
-	.rss_hash_conf_get = eth_rss_hash_conf_get
+	.rss_hash_conf_get = eth_rss_hash_conf_get,
+	/* Fake our capabilities */
+	.promiscuous_enable   = eth_dev_void_ok,
+	.promiscuous_disable  = eth_dev_void_ok,
+	.allmulticast_enable  = eth_dev_void_ok,
+	.allmulticast_disable = eth_dev_void_ok
 };
 
 int
-- 
2.10.2

[dpdk-dev] [PATCH v2 06/13] null: fake PMD capabilities

[Michał Mirosław]

From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>

Thanks to that change we can use Null PMD for testing purposes.

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 drivers/net/null/rte_eth_null.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 836d982..09d53b0 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
 	return 0;
 }
 
+static void
+eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
+
 
 static void
 eth_dev_info(struct rte_eth_dev *dev,
@@ -304,6 +307,11 @@ eth_dev_info(struct rte_eth_dev *dev,
 	dev_info->pci_dev = NULL;
 	dev_info->reta_size = internals->reta_size;
 	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
+	/* We hereby declare we can RX offload VLAN-s out of thin air and update
+	 * checksums and VLANs before sinking packets in /dev/null */
+	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
+	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT |
+		DEV_TX_OFFLOAD_IPV4_CKSUM;
 }
 
 static void
@@ -477,7 +485,12 @@ static const struct eth_dev_ops ops = {
 	.reta_update = eth_rss_reta_update,
 	.reta_query = eth_rss_reta_query,
 	.rss_hash_update = eth_rss_hash_update,
-	.rss_hash_conf_get = eth_rss_hash_conf_get
+	.rss_hash_conf_get = eth_rss_hash_conf_get,
+	/* Fake our capabilities */
+	.promiscuous_enable   = eth_dev_void_ok,
+	.promiscuous_disable  = eth_dev_void_ok,
+	.allmulticast_enable  = eth_dev_void_ok,
+	.allmulticast_disable = eth_dev_void_ok
 };
 
 int
-- 
2.10.2

[dpdk-dev] [-- 06/13] null: fake PMD capabilities

[Michał Mirosław]

From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 drivers/net/null/rte_eth_null.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 836d982..c802bc0 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
 	return 0;
 }
 
+static void
+eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
+
 
 static void
 eth_dev_info(struct rte_eth_dev *dev,
@@ -304,6 +307,12 @@ eth_dev_info(struct rte_eth_dev *dev,
 	dev_info->pci_dev = NULL;
 	dev_info->reta_size = internals->reta_size;
 	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
+	/* We hereby declare we can RX offload VLAN-s out of thin air and update
+	 * checksums and VLANs before sinking packets in /dev/null
+	 */
+	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
+	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT |
+		DEV_TX_OFFLOAD_IPV4_CKSUM;
 }
 
 static void
@@ -477,7 +486,12 @@ static const struct eth_dev_ops ops = {
 	.reta_update = eth_rss_reta_update,
 	.reta_query = eth_rss_reta_query,
 	.rss_hash_update = eth_rss_hash_update,
-	.rss_hash_conf_get = eth_rss_hash_conf_get
+	.rss_hash_conf_get = eth_rss_hash_conf_get,
+	/* Fake our capabilities */
+	.promiscuous_enable   = eth_dev_void_ok,
+	.promiscuous_disable  = eth_dev_void_ok,
+	.allmulticast_enable  = eth_dev_void_ok,
+	.allmulticast_disable = eth_dev_void_ok
 };
 
 int
-- 
2.10.2

Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities

[Ananyev, Konstantin]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> Sent: Tuesday, December 13, 2016 1:08 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> 
> From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
> 
> Thanks to that change we can use Null PMD for testing purposes.
> 
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> ---
>  drivers/net/null/rte_eth_null.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
> index 836d982..f32ba2a 100644
> --- a/drivers/net/null/rte_eth_null.c
> +++ b/drivers/net/null/rte_eth_null.c
> @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
>  	return 0;
>  }
> 
> +static void
> +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
> +
> 
>  static void
>  eth_dev_info(struct rte_eth_dev *dev,
> @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,
>  	dev_info->pci_dev = NULL;
>  	dev_info->reta_size = internals->reta_size;
>  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
> +	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking packets in
> /dev/null */
> +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
> +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;

Hmm, how could it be supported if all that null PMD does on TX - just free the packets?
Same question for RX.
Konstantin

>  }
> 
>  static void
> @@ -477,7 +483,12 @@ static const struct eth_dev_ops ops = {
>  	.reta_update = eth_rss_reta_update,
>  	.reta_query = eth_rss_reta_query,
>  	.rss_hash_update = eth_rss_hash_update,
> -	.rss_hash_conf_get = eth_rss_hash_conf_get
> +	.rss_hash_conf_get = eth_rss_hash_conf_get,
> +	/* Fake our capabilities */
> +	.promiscuous_enable   = eth_dev_void_ok,
> +	.promiscuous_disable  = eth_dev_void_ok,
> +	.allmulticast_enable  = eth_dev_void_ok,
> +	.allmulticast_disable = eth_dev_void_ok
>  };
> 
>  int
> --
> 2.10.2

Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities

[Michal Miroslaw]

On Tue, Dec 13, 2016 at 10:48:32AM +0000, Ananyev, Konstantin wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > Sent: Tuesday, December 13, 2016 1:08 AM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > 
> > From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
> > 
> > Thanks to that change we can use Null PMD for testing purposes.
> > 
> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > ---
> >  drivers/net/null/rte_eth_null.c | 13 ++++++++++++-
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
> > index 836d982..f32ba2a 100644
> > --- a/drivers/net/null/rte_eth_null.c
> > +++ b/drivers/net/null/rte_eth_null.c
> > @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
> >  	return 0;
> >  }
> > 
> > +static void
> > +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
> > +
> > 
> >  static void
> >  eth_dev_info(struct rte_eth_dev *dev,
> > @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,
> >  	dev_info->pci_dev = NULL;
> >  	dev_info->reta_size = internals->reta_size;
> >  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
> > +	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking packets in
> > /dev/null */
> > +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
> > +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;
> 
> Hmm, how could it be supported if all that null PMD does on TX - just free the packets?
> Same question for RX.

You could imagine, that before dropping the packet you insert the tag
and calculate the checksum. The observed effect will be the same.

On RX this always indicates lack of VLAN tag. So whether the offload
is enabled or not it doesn't matter.

Best Regards,
Michał Mirosław

Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities

[Ananyev, Konstantin]

> -----Original Message-----
> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> Sent: Tuesday, December 13, 2016 2:27 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> 
> On Tue, Dec 13, 2016 at 10:48:32AM +0000, Ananyev, Konstantin wrote:
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > > Sent: Tuesday, December 13, 2016 1:08 AM
> > > To: dev@dpdk.org
> > > Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > >
> > > From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
> > >
> > > Thanks to that change we can use Null PMD for testing purposes.
> > >
> > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > ---
> > >  drivers/net/null/rte_eth_null.c | 13 ++++++++++++-
> > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
> > > index 836d982..f32ba2a 100644
> > > --- a/drivers/net/null/rte_eth_null.c
> > > +++ b/drivers/net/null/rte_eth_null.c
> > > @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
> > >  	return 0;
> > >  }
> > >
> > > +static void
> > > +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
> > > +
> > >
> > >  static void
> > >  eth_dev_info(struct rte_eth_dev *dev,
> > > @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,
> > >  	dev_info->pci_dev = NULL;
> > >  	dev_info->reta_size = internals->reta_size;
> > >  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
> > > +	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking packets in
> > > /dev/null */
> > > +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
> > > +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;
> >
> > Hmm, how could it be supported if all that null PMD does on TX - just free the packets?
> > Same question for RX.
> 
> You could imagine, that before dropping the packet you insert the tag
> and calculate the checksum. The observed effect will be the same.
> 
> On RX this always indicates lack of VLAN tag. So whether the offload
> is enabled or not it doesn't matter.

Of course user can imagine whatever he likes, but what the point to advertise these capabilities,
when the PMD clearly doesn't have them?
Again, why these particular ones?
Konstantin

> 
> Best Regards,
> Michał Mirosław

Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities

[Michal Miroslaw]

On Tue, Dec 13, 2016 at 02:37:34PM +0000, Ananyev, Konstantin wrote:
> 
> 
> > -----Original Message-----
> > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > Sent: Tuesday, December 13, 2016 2:27 PM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > 
> > On Tue, Dec 13, 2016 at 10:48:32AM +0000, Ananyev, Konstantin wrote:
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > > > Sent: Tuesday, December 13, 2016 1:08 AM
> > > > To: dev@dpdk.org
> > > > Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > > >
> > > > From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
> > > >
> > > > Thanks to that change we can use Null PMD for testing purposes.
> > > >
> > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > > ---
> > > >  drivers/net/null/rte_eth_null.c | 13 ++++++++++++-
> > > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
> > > > index 836d982..f32ba2a 100644
> > > > --- a/drivers/net/null/rte_eth_null.c
> > > > +++ b/drivers/net/null/rte_eth_null.c
> > > > @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
> > > >  	return 0;
> > > >  }
> > > >
> > > > +static void
> > > > +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
> > > > +
> > > >
> > > >  static void
> > > >  eth_dev_info(struct rte_eth_dev *dev,
> > > > @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,
> > > >  	dev_info->pci_dev = NULL;
> > > >  	dev_info->reta_size = internals->reta_size;
> > > >  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
> > > > +	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking packets in
> > > > /dev/null */
> > > > +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
> > > > +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;
> > >
> > > Hmm, how could it be supported if all that null PMD does on TX - just free the packets?
> > > Same question for RX.
> > 
> > You could imagine, that before dropping the packet you insert the tag
> > and calculate the checksum. The observed effect will be the same.
> > 
> > On RX this always indicates lack of VLAN tag. So whether the offload
> > is enabled or not it doesn't matter.
> 
> Of course user can imagine whatever he likes, but what the point to advertise these capabilities,
> when the PMD clearly doesn't have them?
> Again, why these particular ones?

Hmm. I guess we can expand the set. Those were the ones we actually use
(depend on) for testing our code.

This allows to use null PMD for testing in place of real network interface
with those offloads. This patch is to keep users from having to place if's
around their code just to support test scenarios with null PMD.

Best Regards,
Michał Mirosław

Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities

[Ananyev, Konstantin]

> -----Original Message-----
> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> Sent: Tuesday, December 13, 2016 2:58 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> 
> On Tue, Dec 13, 2016 at 02:37:34PM +0000, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > > Sent: Tuesday, December 13, 2016 2:27 PM
> > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > >
> > > On Tue, Dec 13, 2016 at 10:48:32AM +0000, Ananyev, Konstantin wrote:
> > > > > -----Original Message-----
> > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > > > > Sent: Tuesday, December 13, 2016 1:08 AM
> > > > > To: dev@dpdk.org
> > > > > Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > > > >
> > > > > From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
> > > > >
> > > > > Thanks to that change we can use Null PMD for testing purposes.
> > > > >
> > > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > > > ---
> > > > >  drivers/net/null/rte_eth_null.c | 13 ++++++++++++-
> > > > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
> > > > > index 836d982..f32ba2a 100644
> > > > > --- a/drivers/net/null/rte_eth_null.c
> > > > > +++ b/drivers/net/null/rte_eth_null.c
> > > > > @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
> > > > >  	return 0;
> > > > >  }
> > > > >
> > > > > +static void
> > > > > +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
> > > > > +
> > > > >
> > > > >  static void
> > > > >  eth_dev_info(struct rte_eth_dev *dev,
> > > > > @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,
> > > > >  	dev_info->pci_dev = NULL;
> > > > >  	dev_info->reta_size = internals->reta_size;
> > > > >  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
> > > > > +	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking
> packets in
> > > > > /dev/null */
> > > > > +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
> > > > > +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;
> > > >
> > > > Hmm, how could it be supported if all that null PMD does on TX - just free the packets?
> > > > Same question for RX.
> > >
> > > You could imagine, that before dropping the packet you insert the tag
> > > and calculate the checksum. The observed effect will be the same.
> > >
> > > On RX this always indicates lack of VLAN tag. So whether the offload
> > > is enabled or not it doesn't matter.
> >
> > Of course user can imagine whatever he likes, but what the point to advertise these capabilities,
> > when the PMD clearly doesn't have them?
> > Again, why these particular ones?
> 
> Hmm. I guess we can expand the set. Those were the ones we actually use
> (depend on) for testing our code.
> 
> This allows to use null PMD for testing in place of real network interface
> with those offloads. 

As I can see on TX null pmd would just drop the packets, right?
So  the only thing you might check, as I understand, did upper layer code
setup ol_flags  and other mbuf fields properly depending on advertised capabilities
(probably via sme special tx_callback installed  or so).
Is that correct? 
That's ok, I  suppose, but if tomorrow you (or someone else) would like to test
with different RX/TX offloads?   
Shouldn't be advertised offload capabilities be configurable at device creation/attach time
somehow?
Or at least just advertise all possible ones then?

Konstantin

>This patch is to keep users from having to place if's
> around their code just to support test scenarios with null PMD.
> 
> Best Regards,
> Michał Mirosław

Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities

[Ferruh Yigit]

On 12/13/2016 5:12 PM, Ananyev, Konstantin wrote:
> 
> 
>> -----Original Message-----
>> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
>> Sent: Tuesday, December 13, 2016 2:58 PM
>> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
>> Cc: dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
>>
>> On Tue, Dec 13, 2016 at 02:37:34PM +0000, Ananyev, Konstantin wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
>>>> Sent: Tuesday, December 13, 2016 2:27 PM
>>>> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
>>>> Cc: dev@dpdk.org
>>>> Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
>>>>
>>>> On Tue, Dec 13, 2016 at 10:48:32AM +0000, Ananyev, Konstantin wrote:
>>>>>> -----Original Message-----
>>>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
>>>>>> Sent: Tuesday, December 13, 2016 1:08 AM
>>>>>> To: dev@dpdk.org
>>>>>> Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
>>>>>>
>>>>>> From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
>>>>>>
>>>>>> Thanks to that change we can use Null PMD for testing purposes.
>>>>>>
>>>>>> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
>>>>>> ---
>>>>>>  drivers/net/null/rte_eth_null.c | 13 ++++++++++++-
>>>>>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
>>>>>> index 836d982..f32ba2a 100644
>>>>>> --- a/drivers/net/null/rte_eth_null.c
>>>>>> +++ b/drivers/net/null/rte_eth_null.c
>>>>>> @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
>>>>>>  	return 0;
>>>>>>  }
>>>>>>
>>>>>> +static void
>>>>>> +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
>>>>>> +
>>>>>>
>>>>>>  static void
>>>>>>  eth_dev_info(struct rte_eth_dev *dev,
>>>>>> @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,
>>>>>>  	dev_info->pci_dev = NULL;
>>>>>>  	dev_info->reta_size = internals->reta_size;
>>>>>>  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
>>>>>> +	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking
>> packets in
>>>>>> /dev/null */
>>>>>> +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
>>>>>> +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;
>>>>>
>>>>> Hmm, how could it be supported if all that null PMD does on TX - just free the packets?
>>>>> Same question for RX.
>>>>
>>>> You could imagine, that before dropping the packet you insert the tag
>>>> and calculate the checksum. The observed effect will be the same.
>>>>
>>>> On RX this always indicates lack of VLAN tag. So whether the offload
>>>> is enabled or not it doesn't matter.
>>>
>>> Of course user can imagine whatever he likes, but what the point to advertise these capabilities,
>>> when the PMD clearly doesn't have them?
>>> Again, why these particular ones?
>>
>> Hmm. I guess we can expand the set. Those were the ones we actually use
>> (depend on) for testing our code.
>>
>> This allows to use null PMD for testing in place of real network interface
>> with those offloads. 
> 
> As I can see on TX null pmd would just drop the packets, right?
> So  the only thing you might check, as I understand, did upper layer code
> setup ol_flags  and other mbuf fields properly depending on advertised capabilities
> (probably via sme special tx_callback installed  or so).
> Is that correct? 
> That's ok, I  suppose, but if tomorrow you (or someone else) would like to test
> with different RX/TX offloads?   
> Shouldn't be advertised offload capabilities be configurable at device creation/attach time
> somehow?

This sounds good. Getting offload capabilities on runtime as devargs.

> Or at least just advertise all possible ones then?
> 
> Konstantin
> 
>> This patch is to keep users from having to place if's
>> around their code just to support test scenarios with null PMD.
>>
>> Best Regards,
>> Michał Mirosław

[dpdk-dev] [PATCH v4] null: fake PMD capabilities

[Michał Mirosław]

From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>

This allows for testing code which needs offloads to be supported.

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 drivers/net/null/rte_eth_null.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 836d982..e60516f 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
 	return 0;
 }
 
+static void
+eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
+
 
 static void
 eth_dev_info(struct rte_eth_dev *dev,
@@ -304,6 +307,19 @@ eth_dev_info(struct rte_eth_dev *dev,
 	dev_info->pci_dev = NULL;
 	dev_info->reta_size = internals->reta_size;
 	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
+	/* We hereby declare we can RX offload VLAN-s out of thin air (they are not there)
+	 */
+	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP |
+		DEV_RX_OFFLOAD_QINQ_STRIP;
+	/* We promise we will do any TX offloads before passing packets to /dev/null
+	 */
+	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT |
+		DEV_TX_OFFLOAD_IPV4_CKSUM | DEV_TX_OFFLOAD_UDP_CKSUM |
+		DEV_TX_OFFLOAD_TCP_CKSUM | DEV_TX_OFFLOAD_SCTP_CKSUM |
+		DEV_TX_OFFLOAD_TCP_TSO | DEV_TX_OFFLOAD_UDP_TSO |
+		DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM | DEV_TX_OFFLOAD_QINQ_INSERT |
+		DEV_TX_OFFLOAD_VXLAN_TNL_TSO | DEV_TX_OFFLOAD_GRE_TNL_TSO |
+		DEV_TX_OFFLOAD_IPIP_TNL_TSO | DEV_TX_OFFLOAD_GENEVE_TNL_TSO;
 }
 
 static void
@@ -477,7 +493,12 @@ static const struct eth_dev_ops ops = {
 	.reta_update = eth_rss_reta_update,
 	.reta_query = eth_rss_reta_query,
 	.rss_hash_update = eth_rss_hash_update,
-	.rss_hash_conf_get = eth_rss_hash_conf_get
+	.rss_hash_conf_get = eth_rss_hash_conf_get,
+	/* Fake our capabilities */
+	.promiscuous_enable   = eth_dev_void_ok,
+	.promiscuous_disable  = eth_dev_void_ok,
+	.allmulticast_enable  = eth_dev_void_ok,
+	.allmulticast_disable = eth_dev_void_ok
 };
 
 int
-- 
2.10.2

Re: [dpdk-dev] [PATCH v4] null: fake PMD capabilities

[Ferruh Yigit]

On 12/14/2016 7:16 PM, Michał Mirosław wrote:
> From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
> 
> This allows for testing code which needs offloads to be supported.
> 
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> ---
>  drivers/net/null/rte_eth_null.c | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
> index 836d982..e60516f 100644
> --- a/drivers/net/null/rte_eth_null.c
> +++ b/drivers/net/null/rte_eth_null.c
> @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
>  	return 0;
>  }
>  
> +static void
> +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
> +
>  
>  static void
>  eth_dev_info(struct rte_eth_dev *dev,
> @@ -304,6 +307,19 @@ eth_dev_info(struct rte_eth_dev *dev,
>  	dev_info->pci_dev = NULL;
>  	dev_info->reta_size = internals->reta_size;
>  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
> +	/* We hereby declare we can RX offload VLAN-s out of thin air (they are not there)
> +	 */
> +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP |
> +		DEV_RX_OFFLOAD_QINQ_STRIP;
> +	/* We promise we will do any TX offloads before passing packets to /dev/null
> +	 */
> +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT |
> +		DEV_TX_OFFLOAD_IPV4_CKSUM | DEV_TX_OFFLOAD_UDP_CKSUM |
> +		DEV_TX_OFFLOAD_TCP_CKSUM | DEV_TX_OFFLOAD_SCTP_CKSUM |
> +		DEV_TX_OFFLOAD_TCP_TSO | DEV_TX_OFFLOAD_UDP_TSO |
> +		DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM | DEV_TX_OFFLOAD_QINQ_INSERT |
> +		DEV_TX_OFFLOAD_VXLAN_TNL_TSO | DEV_TX_OFFLOAD_GRE_TNL_TSO |
> +		DEV_TX_OFFLOAD_IPIP_TNL_TSO | DEV_TX_OFFLOAD_GENEVE_TNL_TSO;

What do you think reporting offload capa based on user provided devargs,
as suggested by Konstantin?And by default not report any.

>  }
>  
>  static void
> @@ -477,7 +493,12 @@ static const struct eth_dev_ops ops = {
>  	.reta_update = eth_rss_reta_update,
>  	.reta_query = eth_rss_reta_query,
>  	.rss_hash_update = eth_rss_hash_update,
> -	.rss_hash_conf_get = eth_rss_hash_conf_get
> +	.rss_hash_conf_get = eth_rss_hash_conf_get,
> +	/* Fake our capabilities */
> +	.promiscuous_enable   = eth_dev_void_ok,
> +	.promiscuous_disable  = eth_dev_void_ok,
> +	.allmulticast_enable  = eth_dev_void_ok,
> +	.allmulticast_disable = eth_dev_void_ok
>  };
>  
>  int
> 

Re: [dpdk-dev] [PATCH v4] null: fake PMD capabilities

[Michał Mirosław]

On Mon, Jan 09, 2017 at 12:07:36PM +0000, Ferruh Yigit wrote:
> On 12/14/2016 7:16 PM, Michał Mirosław wrote:
> > From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
> > 
> > This allows for testing code which needs offloads to be supported.
> > 
> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > ---
> >  drivers/net/null/rte_eth_null.c | 23 ++++++++++++++++++++++-
> >  1 file changed, 22 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
> > index 836d982..e60516f 100644
> > --- a/drivers/net/null/rte_eth_null.c
> > +++ b/drivers/net/null/rte_eth_null.c
> > @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
> >  	return 0;
> >  }
> >  
> > +static void
> > +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
> > +
> >  
> >  static void
> >  eth_dev_info(struct rte_eth_dev *dev,
> > @@ -304,6 +307,19 @@ eth_dev_info(struct rte_eth_dev *dev,
> >  	dev_info->pci_dev = NULL;
> >  	dev_info->reta_size = internals->reta_size;
> >  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
> > +	/* We hereby declare we can RX offload VLAN-s out of thin air (they are not there)
> > +	 */
> > +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP |
> > +		DEV_RX_OFFLOAD_QINQ_STRIP;
> > +	/* We promise we will do any TX offloads before passing packets to /dev/null
> > +	 */
> > +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT |
> > +		DEV_TX_OFFLOAD_IPV4_CKSUM | DEV_TX_OFFLOAD_UDP_CKSUM |
> > +		DEV_TX_OFFLOAD_TCP_CKSUM | DEV_TX_OFFLOAD_SCTP_CKSUM |
> > +		DEV_TX_OFFLOAD_TCP_TSO | DEV_TX_OFFLOAD_UDP_TSO |
> > +		DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM | DEV_TX_OFFLOAD_QINQ_INSERT |
> > +		DEV_TX_OFFLOAD_VXLAN_TNL_TSO | DEV_TX_OFFLOAD_GRE_TNL_TSO |
> > +		DEV_TX_OFFLOAD_IPIP_TNL_TSO | DEV_TX_OFFLOAD_GENEVE_TNL_TSO;
> 
> What do you think reporting offload capa based on user provided devargs,
> as suggested by Konstantin?And by default not report any.

I can see use of it for people that want to test software fallbacks for
their app. For those who need only a /dev/null port, it doesn't add any value.

Best Regards,
Michał Mirosław

Re: [dpdk-dev] [PATCH v4] null: fake PMD capabilities

[Ferruh Yigit]

On 1/11/2017 10:14 AM, Michał Mirosław wrote:
> On Mon, Jan 09, 2017 at 12:07:36PM +0000, Ferruh Yigit wrote:
>> On 12/14/2016 7:16 PM, Michał Mirosław wrote:
>>> From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
>>>
>>> This allows for testing code which needs offloads to be supported.
>>>
>>> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
>>> ---
>>>  drivers/net/null/rte_eth_null.c | 23 ++++++++++++++++++++++-
>>>  1 file changed, 22 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
>>> index 836d982..e60516f 100644
>>> --- a/drivers/net/null/rte_eth_null.c
>>> +++ b/drivers/net/null/rte_eth_null.c
>>> @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
>>>  	return 0;
>>>  }
>>>  
>>> +static void
>>> +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
>>> +
>>>  
>>>  static void
>>>  eth_dev_info(struct rte_eth_dev *dev,
>>> @@ -304,6 +307,19 @@ eth_dev_info(struct rte_eth_dev *dev,
>>>  	dev_info->pci_dev = NULL;
>>>  	dev_info->reta_size = internals->reta_size;
>>>  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
>>> +	/* We hereby declare we can RX offload VLAN-s out of thin air (they are not there)
>>> +	 */
>>> +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP |
>>> +		DEV_RX_OFFLOAD_QINQ_STRIP;
>>> +	/* We promise we will do any TX offloads before passing packets to /dev/null
>>> +	 */
>>> +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT |
>>> +		DEV_TX_OFFLOAD_IPV4_CKSUM | DEV_TX_OFFLOAD_UDP_CKSUM |
>>> +		DEV_TX_OFFLOAD_TCP_CKSUM | DEV_TX_OFFLOAD_SCTP_CKSUM |
>>> +		DEV_TX_OFFLOAD_TCP_TSO | DEV_TX_OFFLOAD_UDP_TSO |
>>> +		DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM | DEV_TX_OFFLOAD_QINQ_INSERT |
>>> +		DEV_TX_OFFLOAD_VXLAN_TNL_TSO | DEV_TX_OFFLOAD_GRE_TNL_TSO |
>>> +		DEV_TX_OFFLOAD_IPIP_TNL_TSO | DEV_TX_OFFLOAD_GENEVE_TNL_TSO;
>>
>> What do you think reporting offload capa based on user provided devargs,
>> as suggested by Konstantin?And by default not report any.
> 
> I can see use of it for people that want to test software fallbacks for
> their app. For those who need only a /dev/null port, it doesn't add any value.

That would help if user want to test some combination of offload flags,
instead of having all.

> 
> Best Regards,
> Michał Mirosław
> 

[dpdk-dev] [PATCH 04/13] acl: allow zero verdict

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 lib/librte_acl/rte_acl.c         | 3 +--
 lib/librte_acl/rte_acl.h         | 2 --
 lib/librte_table/rte_table_acl.c | 2 +-
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
index 8b7e92c..d1f40be 100644
--- a/lib/librte_acl/rte_acl.c
+++ b/lib/librte_acl/rte_acl.c
@@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
 	if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
 			rd->category_mask) == 0 ||
 			rd->priority > RTE_ACL_MAX_PRIORITY ||
-			rd->priority < RTE_ACL_MIN_PRIORITY ||
-			rd->userdata == RTE_ACL_INVALID_USERDATA)
+			rd->priority < RTE_ACL_MIN_PRIORITY)
 		return -EINVAL;
 	return 0;
 }
diff --git a/lib/librte_acl/rte_acl.h b/lib/librte_acl/rte_acl.h
index caa91f7..b53179a 100644
--- a/lib/librte_acl/rte_acl.h
+++ b/lib/librte_acl/rte_acl.h
@@ -120,8 +120,6 @@ enum {
 	RTE_ACL_MIN_PRIORITY = 0,
 };
 
-#define	RTE_ACL_INVALID_USERDATA	0
-
 #define	RTE_ACL_MASKLEN_TO_BITMASK(v, s)	\
 ((v) == 0 ? (v) : (typeof(v))((uint64_t)-1 << ((s) * CHAR_BIT - (v))))
 
diff --git a/lib/librte_table/rte_table_acl.c b/lib/librte_table/rte_table_acl.c
index 8f1f8ce..94b69a9 100644
--- a/lib/librte_table/rte_table_acl.c
+++ b/lib/librte_table/rte_table_acl.c
@@ -792,7 +792,7 @@ rte_table_acl_lookup(
 
 		pkts_mask &= ~pkt_mask;
 
-		if (action_table_pos != RTE_ACL_INVALID_USERDATA) {
+		if (action_table_pos != 0) {
 			pkts_out_mask |= pkt_mask;
 			entries[pkt_pos] = (void *)
 				&acl->memory[action_table_pos *
-- 
2.10.2

Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict

[Ananyev, Konstantin]

Hi Michal,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> Sent: Tuesday, December 13, 2016 1:08 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> 
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> ---
>  lib/librte_acl/rte_acl.c         | 3 +--
>  lib/librte_acl/rte_acl.h         | 2 --
>  lib/librte_table/rte_table_acl.c | 2 +-
>  3 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> index 8b7e92c..d1f40be 100644
> --- a/lib/librte_acl/rte_acl.c
> +++ b/lib/librte_acl/rte_acl.c
> @@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
>  	if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
>  			rd->category_mask) == 0 ||
>  			rd->priority > RTE_ACL_MAX_PRIORITY ||
> -			rd->priority < RTE_ACL_MIN_PRIORITY ||
> -			rd->userdata == RTE_ACL_INVALID_USERDATA)
> +			rd->priority < RTE_ACL_MIN_PRIORITY)
>  		return -EINVAL;
>  	return 0;
>  }

I am not sure, how it supposed to work properly?
Zero value is reserved and ifnicates that no match were found for that input.
Konstantin


> diff --git a/lib/librte_acl/rte_acl.h b/lib/librte_acl/rte_acl.h
> index caa91f7..b53179a 100644
> --- a/lib/librte_acl/rte_acl.h
> +++ b/lib/librte_acl/rte_acl.h
> @@ -120,8 +120,6 @@ enum {
>  	RTE_ACL_MIN_PRIORITY = 0,
>  };
> 
> -#define	RTE_ACL_INVALID_USERDATA	0
> -
>  #define	RTE_ACL_MASKLEN_TO_BITMASK(v, s)	\
>  ((v) == 0 ? (v) : (typeof(v))((uint64_t)-1 << ((s) * CHAR_BIT - (v))))
> 
> diff --git a/lib/librte_table/rte_table_acl.c b/lib/librte_table/rte_table_acl.c
> index 8f1f8ce..94b69a9 100644
> --- a/lib/librte_table/rte_table_acl.c
> +++ b/lib/librte_table/rte_table_acl.c
> @@ -792,7 +792,7 @@ rte_table_acl_lookup(
> 
>  		pkts_mask &= ~pkt_mask;
> 
> -		if (action_table_pos != RTE_ACL_INVALID_USERDATA) {
> +		if (action_table_pos != 0) {
>  			pkts_out_mask |= pkt_mask;
>  			entries[pkt_pos] = (void *)
>  				&acl->memory[action_table_pos *
> --
> 2.10.2

Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict

[Michal Miroslaw]

On Tue, Dec 13, 2016 at 10:36:16AM +0000, Ananyev, Konstantin wrote:
> Hi Michal,
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > Sent: Tuesday, December 13, 2016 1:08 AM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > 
> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > ---
> >  lib/librte_acl/rte_acl.c         | 3 +--
> >  lib/librte_acl/rte_acl.h         | 2 --
> >  lib/librte_table/rte_table_acl.c | 2 +-
> >  3 files changed, 2 insertions(+), 5 deletions(-)
> > 
> > diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> > index 8b7e92c..d1f40be 100644
> > --- a/lib/librte_acl/rte_acl.c
> > +++ b/lib/librte_acl/rte_acl.c
> > @@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
> >  	if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
> >  			rd->category_mask) == 0 ||
> >  			rd->priority > RTE_ACL_MAX_PRIORITY ||
> > -			rd->priority < RTE_ACL_MIN_PRIORITY ||
> > -			rd->userdata == RTE_ACL_INVALID_USERDATA)
> > +			rd->priority < RTE_ACL_MIN_PRIORITY)
> >  		return -EINVAL;
> >  	return 0;
> >  }
> 
> I am not sure, how it supposed to work properly?
> Zero value is reserved and ifnicates that no match were found for that input.
 
This is actually in use by us. In our use we don't need to differentiate
matching a rule with zero verdict vs not matching a rule at all. I also
have a patch that changes the value returned in non-matching case, but
it's in "dirty hack" state, as of yet.

The ACL code does not treat zero userdata specially, so this is only
a policy choice and as such would be better to be made by the user.

Best Regards,
Michał Mirosław

Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict

[Ananyev, Konstantin]

> -----Original Message-----
> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> Sent: Tuesday, December 13, 2016 1:55 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> 
> On Tue, Dec 13, 2016 at 10:36:16AM +0000, Ananyev, Konstantin wrote:
> > Hi Michal,
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > > Sent: Tuesday, December 13, 2016 1:08 AM
> > > To: dev@dpdk.org
> > > Subject: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > >
> > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > ---
> > >  lib/librte_acl/rte_acl.c         | 3 +--
> > >  lib/librte_acl/rte_acl.h         | 2 --
> > >  lib/librte_table/rte_table_acl.c | 2 +-
> > >  3 files changed, 2 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> > > index 8b7e92c..d1f40be 100644
> > > --- a/lib/librte_acl/rte_acl.c
> > > +++ b/lib/librte_acl/rte_acl.c
> > > @@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
> > >  	if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
> > >  			rd->category_mask) == 0 ||
> > >  			rd->priority > RTE_ACL_MAX_PRIORITY ||
> > > -			rd->priority < RTE_ACL_MIN_PRIORITY ||
> > > -			rd->userdata == RTE_ACL_INVALID_USERDATA)
> > > +			rd->priority < RTE_ACL_MIN_PRIORITY)
> > >  		return -EINVAL;
> > >  	return 0;
> > >  }
> >
> > I am not sure, how it supposed to work properly?
> > Zero value is reserved and ifnicates that no match were found for that input.
> 
> This is actually in use by us. In our use we don't need to differentiate
> matching a rule with zero verdict vs not matching a rule at all. I also
> have a patch that changes the value returned in non-matching case, but
> it's in "dirty hack" state, as of yet.

With that chane rte_acl_classify() might produce invalid results.
Even if you don't need it (I still don't understand how) , it doesn't mean other people
don't  need it either and it is ok to change it.

> 
> The ACL code does not treat zero userdata specially, so this is only
> a policy choice and as such would be better to be made by the user.

I believe it does.
userdata==0 is a reserved value.
When rte_acl_clasify() returns 0 for that particular input, it means 'no matches were found'. 
Konstantin

Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict

[Michal Miroslaw]

On Tue, Dec 13, 2016 at 02:14:19PM +0000, Ananyev, Konstantin wrote:
> > -----Original Message-----
> > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > Sent: Tuesday, December 13, 2016 1:55 PM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > 
> > On Tue, Dec 13, 2016 at 10:36:16AM +0000, Ananyev, Konstantin wrote:
> > > Hi Michal,
> > >
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > > > Sent: Tuesday, December 13, 2016 1:08 AM
> > > > To: dev@dpdk.org
> > > > Subject: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > > >
> > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > > ---
> > > >  lib/librte_acl/rte_acl.c         | 3 +--
> > > >  lib/librte_acl/rte_acl.h         | 2 --
> > > >  lib/librte_table/rte_table_acl.c | 2 +-
> > > >  3 files changed, 2 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> > > > index 8b7e92c..d1f40be 100644
> > > > --- a/lib/librte_acl/rte_acl.c
> > > > +++ b/lib/librte_acl/rte_acl.c
> > > > @@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
> > > >  	if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
> > > >  			rd->category_mask) == 0 ||
> > > >  			rd->priority > RTE_ACL_MAX_PRIORITY ||
> > > > -			rd->priority < RTE_ACL_MIN_PRIORITY ||
> > > > -			rd->userdata == RTE_ACL_INVALID_USERDATA)
> > > > +			rd->priority < RTE_ACL_MIN_PRIORITY)
> > > >  		return -EINVAL;
> > > >  	return 0;
> > > >  }
> > >
> > > I am not sure, how it supposed to work properly?
> > > Zero value is reserved and ifnicates that no match were found for that input.
> > 
> > This is actually in use by us. In our use we don't need to differentiate
> > matching a rule with zero verdict vs not matching a rule at all. I also
> > have a patch that changes the value returned in non-matching case, but
> > it's in "dirty hack" state, as of yet.
> 
> With that chane rte_acl_classify() might produce invalid results.
> Even if you don't need it (I still don't understand how) , it doesn't mean other people
> don't  need it either and it is ok to change it.
> 
> > 
> > The ACL code does not treat zero userdata specially, so this is only
> > a policy choice and as such would be better to be made by the user.
> 
> I believe it does.
> userdata==0 is a reserved value.
> When rte_acl_clasify() returns 0 for that particular input, it means 'no matches were found'. 

Dear Konstantin,

Can you describe how the ACL code treats zero specially? I could not find
anything, really. The only thing I found is that iff I use zero userdata
in a rule I won't be able to differentiate a case where it matched from
a case where no rule matched. If I all my rules have non-zero userdata,
then this patch changes nothing. But if I have a table where 0 means drop
(default-drop policy) then being able to use zero userdata in DROP rules
makes the ACLs just that more useful.

Best Regards,
Michał Mirosław

Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict

[Ananyev, Konstantin]

> -----Original Message-----
> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> Sent: Tuesday, December 13, 2016 2:53 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> 
> On Tue, Dec 13, 2016 at 02:14:19PM +0000, Ananyev, Konstantin wrote:
> > > -----Original Message-----
> > > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > > Sent: Tuesday, December 13, 2016 1:55 PM
> > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > >
> > > On Tue, Dec 13, 2016 at 10:36:16AM +0000, Ananyev, Konstantin wrote:
> > > > Hi Michal,
> > > >
> > > > > -----Original Message-----
> > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > > > > Sent: Tuesday, December 13, 2016 1:08 AM
> > > > > To: dev@dpdk.org
> > > > > Subject: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > > > >
> > > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > > > ---
> > > > >  lib/librte_acl/rte_acl.c         | 3 +--
> > > > >  lib/librte_acl/rte_acl.h         | 2 --
> > > > >  lib/librte_table/rte_table_acl.c | 2 +-
> > > > >  3 files changed, 2 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> > > > > index 8b7e92c..d1f40be 100644
> > > > > --- a/lib/librte_acl/rte_acl.c
> > > > > +++ b/lib/librte_acl/rte_acl.c
> > > > > @@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
> > > > >  	if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
> > > > >  			rd->category_mask) == 0 ||
> > > > >  			rd->priority > RTE_ACL_MAX_PRIORITY ||
> > > > > -			rd->priority < RTE_ACL_MIN_PRIORITY ||
> > > > > -			rd->userdata == RTE_ACL_INVALID_USERDATA)
> > > > > +			rd->priority < RTE_ACL_MIN_PRIORITY)
> > > > >  		return -EINVAL;
> > > > >  	return 0;
> > > > >  }
> > > >
> > > > I am not sure, how it supposed to work properly?
> > > > Zero value is reserved and ifnicates that no match were found for that input.
> > >
> > > This is actually in use by us. In our use we don't need to differentiate
> > > matching a rule with zero verdict vs not matching a rule at all. I also
> > > have a patch that changes the value returned in non-matching case, but
> > > it's in "dirty hack" state, as of yet.
> >
> > With that chane rte_acl_classify() might produce invalid results.
> > Even if you don't need it (I still don't understand how) , it doesn't mean other people
> > don't  need it either and it is ok to change it.
> >
> > >
> > > The ACL code does not treat zero userdata specially, so this is only
> > > a policy choice and as such would be better to be made by the user.
> >
> > I believe it does.
> > userdata==0 is a reserved value.
> > When rte_acl_clasify() returns 0 for that particular input, it means 'no matches were found'.
> 
> Dear Konstantin,
> 
> Can you describe how the ACL code treats zero specially? I could not find
> anything, really. The only thing I found is that iff I use zero userdata
> in a rule I won't be able to differentiate a case where it matched from
> a case where no rule matched.

Yes, that's what I am talking about.

> If I all my rules have non-zero userdata,
> then this patch changes nothing.

Ok, then why do you remove a code that does checking for invalid userdata==0?
That supposed to prevent user to setup invalid value by mistake.

 But if I have a table where 0 means drop
> (default-drop policy) then being able to use zero userdata in DROP rules
> makes the ACLs just that more useful.

Ok, and what prevents you from do +1 to your policy values before
you insert it into the ACL table and -1 after you retrieved it via rte_acl_classify()? 
  
Konstantin

Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict

[Michal Miroslaw]

On Tue, Dec 13, 2016 at 03:13:42PM +0000, Ananyev, Konstantin wrote:
[...]
> > > > > > Subject: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > > > > >
> > > > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > > > > ---
> > > > > >  lib/librte_acl/rte_acl.c         | 3 +--
> > > > > >  lib/librte_acl/rte_acl.h         | 2 --
> > > > > >  lib/librte_table/rte_table_acl.c | 2 +-
> > > > > >  3 files changed, 2 insertions(+), 5 deletions(-)
> > > > > >
> > > > > > diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> > > > > > index 8b7e92c..d1f40be 100644
> > > > > > --- a/lib/librte_acl/rte_acl.c
> > > > > > +++ b/lib/librte_acl/rte_acl.c
> > > > > > @@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
> > > > > >  	if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
> > > > > >  			rd->category_mask) == 0 ||
> > > > > >  			rd->priority > RTE_ACL_MAX_PRIORITY ||
> > > > > > -			rd->priority < RTE_ACL_MIN_PRIORITY ||
> > > > > > -			rd->userdata == RTE_ACL_INVALID_USERDATA)
> > > > > > +			rd->priority < RTE_ACL_MIN_PRIORITY)
> > > > > >  		return -EINVAL;
> > > > > >  	return 0;
> > > > > >  }
> > > > >
> > > > > I am not sure, how it supposed to work properly?
> > > > > Zero value is reserved and ifnicates that no match were found for that input.
> > > >
> > > > This is actually in use by us. In our use we don't need to differentiate
> > > > matching a rule with zero verdict vs not matching a rule at all. I also
> > > > have a patch that changes the value returned in non-matching case, but
> > > > it's in "dirty hack" state, as of yet.
> > >
> > > With that chane rte_acl_classify() might produce invalid results.
> > > Even if you don't need it (I still don't understand how) , it doesn't mean other people
> > > don't  need it either and it is ok to change it.
> > >
> > > >
> > > > The ACL code does not treat zero userdata specially, so this is only
> > > > a policy choice and as such would be better to be made by the user.
> > >
> > > I believe it does.
> > > userdata==0 is a reserved value.
> > > When rte_acl_clasify() returns 0 for that particular input, it means 'no matches were found'.
> > 
> > Dear Konstantin,
> > 
> > Can you describe how the ACL code treats zero specially? I could not find
> > anything, really. The only thing I found is that iff I use zero userdata
> > in a rule I won't be able to differentiate a case where it matched from
> > a case where no rule matched.
> 
> Yes, that's what I am talking about.
> 
> > If I all my rules have non-zero userdata,
> > then this patch changes nothing.
> 
> Ok, then why do you remove a code that does checking for invalid userdata==0?
> That supposed to prevent user to setup invalid value by mistake.
> 
>  But if I have a table where 0 means drop
> > (default-drop policy) then being able to use zero userdata in DROP rules
> > makes the ACLs just that more useful.
> 
> Ok, and what prevents you from do +1 to your policy values before
> you insert it into the ACL table and -1 after you retrieved it via rte_acl_classify()? 

The check is enforcing an assumption that all users want to distinguish
the cases whether any rule matched and whether no rules matched. Not all
users do, hence the assumption is invalid and this patch removes it.

Yes, people can work around it by loosing 1 of 2^32 useful values and
convoluting their code.

You seem to argue that 0 is somehow an invalid value, but I can't find
anything in the ACL that would require it to be so. Could you point me
to the code in DPDK where this actually matters?

Best Regards,
Michał Mirosław

Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict

[Michal Miroslaw]

On Tue, Dec 13, 2016 at 05:14:09PM +0100, Michal Miroslaw wrote:
> On Tue, Dec 13, 2016 at 03:13:42PM +0000, Ananyev, Konstantin wrote:
[...]
> > > Dear Konstantin,
> > > 
> > > Can you describe how the ACL code treats zero specially? I could not find
> > > anything, really. The only thing I found is that iff I use zero userdata
> > > in a rule I won't be able to differentiate a case where it matched from
> > > a case where no rule matched.
> > 
> > Yes, that's what I am talking about.
> > 
> > > If I all my rules have non-zero userdata,
> > > then this patch changes nothing.
> > 
> > Ok, then why do you remove a code that does checking for invalid userdata==0?
> > That supposed to prevent user to setup invalid value by mistake.
> > 
> >  But if I have a table where 0 means drop
> > > (default-drop policy) then being able to use zero userdata in DROP rules
> > > makes the ACLs just that more useful.
> > 
> > Ok, and what prevents you from do +1 to your policy values before
> > you insert it into the ACL table and -1 after you retrieved it via rte_acl_classify()? 
> 
> The check is enforcing an assumption that all users want to distinguish
> the cases whether any rule matched and whether no rules matched. Not all
> users do, hence the assumption is invalid and this patch removes it.
> 
> Yes, people can work around it by loosing 1 of 2^32 useful values and
> convoluting their code.
> 
> You seem to argue that 0 is somehow an invalid value, but I can't find
> anything in the ACL that would require it to be so. Could you point me
> to the code in DPDK where this actually matters?

I just noticed that it's probably you who wrote most of the ACLs code,
so I guest you're the right person to ask the question above.

Nice work, BTW. :-)

Best Regards,
Michał Mirosław

Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict

[Ananyev, Konstantin]

> -----Original Message-----
> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> Sent: Tuesday, December 13, 2016 4:14 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> 
> On Tue, Dec 13, 2016 at 03:13:42PM +0000, Ananyev, Konstantin wrote:
> [...]
> > > > > > > Subject: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > > > > > >
> > > > > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > > > > > ---
> > > > > > >  lib/librte_acl/rte_acl.c         | 3 +--
> > > > > > >  lib/librte_acl/rte_acl.h         | 2 --
> > > > > > >  lib/librte_table/rte_table_acl.c | 2 +-
> > > > > > >  3 files changed, 2 insertions(+), 5 deletions(-)
> > > > > > >
> > > > > > > diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> > > > > > > index 8b7e92c..d1f40be 100644
> > > > > > > --- a/lib/librte_acl/rte_acl.c
> > > > > > > +++ b/lib/librte_acl/rte_acl.c
> > > > > > > @@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
> > > > > > >  	if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
> > > > > > >  			rd->category_mask) == 0 ||
> > > > > > >  			rd->priority > RTE_ACL_MAX_PRIORITY ||
> > > > > > > -			rd->priority < RTE_ACL_MIN_PRIORITY ||
> > > > > > > -			rd->userdata == RTE_ACL_INVALID_USERDATA)
> > > > > > > +			rd->priority < RTE_ACL_MIN_PRIORITY)
> > > > > > >  		return -EINVAL;
> > > > > > >  	return 0;
> > > > > > >  }
> > > > > >
> > > > > > I am not sure, how it supposed to work properly?
> > > > > > Zero value is reserved and ifnicates that no match were found for that input.
> > > > >
> > > > > This is actually in use by us. In our use we don't need to differentiate
> > > > > matching a rule with zero verdict vs not matching a rule at all. I also
> > > > > have a patch that changes the value returned in non-matching case, but
> > > > > it's in "dirty hack" state, as of yet.
> > > >
> > > > With that chane rte_acl_classify() might produce invalid results.
> > > > Even if you don't need it (I still don't understand how) , it doesn't mean other people
> > > > don't  need it either and it is ok to change it.
> > > >
> > > > >
> > > > > The ACL code does not treat zero userdata specially, so this is only
> > > > > a policy choice and as such would be better to be made by the user.
> > > >
> > > > I believe it does.
> > > > userdata==0 is a reserved value.
> > > > When rte_acl_clasify() returns 0 for that particular input, it means 'no matches were found'.
> > >
> > > Dear Konstantin,
> > >
> > > Can you describe how the ACL code treats zero specially? I could not find
> > > anything, really. The only thing I found is that iff I use zero userdata
> > > in a rule I won't be able to differentiate a case where it matched from
> > > a case where no rule matched.
> >
> > Yes, that's what I am talking about.
> >
> > > If I all my rules have non-zero userdata,
> > > then this patch changes nothing.
> >
> > Ok, then why do you remove a code that does checking for invalid userdata==0?
> > That supposed to prevent user to setup invalid value by mistake.
> >
> >  But if I have a table where 0 means drop
> > > (default-drop policy) then being able to use zero userdata in DROP rules
> > > makes the ACLs just that more useful.
> >
> > Ok, and what prevents you from do +1 to your policy values before
> > you insert it into the ACL table and -1 after you retrieved it via rte_acl_classify()?
> 
> The check is enforcing an assumption that all users want to distinguish
> the cases whether any rule matched and whether no rules matched. Not all
> users do, hence the assumption is invalid and this patch removes it.

The check is based on the assumption that users might need to distinguish
the situation when no rules were matched.
To support that we need a reserved userdata value, which would mean
NO_MATCH.
>From what I heard, most users do need this ability, those who don't
can easily overcome it.
> 
> Yes, people can work around it by loosing 1 of 2^32 useful values and
> convoluting their code.

Yes, one of 2^32 values is reserved.
Any reason why (2^32 - 1) values might not be enough?

> 
> You seem to argue that 0 is somehow an invalid value, but I can't find
> anything in the ACL that would require it to be so. Could you point me
> to the code in DPDK where this actually matters?

It was a while, when I looked into ACL code in details, but as remember
that's the only reason: we need some value to be reserved as NO_MATCH.
Let say in build_trie() we set results to zero for rules with unused categories:
for (m = context->cfg.num_categories; 0 != m--; ) {
                        if (rule->f->data.category_mask & (1 << m)) {
                                end->mrt->results[m] = rule->f->data.userdata;
                                end->mrt->priority[m] = rule->f->data.priority;
                        } else {
                                end->mrt->results[m] = 0;
                                end->mrt->priority[m] = 0;
                        }
                }

Konstantin

Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict

[Michal Miroslaw]

On Tue, Dec 13, 2016 at 05:27:31PM +0000, Ananyev, Konstantin wrote:
> 
> 
> > -----Original Message-----
> > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > Sent: Tuesday, December 13, 2016 4:14 PM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > 
> > On Tue, Dec 13, 2016 at 03:13:42PM +0000, Ananyev, Konstantin wrote:
> > [...]
> > > > > > > > Subject: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > > > > > > >
> > > > > > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > > > > > > ---
> > > > > > > >  lib/librte_acl/rte_acl.c         | 3 +--
> > > > > > > >  lib/librte_acl/rte_acl.h         | 2 --
> > > > > > > >  lib/librte_table/rte_table_acl.c | 2 +-
> > > > > > > >  3 files changed, 2 insertions(+), 5 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> > > > > > > > index 8b7e92c..d1f40be 100644
> > > > > > > > --- a/lib/librte_acl/rte_acl.c
> > > > > > > > +++ b/lib/librte_acl/rte_acl.c
> > > > > > > > @@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
> > > > > > > >  	if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
> > > > > > > >  			rd->category_mask) == 0 ||
> > > > > > > >  			rd->priority > RTE_ACL_MAX_PRIORITY ||
> > > > > > > > -			rd->priority < RTE_ACL_MIN_PRIORITY ||
> > > > > > > > -			rd->userdata == RTE_ACL_INVALID_USERDATA)
> > > > > > > > +			rd->priority < RTE_ACL_MIN_PRIORITY)
> > > > > > > >  		return -EINVAL;
> > > > > > > >  	return 0;
> > > > > > > >  }
> > > > > > >
> > > > > > > I am not sure, how it supposed to work properly?
> > > > > > > Zero value is reserved and ifnicates that no match were found for that input.
> > > > > >
> > > > > > This is actually in use by us. In our use we don't need to differentiate
> > > > > > matching a rule with zero verdict vs not matching a rule at all. I also
> > > > > > have a patch that changes the value returned in non-matching case, but
> > > > > > it's in "dirty hack" state, as of yet.
> > > > >
> > > > > With that chane rte_acl_classify() might produce invalid results.
> > > > > Even if you don't need it (I still don't understand how) , it doesn't mean other people
> > > > > don't  need it either and it is ok to change it.
> > > > >
> > > > > >
> > > > > > The ACL code does not treat zero userdata specially, so this is only
> > > > > > a policy choice and as such would be better to be made by the user.
> > > > >
> > > > > I believe it does.
> > > > > userdata==0 is a reserved value.
> > > > > When rte_acl_clasify() returns 0 for that particular input, it means 'no matches were found'.
> > > >
> > > > Dear Konstantin,
> > > >
> > > > Can you describe how the ACL code treats zero specially? I could not find
> > > > anything, really. The only thing I found is that iff I use zero userdata
> > > > in a rule I won't be able to differentiate a case where it matched from
> > > > a case where no rule matched.
> > >
> > > Yes, that's what I am talking about.
> > >
> > > > If I all my rules have non-zero userdata,
> > > > then this patch changes nothing.
> > >
> > > Ok, then why do you remove a code that does checking for invalid userdata==0?
> > > That supposed to prevent user to setup invalid value by mistake.
> > >
> > >  But if I have a table where 0 means drop
> > > > (default-drop policy) then being able to use zero userdata in DROP rules
> > > > makes the ACLs just that more useful.
> > >
> > > Ok, and what prevents you from do +1 to your policy values before
> > > you insert it into the ACL table and -1 after you retrieved it via rte_acl_classify()?
> > 
> > The check is enforcing an assumption that all users want to distinguish
> > the cases whether any rule matched and whether no rules matched. Not all
> > users do, hence the assumption is invalid and this patch removes it.
> 
> The check is based on the assumption that users might need to distinguish
> the situation when no rules were matched.
> To support that we need a reserved userdata value, which would mean
> NO_MATCH.
> From what I heard, most users do need this ability, those who don't
> can easily overcome it.

That's actually my point. Some users need the distinction, so they don't use
zero userdata in their rules and have their work done. Some users don't need
it and would prefer to just use the convenience of zero being no-match signal
to insert "non-matching" rules (now they have to check two values for the
same signal).

> > Yes, people can work around it by loosing 1 of 2^32 useful values and
> > convoluting their code.
> Yes, one of 2^32 values is reserved.
> Any reason why (2^32 - 1) values might not be enough?

Sure. We're using userdata as a bitmask of actions to take on the packet,
and because of this restriction we're loosing half of the userdata field.
If we would add this "decrement if non-zero" workaround this would keep
biting us on every occasion where we touch the ACL verdict code.

> > You seem to argue that 0 is somehow an invalid value, but I can't find
> > anything in the ACL that would require it to be so. Could you point me
> > to the code in DPDK where this actually matters?
> 
> It was a while, when I looked into ACL code in details, but as remember
> that's the only reason: we need some value to be reserved as NO_MATCH.
> Let say in build_trie() we set results to zero for rules with unused categories:
> for (m = context->cfg.num_categories; 0 != m--; ) {
>                         if (rule->f->data.category_mask & (1 << m)) {
>                                 end->mrt->results[m] = rule->f->data.userdata;
>                                 end->mrt->priority[m] = rule->f->data.priority;
>                         } else {
>                                 end->mrt->results[m] = 0;
>                                 end->mrt->priority[m] = 0;
>                         }
>                 }

So, if I understand correctly, 0 is a default value for category result.
Any matching rule with priority >= 0 will override it (leaving last highest
priority rule's userdata). This will just work the same for anyone needing
the distinction (when he doesn't use userdata == 0) and also for those who
don't -- when the restriction is removed.

I think that it comes to documenting the behaviour and let users choose
their way. At the beginning I haven't found any mention of the restriction
in the docs, so I had to spend a fair amount of time to find out why the
zero is so special (it wasn't).

Best Regards,
Michał Mirosław

Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict

[Ananyev, Konstantin]

> -----Original Message-----
> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> Sent: Tuesday, December 13, 2016 6:03 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> 
> On Tue, Dec 13, 2016 at 05:27:31PM +0000, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > > Sent: Tuesday, December 13, 2016 4:14 PM
> > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > >
> > > On Tue, Dec 13, 2016 at 03:13:42PM +0000, Ananyev, Konstantin wrote:
> > > [...]
> > > > > > > > > Subject: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > > > > > > > >
> > > > > > > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > > > > > > > ---
> > > > > > > > >  lib/librte_acl/rte_acl.c         | 3 +--
> > > > > > > > >  lib/librte_acl/rte_acl.h         | 2 --
> > > > > > > > >  lib/librte_table/rte_table_acl.c | 2 +-
> > > > > > > > >  3 files changed, 2 insertions(+), 5 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> > > > > > > > > index 8b7e92c..d1f40be 100644
> > > > > > > > > --- a/lib/librte_acl/rte_acl.c
> > > > > > > > > +++ b/lib/librte_acl/rte_acl.c
> > > > > > > > > @@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
> > > > > > > > >  	if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
> > > > > > > > >  			rd->category_mask) == 0 ||
> > > > > > > > >  			rd->priority > RTE_ACL_MAX_PRIORITY ||
> > > > > > > > > -			rd->priority < RTE_ACL_MIN_PRIORITY ||
> > > > > > > > > -			rd->userdata == RTE_ACL_INVALID_USERDATA)
> > > > > > > > > +			rd->priority < RTE_ACL_MIN_PRIORITY)
> > > > > > > > >  		return -EINVAL;
> > > > > > > > >  	return 0;
> > > > > > > > >  }
> > > > > > > >
> > > > > > > > I am not sure, how it supposed to work properly?
> > > > > > > > Zero value is reserved and ifnicates that no match were found for that input.
> > > > > > >
> > > > > > > This is actually in use by us. In our use we don't need to differentiate
> > > > > > > matching a rule with zero verdict vs not matching a rule at all. I also
> > > > > > > have a patch that changes the value returned in non-matching case, but
> > > > > > > it's in "dirty hack" state, as of yet.
> > > > > >
> > > > > > With that chane rte_acl_classify() might produce invalid results.
> > > > > > Even if you don't need it (I still don't understand how) , it doesn't mean other people
> > > > > > don't  need it either and it is ok to change it.
> > > > > >
> > > > > > >
> > > > > > > The ACL code does not treat zero userdata specially, so this is only
> > > > > > > a policy choice and as such would be better to be made by the user.
> > > > > >
> > > > > > I believe it does.
> > > > > > userdata==0 is a reserved value.
> > > > > > When rte_acl_clasify() returns 0 for that particular input, it means 'no matches were found'.
> > > > >
> > > > > Dear Konstantin,
> > > > >
> > > > > Can you describe how the ACL code treats zero specially? I could not find
> > > > > anything, really. The only thing I found is that iff I use zero userdata
> > > > > in a rule I won't be able to differentiate a case where it matched from
> > > > > a case where no rule matched.
> > > >
> > > > Yes, that's what I am talking about.
> > > >
> > > > > If I all my rules have non-zero userdata,
> > > > > then this patch changes nothing.
> > > >
> > > > Ok, then why do you remove a code that does checking for invalid userdata==0?
> > > > That supposed to prevent user to setup invalid value by mistake.
> > > >
> > > >  But if I have a table where 0 means drop
> > > > > (default-drop policy) then being able to use zero userdata in DROP rules
> > > > > makes the ACLs just that more useful.
> > > >
> > > > Ok, and what prevents you from do +1 to your policy values before
> > > > you insert it into the ACL table and -1 after you retrieved it via rte_acl_classify()?
> > >
> > > The check is enforcing an assumption that all users want to distinguish
> > > the cases whether any rule matched and whether no rules matched. Not all
> > > users do, hence the assumption is invalid and this patch removes it.
> >
> > The check is based on the assumption that users might need to distinguish
> > the situation when no rules were matched.
> > To support that we need a reserved userdata value, which would mean
> > NO_MATCH.
> > From what I heard, most users do need this ability, those who don't
> > can easily overcome it.
> 
> That's actually my point. Some users need the distinction, so they don't use
> zero userdata in their rules and have their work done. Some users don't need
> it and would prefer to just use the convenience of zero being no-match signal
> to insert "non-matching" rules (now they have to check two values for the
> same signal).
> 
> > > Yes, people can work around it by loosing 1 of 2^32 useful values and
> > > convoluting their code.
> > Yes, one of 2^32 values is reserved.
> > Any reason why (2^32 - 1) values might not be enough?
> 
> Sure. We're using userdata as a bitmask of actions to take on the packet,
> and because of this restriction we're loosing half of the userdata field.
> If we would add this "decrement if non-zero" workaround this would keep
> biting us on every occasion where we touch the ACL verdict code.
> 
> > > You seem to argue that 0 is somehow an invalid value, but I can't find
> > > anything in the ACL that would require it to be so. Could you point me
> > > to the code in DPDK where this actually matters?
> >
> > It was a while, when I looked into ACL code in details, but as remember
> > that's the only reason: we need some value to be reserved as NO_MATCH.
> > Let say in build_trie() we set results to zero for rules with unused categories:
> > for (m = context->cfg.num_categories; 0 != m--; ) {
> >                         if (rule->f->data.category_mask & (1 << m)) {
> >                                 end->mrt->results[m] = rule->f->data.userdata;
> >                                 end->mrt->priority[m] = rule->f->data.priority;
> >                         } else {
> >                                 end->mrt->results[m] = 0;
> >                                 end->mrt->priority[m] = 0;
> >                         }
> >                 }
> 
> So, if I understand correctly, 0 is a default value for category result.
> Any matching rule with priority >= 0 will override it (leaving last highest
> priority rule's userdata). This will just work the same for anyone needing
> the distinction (when he doesn't use userdata == 0) and also for those who
> don't -- when the restriction is removed.
> 
> I think that it comes to documenting the behaviour and let users choose
> their way. At the beginning I haven't found any mention of the restriction
> in the docs, so I had to spend a fair amount of time to find out why the
> zero is so special (it wasn't).

Ok, so you suggest the following:
1. Zero value for both userdata and results still has a special meaning: NO_MATCH.
2. Allow user to create a rule(s) that would on hit return NO_MATCH for it,
as if no rule was matched by that input (i.e. rule's userdata==0).
Is my understanding correct?
Konstantin
 



  

Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict

[Michal Miroslaw]

On Tue, Dec 13, 2016 at 09:55:12PM +0000, Ananyev, Konstantin wrote:
> 
> 
> > -----Original Message-----
> > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > Sent: Tuesday, December 13, 2016 6:03 PM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > 
> > On Tue, Dec 13, 2016 at 05:27:31PM +0000, Ananyev, Konstantin wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > > > Sent: Tuesday, December 13, 2016 4:14 PM
> > > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > > Cc: dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > > >
> > > > On Tue, Dec 13, 2016 at 03:13:42PM +0000, Ananyev, Konstantin wrote:
> > > > [...]
> > > > > > > > > > Subject: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > > > > > > > > ---
> > > > > > > > > >  lib/librte_acl/rte_acl.c         | 3 +--
> > > > > > > > > >  lib/librte_acl/rte_acl.h         | 2 --
> > > > > > > > > >  lib/librte_table/rte_table_acl.c | 2 +-
> > > > > > > > > >  3 files changed, 2 insertions(+), 5 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> > > > > > > > > > index 8b7e92c..d1f40be 100644
> > > > > > > > > > --- a/lib/librte_acl/rte_acl.c
> > > > > > > > > > +++ b/lib/librte_acl/rte_acl.c
> > > > > > > > > > @@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
> > > > > > > > > >  	if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
> > > > > > > > > >  			rd->category_mask) == 0 ||
> > > > > > > > > >  			rd->priority > RTE_ACL_MAX_PRIORITY ||
> > > > > > > > > > -			rd->priority < RTE_ACL_MIN_PRIORITY ||
> > > > > > > > > > -			rd->userdata == RTE_ACL_INVALID_USERDATA)
> > > > > > > > > > +			rd->priority < RTE_ACL_MIN_PRIORITY)
> > > > > > > > > >  		return -EINVAL;
> > > > > > > > > >  	return 0;
> > > > > > > > > >  }
> > > > > > > > >
> > > > > > > > > I am not sure, how it supposed to work properly?
> > > > > > > > > Zero value is reserved and ifnicates that no match were found for that input.
> > > > > > > >
> > > > > > > > This is actually in use by us. In our use we don't need to differentiate
> > > > > > > > matching a rule with zero verdict vs not matching a rule at all. I also
> > > > > > > > have a patch that changes the value returned in non-matching case, but
> > > > > > > > it's in "dirty hack" state, as of yet.
> > > > > > >
> > > > > > > With that chane rte_acl_classify() might produce invalid results.
> > > > > > > Even if you don't need it (I still don't understand how) , it doesn't mean other people
> > > > > > > don't  need it either and it is ok to change it.
> > > > > > >
> > > > > > > >
> > > > > > > > The ACL code does not treat zero userdata specially, so this is only
> > > > > > > > a policy choice and as such would be better to be made by the user.
> > > > > > >
> > > > > > > I believe it does.
> > > > > > > userdata==0 is a reserved value.
> > > > > > > When rte_acl_clasify() returns 0 for that particular input, it means 'no matches were found'.
> > > > > >
> > > > > > Dear Konstantin,
> > > > > >
> > > > > > Can you describe how the ACL code treats zero specially? I could not find
> > > > > > anything, really. The only thing I found is that iff I use zero userdata
> > > > > > in a rule I won't be able to differentiate a case where it matched from
> > > > > > a case where no rule matched.
> > > > >
> > > > > Yes, that's what I am talking about.
> > > > >
> > > > > > If I all my rules have non-zero userdata,
> > > > > > then this patch changes nothing.
> > > > >
> > > > > Ok, then why do you remove a code that does checking for invalid userdata==0?
> > > > > That supposed to prevent user to setup invalid value by mistake.
> > > > >
> > > > >  But if I have a table where 0 means drop
> > > > > > (default-drop policy) then being able to use zero userdata in DROP rules
> > > > > > makes the ACLs just that more useful.
> > > > >
> > > > > Ok, and what prevents you from do +1 to your policy values before
> > > > > you insert it into the ACL table and -1 after you retrieved it via rte_acl_classify()?
> > > >
> > > > The check is enforcing an assumption that all users want to distinguish
> > > > the cases whether any rule matched and whether no rules matched. Not all
> > > > users do, hence the assumption is invalid and this patch removes it.
> > >
> > > The check is based on the assumption that users might need to distinguish
> > > the situation when no rules were matched.
> > > To support that we need a reserved userdata value, which would mean
> > > NO_MATCH.
> > > From what I heard, most users do need this ability, those who don't
> > > can easily overcome it.
> > 
> > That's actually my point. Some users need the distinction, so they don't use
> > zero userdata in their rules and have their work done. Some users don't need
> > it and would prefer to just use the convenience of zero being no-match signal
> > to insert "non-matching" rules (now they have to check two values for the
> > same signal).
> > 
> > > > Yes, people can work around it by loosing 1 of 2^32 useful values and
> > > > convoluting their code.
> > > Yes, one of 2^32 values is reserved.
> > > Any reason why (2^32 - 1) values might not be enough?
> > 
> > Sure. We're using userdata as a bitmask of actions to take on the packet,
> > and because of this restriction we're loosing half of the userdata field.
> > If we would add this "decrement if non-zero" workaround this would keep
> > biting us on every occasion where we touch the ACL verdict code.
> > 
> > > > You seem to argue that 0 is somehow an invalid value, but I can't find
> > > > anything in the ACL that would require it to be so. Could you point me
> > > > to the code in DPDK where this actually matters?
> > >
> > > It was a while, when I looked into ACL code in details, but as remember
> > > that's the only reason: we need some value to be reserved as NO_MATCH.
> > > Let say in build_trie() we set results to zero for rules with unused categories:
> > > for (m = context->cfg.num_categories; 0 != m--; ) {
> > >                         if (rule->f->data.category_mask & (1 << m)) {
> > >                                 end->mrt->results[m] = rule->f->data.userdata;
> > >                                 end->mrt->priority[m] = rule->f->data.priority;
> > >                         } else {
> > >                                 end->mrt->results[m] = 0;
> > >                                 end->mrt->priority[m] = 0;
> > >                         }
> > >                 }
> > 
> > So, if I understand correctly, 0 is a default value for category result.
> > Any matching rule with priority >= 0 will override it (leaving last highest
> > priority rule's userdata). This will just work the same for anyone needing
> > the distinction (when he doesn't use userdata == 0) and also for those who
> > don't -- when the restriction is removed.
> > 
> > I think that it comes to documenting the behaviour and let users choose
> > their way. At the beginning I haven't found any mention of the restriction
> > in the docs, so I had to spend a fair amount of time to find out why the
> > zero is so special (it wasn't).
> 
> Ok, so you suggest the following:
> 1. Zero value for both userdata and results still has a special meaning: NO_MATCH.
> 2. Allow user to create a rule(s) that would on hit return NO_MATCH for it,
> as if no rule was matched by that input (i.e. rule's userdata==0).
> Is my understanding correct?

That is exactly it.

Best Regards,
Michał Mirosław

Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict

[Ananyev, Konstantin]

Hi Michal,

> -----Original Message-----
> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> Sent: Wednesday, December 14, 2016 2:11 AM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> 
> On Tue, Dec 13, 2016 at 09:55:12PM +0000, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > > Sent: Tuesday, December 13, 2016 6:03 PM
> > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > >
> > > On Tue, Dec 13, 2016 at 05:27:31PM +0000, Ananyev, Konstantin wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > > > > Sent: Tuesday, December 13, 2016 4:14 PM
> > > > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > > > Cc: dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > > > >
> > > > > On Tue, Dec 13, 2016 at 03:13:42PM +0000, Ananyev, Konstantin wrote:
> > > > > [...]
> > > > > > > > > > > Subject: [dpdk-dev] [PATCH 04/13] acl: allow zero verdict
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > > > > > > > > > ---
> > > > > > > > > > >  lib/librte_acl/rte_acl.c         | 3 +--
> > > > > > > > > > >  lib/librte_acl/rte_acl.h         | 2 --
> > > > > > > > > > >  lib/librte_table/rte_table_acl.c | 2 +-
> > > > > > > > > > >  3 files changed, 2 insertions(+), 5 deletions(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> > > > > > > > > > > index 8b7e92c..d1f40be 100644
> > > > > > > > > > > --- a/lib/librte_acl/rte_acl.c
> > > > > > > > > > > +++ b/lib/librte_acl/rte_acl.c
> > > > > > > > > > > @@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
> > > > > > > > > > >  	if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
> > > > > > > > > > >  			rd->category_mask) == 0 ||
> > > > > > > > > > >  			rd->priority > RTE_ACL_MAX_PRIORITY ||
> > > > > > > > > > > -			rd->priority < RTE_ACL_MIN_PRIORITY ||
> > > > > > > > > > > -			rd->userdata == RTE_ACL_INVALID_USERDATA)
> > > > > > > > > > > +			rd->priority < RTE_ACL_MIN_PRIORITY)
> > > > > > > > > > >  		return -EINVAL;
> > > > > > > > > > >  	return 0;
> > > > > > > > > > >  }
> > > > > > > > > >
> > > > > > > > > > I am not sure, how it supposed to work properly?
> > > > > > > > > > Zero value is reserved and ifnicates that no match were found for that input.
> > > > > > > > >
> > > > > > > > > This is actually in use by us. In our use we don't need to differentiate
> > > > > > > > > matching a rule with zero verdict vs not matching a rule at all. I also
> > > > > > > > > have a patch that changes the value returned in non-matching case, but
> > > > > > > > > it's in "dirty hack" state, as of yet.
> > > > > > > >
> > > > > > > > With that chane rte_acl_classify() might produce invalid results.
> > > > > > > > Even if you don't need it (I still don't understand how) , it doesn't mean other people
> > > > > > > > don't  need it either and it is ok to change it.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > The ACL code does not treat zero userdata specially, so this is only
> > > > > > > > > a policy choice and as such would be better to be made by the user.
> > > > > > > >
> > > > > > > > I believe it does.
> > > > > > > > userdata==0 is a reserved value.
> > > > > > > > When rte_acl_clasify() returns 0 for that particular input, it means 'no matches were found'.
> > > > > > >
> > > > > > > Dear Konstantin,
> > > > > > >
> > > > > > > Can you describe how the ACL code treats zero specially? I could not find
> > > > > > > anything, really. The only thing I found is that iff I use zero userdata
> > > > > > > in a rule I won't be able to differentiate a case where it matched from
> > > > > > > a case where no rule matched.
> > > > > >
> > > > > > Yes, that's what I am talking about.
> > > > > >
> > > > > > > If I all my rules have non-zero userdata,
> > > > > > > then this patch changes nothing.
> > > > > >
> > > > > > Ok, then why do you remove a code that does checking for invalid userdata==0?
> > > > > > That supposed to prevent user to setup invalid value by mistake.
> > > > > >
> > > > > >  But if I have a table where 0 means drop
> > > > > > > (default-drop policy) then being able to use zero userdata in DROP rules
> > > > > > > makes the ACLs just that more useful.
> > > > > >
> > > > > > Ok, and what prevents you from do +1 to your policy values before
> > > > > > you insert it into the ACL table and -1 after you retrieved it via rte_acl_classify()?
> > > > >
> > > > > The check is enforcing an assumption that all users want to distinguish
> > > > > the cases whether any rule matched and whether no rules matched. Not all
> > > > > users do, hence the assumption is invalid and this patch removes it.
> > > >
> > > > The check is based on the assumption that users might need to distinguish
> > > > the situation when no rules were matched.
> > > > To support that we need a reserved userdata value, which would mean
> > > > NO_MATCH.
> > > > From what I heard, most users do need this ability, those who don't
> > > > can easily overcome it.
> > >
> > > That's actually my point. Some users need the distinction, so they don't use
> > > zero userdata in their rules and have their work done. Some users don't need
> > > it and would prefer to just use the convenience of zero being no-match signal
> > > to insert "non-matching" rules (now they have to check two values for the
> > > same signal).
> > >
> > > > > Yes, people can work around it by loosing 1 of 2^32 useful values and
> > > > > convoluting their code.
> > > > Yes, one of 2^32 values is reserved.
> > > > Any reason why (2^32 - 1) values might not be enough?
> > >
> > > Sure. We're using userdata as a bitmask of actions to take on the packet,
> > > and because of this restriction we're loosing half of the userdata field.
> > > If we would add this "decrement if non-zero" workaround this would keep
> > > biting us on every occasion where we touch the ACL verdict code.
> > >
> > > > > You seem to argue that 0 is somehow an invalid value, but I can't find
> > > > > anything in the ACL that would require it to be so. Could you point me
> > > > > to the code in DPDK where this actually matters?
> > > >
> > > > It was a while, when I looked into ACL code in details, but as remember
> > > > that's the only reason: we need some value to be reserved as NO_MATCH.
> > > > Let say in build_trie() we set results to zero for rules with unused categories:
> > > > for (m = context->cfg.num_categories; 0 != m--; ) {
> > > >                         if (rule->f->data.category_mask & (1 << m)) {
> > > >                                 end->mrt->results[m] = rule->f->data.userdata;
> > > >                                 end->mrt->priority[m] = rule->f->data.priority;
> > > >                         } else {
> > > >                                 end->mrt->results[m] = 0;
> > > >                                 end->mrt->priority[m] = 0;
> > > >                         }
> > > >                 }
> > >
> > > So, if I understand correctly, 0 is a default value for category result.
> > > Any matching rule with priority >= 0 will override it (leaving last highest
> > > priority rule's userdata). This will just work the same for anyone needing
> > > the distinction (when he doesn't use userdata == 0) and also for those who
> > > don't -- when the restriction is removed.
> > >
> > > I think that it comes to documenting the behaviour and let users choose
> > > their way. At the beginning I haven't found any mention of the restriction
> > > in the docs, so I had to spend a fair amount of time to find out why the
> > > zero is so special (it wasn't).
> >
> > Ok, so you suggest the following:
> > 1. Zero value for both userdata and results still has a special meaning: NO_MATCH.
> > 2. Allow user to create a rule(s) that would on hit return NO_MATCH for it,
> > as if no rule was matched by that input (i.e. rule's userdata==0).
> > Is my understanding correct?
> 
> That is exactly it.

Ok, the idea still seems a bit unusual to me, but I suppose might be useful for some cases.
Again, can't think up a scenario when it would break something.
So don't have any good reason to object :)
Before we proceed with it can I ask you for two things: 
- Verify that autotest_acl works as expected.
- Update PG: http://dpdk.org/doc/guides/prog_guide/packet_classif_access_ctrl.html#rule-definition
I think these lines need to be repharsed because of that patch:
"userdata: A user-defined field that could be any value except zero."

Konstantin

[dpdk-dev] [PATCH 08/13] PMD/af_packet: guard against buffer overruns in RX path

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 drivers/net/af_packet/rte_eth_af_packet.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/af_packet/rte_eth_af_packet.c b/drivers/net/af_packet/rte_eth_af_packet.c
index ff45068..b1005c6 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -370,18 +370,18 @@ eth_rx_queue_setup(struct rte_eth_dev *dev,
 {
 	struct pmd_internals *internals = dev->data->dev_private;
 	struct pkt_rx_queue *pkt_q = &internals->rx_queue[rx_queue_id];
-	uint16_t buf_size;
+	unsigned buf_size, data_size;
 
 	pkt_q->mb_pool = mb_pool;
 
 	/* Now get the space available for data in the mbuf */
-	buf_size = (uint16_t)(rte_pktmbuf_data_room_size(pkt_q->mb_pool) -
-		RTE_PKTMBUF_HEADROOM);
+	buf_size = rte_pktmbuf_data_room_size(pkt_q->mb_pool) - RTE_PKTMBUF_HEADROOM;
+	data_size = internals->req.tp_frame_size - TPACKET2_HDRLEN + sizeof(struct sockaddr_ll);
 
-	if (ETH_FRAME_LEN > buf_size) {
+	if (data_size > buf_size) {
 		RTE_LOG(ERR, PMD,
 			"%s: %d bytes will not fit in mbuf (%d bytes)\n",
-			dev->data->name, ETH_FRAME_LEN, buf_size);
+			dev->data->name, data_size, buf_size);
 		return -ENOMEM;
 	}
 
-- 
2.10.2

[dpdk-dev] [PATCH v2 08/13] PMD/af_packet: guard against buffer overruns in RX path

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 drivers/net/af_packet/rte_eth_af_packet.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/net/af_packet/rte_eth_af_packet.c b/drivers/net/af_packet/rte_eth_af_packet.c
index ff45068..5599e02 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -370,18 +370,19 @@ eth_rx_queue_setup(struct rte_eth_dev *dev,
 {
 	struct pmd_internals *internals = dev->data->dev_private;
 	struct pkt_rx_queue *pkt_q = &internals->rx_queue[rx_queue_id];
-	uint16_t buf_size;
+	unsigned int buf_size, data_size;
 
 	pkt_q->mb_pool = mb_pool;
 
 	/* Now get the space available for data in the mbuf */
-	buf_size = (uint16_t)(rte_pktmbuf_data_room_size(pkt_q->mb_pool) -
-		RTE_PKTMBUF_HEADROOM);
+	buf_size = rte_pktmbuf_data_room_size(pkt_q->mb_pool) - RTE_PKTMBUF_HEADROOM;
+	data_size = internals->req.tp_frame_size;
+	data_size -= TPACKET2_HDRLEN - sizeof(struct sockaddr_ll);
 
-	if (ETH_FRAME_LEN > buf_size) {
+	if (data_size > buf_size) {
 		RTE_LOG(ERR, PMD,
 			"%s: %d bytes will not fit in mbuf (%d bytes)\n",
-			dev->data->name, ETH_FRAME_LEN, buf_size);
+			dev->data->name, data_size, buf_size);
 		return -ENOMEM;
 	}
 
-- 
2.10.2

Re: [dpdk-dev] [PATCH v2 08/13] PMD/af_packet: guard against buffer overruns in RX path

[John W. Linville]

On Tue, Dec 13, 2016 at 02:28:34AM +0100, Michał Mirosław wrote:
> 
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>

Acked-by: John W. Linville <linville@tuxdriver.com>

> ---
>  drivers/net/af_packet/rte_eth_af_packet.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/af_packet/rte_eth_af_packet.c b/drivers/net/af_packet/rte_eth_af_packet.c
> index ff45068..5599e02 100644
> --- a/drivers/net/af_packet/rte_eth_af_packet.c
> +++ b/drivers/net/af_packet/rte_eth_af_packet.c
> @@ -370,18 +370,19 @@ eth_rx_queue_setup(struct rte_eth_dev *dev,
>  {
>  	struct pmd_internals *internals = dev->data->dev_private;
>  	struct pkt_rx_queue *pkt_q = &internals->rx_queue[rx_queue_id];
> -	uint16_t buf_size;
> +	unsigned int buf_size, data_size;
>  
>  	pkt_q->mb_pool = mb_pool;
>  
>  	/* Now get the space available for data in the mbuf */
> -	buf_size = (uint16_t)(rte_pktmbuf_data_room_size(pkt_q->mb_pool) -
> -		RTE_PKTMBUF_HEADROOM);
> +	buf_size = rte_pktmbuf_data_room_size(pkt_q->mb_pool) - RTE_PKTMBUF_HEADROOM;
> +	data_size = internals->req.tp_frame_size;
> +	data_size -= TPACKET2_HDRLEN - sizeof(struct sockaddr_ll);
>  
> -	if (ETH_FRAME_LEN > buf_size) {
> +	if (data_size > buf_size) {
>  		RTE_LOG(ERR, PMD,
>  			"%s: %d bytes will not fit in mbuf (%d bytes)\n",
> -			dev->data->name, ETH_FRAME_LEN, buf_size);
> +			dev->data->name, data_size, buf_size);
>  		return -ENOMEM;
>  	}
>  
> -- 
> 2.10.2
> 
> 

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [dpdk-dev] [PATCH v2 08/13] PMD/af_packet: guard against buffer overruns in RX path

[Ferruh Yigit]

On 12/13/2016 4:05 PM, John W. Linville wrote:
> On Tue, Dec 13, 2016 at 02:28:34AM +0100, Michał Mirosław wrote:
>>
>> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> 
> Acked-by: John W. Linville <linville@tuxdriver.com>
> 

Applied to dpdk-next-net/master, thanks.

Re: [dpdk-dev] [PATCH 08/13] PMD/af_packet: guard against buffer overruns in RX path

[Ferruh Yigit]

On 12/13/2016 1:08 AM, Michał Mirosław wrote:
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>

Form main address (<mirq-linux@rere.qmqm.pl>) which sets git author
field, and Signed-off mail address are different.

As author, any objection to use signed-off mail:
"Michał Mirosław <michal.miroslaw@atendesoftware.pl>"

This is valid for a few other patches.

Re: [dpdk-dev] [PATCH 08/13] PMD/af_packet: guard against buffer overruns in RX path

[Michał Mirosław]

On Wed, Jan 18, 2017 at 11:48:52AM +0000, Ferruh Yigit wrote:
> On 12/13/2016 1:08 AM, Michał Mirosław wrote:
> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> Form main address (<mirq-linux@rere.qmqm.pl>) which sets git author
> field, and Signed-off mail address are different.
> 
> As author, any objection to use signed-off mail:
> "Michał Mirosław <michal.miroslaw@atendesoftware.pl>"
> 
> This is valid for a few other patches.

Please use the Signed-off address, thanks.

Best Regards,
Michał Mirosław

[dpdk-dev] [PATCH 07/13] pcap: fix timestamps in output pcap file

[Michał Mirosław]

From: Piotr Bartosiewicz <piotr.bartosiewicz@atendesoftware.pl>

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 drivers/net/pcap/rte_eth_pcap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index 0162f44..57b0b31 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -247,7 +247,7 @@ calculate_timestamp(struct timeval *ts) {
 
 	cycles = rte_get_timer_cycles() - start_cycles;
 	cur_time.tv_sec = cycles / hz;
-	cur_time.tv_usec = (cycles % hz) * 10e6 / hz;
+	cur_time.tv_usec = (cycles % hz) * 1e6 / hz;
 	timeradd(&start_time, &cur_time, ts);
 }
 
-- 
2.10.2

Re: [dpdk-dev] [PATCH 07/13] pcap: fix timestamps in output pcap file

[Ferruh Yigit]

On 12/13/2016 1:08 AM, Michał Mirosław wrote:
> From: Piotr Bartosiewicz <piotr.bartosiewicz@atendesoftware.pl>
> 
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> ---

Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Re: [dpdk-dev] [PATCH 07/13] pcap: fix timestamps in output pcap file

[Ferruh Yigit]

On 12/14/2016 5:45 PM, Ferruh Yigit wrote:
> On 12/13/2016 1:08 AM, Michał Mirosław wrote:
>> From: Piotr Bartosiewicz <piotr.bartosiewicz@atendesoftware.pl>
>>
>> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
>> ---
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
> 

CC: stable@dpdk.org

Applied to dpdk-next-net/master, thanks.

[dpdk-dev] [PATCH 10/13] KNI: provided netif name's source is user-space

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 lib/librte_eal/linuxapp/kni/kni_misc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c b/lib/librte_eal/linuxapp/kni/kni_misc.c
index 497db9b..f0247aa 100644
--- a/lib/librte_eal/linuxapp/kni/kni_misc.c
+++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
@@ -363,8 +363,8 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
 	up_read(&knet->kni_list_lock);
 
 	net_dev = alloc_netdev(sizeof(struct kni_dev), dev_info.name,
-#ifdef NET_NAME_UNKNOWN
-							NET_NAME_UNKNOWN,
+#ifdef NET_NAME_USER
+							NET_NAME_USER,
 #endif
 							kni_net_init);
 	if (net_dev == NULL) {
-- 
2.10.2

Re: [dpdk-dev] [PATCH 10/13] KNI: provided netif name's source is user-space

[Ferruh Yigit]

Hi Michal,

On 12/13/2016 1:08 AM, Michał Mirosław wrote:
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> ---
>  lib/librte_eal/linuxapp/kni/kni_misc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c b/lib/librte_eal/linuxapp/kni/kni_misc.c
> index 497db9b..f0247aa 100644
> --- a/lib/librte_eal/linuxapp/kni/kni_misc.c
> +++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
> @@ -363,8 +363,8 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
>  	up_read(&knet->kni_list_lock);
>  
>  	net_dev = alloc_netdev(sizeof(struct kni_dev), dev_info.name,
> -#ifdef NET_NAME_UNKNOWN
> -							NET_NAME_UNKNOWN,
> +#ifdef NET_NAME_USER
> +							NET_NAME_USER,

Probably NET_NAME_USER fits better to definition.
But functionally, I wonder if you have a use case to use
"name_assign_type" ?

>  #endif
>  							kni_net_init);
>  	if (net_dev == NULL) {
> 

Re: [dpdk-dev] [PATCH 10/13] KNI: provided netif name's source is user-space

[Michał Mirosław]

On Wed, Dec 14, 2016 at 05:06:23PM +0000, Ferruh Yigit wrote:
> Hi Michal,
> 
> On 12/13/2016 1:08 AM, Michał Mirosław wrote:
> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > ---
> >  lib/librte_eal/linuxapp/kni/kni_misc.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c b/lib/librte_eal/linuxapp/kni/kni_misc.c
> > index 497db9b..f0247aa 100644
> > --- a/lib/librte_eal/linuxapp/kni/kni_misc.c
> > +++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
> > @@ -363,8 +363,8 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
> >  	up_read(&knet->kni_list_lock);
> >  
> >  	net_dev = alloc_netdev(sizeof(struct kni_dev), dev_info.name,
> > -#ifdef NET_NAME_UNKNOWN
> > -							NET_NAME_UNKNOWN,
> > +#ifdef NET_NAME_USER
> > +							NET_NAME_USER,
> 
> Probably NET_NAME_USER fits better to definition.
> But functionally, I wonder if you have a use case to use
> "name_assign_type" ?

I just read what NET_NAME_UNKNOWN/NET_NAME_USER is supposed to do.
UNKNOWN is for "old" drivers that don't know the source of the name.
USER is for a name, that comes from a user and as such is not to be
renamed by udev.

Best Regards,
Michał Mirosław

Re: [dpdk-dev] [PATCH 10/13] KNI: provided netif name's source is user-space

[Ferruh Yigit]

On 12/14/2016 5:19 PM, Michał Mirosław wrote:
> On Wed, Dec 14, 2016 at 05:06:23PM +0000, Ferruh Yigit wrote:
>> Hi Michal,
>>
>> On 12/13/2016 1:08 AM, Michał Mirosław wrote:
>>> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
>>> ---
>>>  lib/librte_eal/linuxapp/kni/kni_misc.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c b/lib/librte_eal/linuxapp/kni/kni_misc.c
>>> index 497db9b..f0247aa 100644
>>> --- a/lib/librte_eal/linuxapp/kni/kni_misc.c
>>> +++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
>>> @@ -363,8 +363,8 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
>>>  	up_read(&knet->kni_list_lock);
>>>  
>>>  	net_dev = alloc_netdev(sizeof(struct kni_dev), dev_info.name,
>>> -#ifdef NET_NAME_UNKNOWN
>>> -							NET_NAME_UNKNOWN,
>>> +#ifdef NET_NAME_USER
>>> +							NET_NAME_USER,
>>
>> Probably NET_NAME_USER fits better to definition.
>> But functionally, I wonder if you have a use case to use
>> "name_assign_type" ?
> 
> I just read what NET_NAME_UNKNOWN/NET_NAME_USER is supposed to do.
> UNKNOWN is for "old" drivers that don't know the source of the name.
> USER is for a name, that comes from a user and as such is not to be
> renamed by udev.

That is what I wonder if you are doing anything special in userspace
related iface name. But it seems the patch is to make it more proper, I
have no objection.

> 
> Best Regards,
> Michał Mirosław
> 

Re: [dpdk-dev] [PATCH 10/13] KNI: provided netif name's source is user-space

[Ferruh Yigit]

On 12/14/2016 5:35 PM, Ferruh Yigit wrote:
> On 12/14/2016 5:19 PM, Michał Mirosław wrote:
>> On Wed, Dec 14, 2016 at 05:06:23PM +0000, Ferruh Yigit wrote:
>>> Hi Michal,
>>>
>>> On 12/13/2016 1:08 AM, Michał Mirosław wrote:
>>>> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
>>>> ---

Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Re: [dpdk-dev] [PATCH 10/13] KNI: provided netif name's source is user-space

[Thomas Monjalon]

2016-12-14 17:35, Ferruh Yigit:
> On 12/14/2016 5:35 PM, Ferruh Yigit wrote:
> > On 12/14/2016 5:19 PM, Michał Mirosław wrote:
> >> On Wed, Dec 14, 2016 at 05:06:23PM +0000, Ferruh Yigit wrote:
> >>> Hi Michal,
> >>>
> >>> On 12/13/2016 1:08 AM, Michał Mirosław wrote:
> >>>> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> >>>> ---
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Applied, thanks

[dpdk-dev] [PATCH 09/13] PMD/af_packet: guard against buffer overruns in TX path

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 drivers/net/af_packet/rte_eth_af_packet.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/net/af_packet/rte_eth_af_packet.c b/drivers/net/af_packet/rte_eth_af_packet.c
index b1005c6..2c81d25 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -83,6 +83,7 @@ struct pkt_rx_queue {
 
 struct pkt_tx_queue {
 	int sockfd;
+	unsigned frame_data_size;
 
 	struct iovec *rd;
 	uint8_t *map;
@@ -206,13 +207,20 @@ eth_af_packet_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
 	framenum = pkt_q->framenum;
 	ppd = (struct tpacket2_hdr *) pkt_q->rd[framenum].iov_base;
 	for (i = 0; i < nb_pkts; i++) {
+		mbuf = *bufs++;
+
+		/* drop oversized packets */
+		if (rte_pktmbuf_data_len(mbuf) > pkt_q->frame_data_size) {
+			rte_pktmbuf_free(mbuf);
+			continue;
+		}
+
 		/* point at the next incoming frame */
 		if ((ppd->tp_status != TP_STATUS_AVAILABLE) &&
 		    (poll(&pfd, 1, -1) < 0))
-				continue;
+				break;
 
 		/* copy the tx frame data */
-		mbuf = bufs[num_tx];
 		pbuf = (uint8_t *) ppd + TPACKET2_HDRLEN -
 			sizeof(struct sockaddr_ll);
 		memcpy(pbuf, rte_pktmbuf_mtod(mbuf, void*), rte_pktmbuf_data_len(mbuf));
@@ -231,13 +239,13 @@ eth_af_packet_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
 
 	/* kick-off transmits */
 	if (sendto(pkt_q->sockfd, NULL, 0, MSG_DONTWAIT, NULL, 0) == -1)
-		return 0; /* error sending -- no packets transmitted */
+		num_tx = 0; /* error sending -- no packets transmitted */
 
 	pkt_q->framenum = framenum;
 	pkt_q->tx_pkts += num_tx;
-	pkt_q->err_pkts += nb_pkts - num_tx;
+	pkt_q->err_pkts += i - num_tx;
 	pkt_q->tx_bytes += num_tx_bytes;
-	return num_tx;
+	return i;
 }
 
 static int
@@ -633,6 +641,7 @@ rte_pmd_init_internals(const char *name,
 
 		tx_queue = &((*internals)->tx_queue[q]);
 		tx_queue->framecount = req->tp_frame_nr;
+		tx_queue->frame_data_size = req->tp_frame_size - TPACKET2_HDRLEN + sizeof(struct sockaddr_ll);
 
 		tx_queue->map = rx_queue->map + req->tp_block_size * req->tp_block_nr;
 
-- 
2.10.2

[dpdk-dev] [PATCH v2 09/13] PMD/af_packet: guard against buffer overruns in TX path

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 drivers/net/af_packet/rte_eth_af_packet.c | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/net/af_packet/rte_eth_af_packet.c b/drivers/net/af_packet/rte_eth_af_packet.c
index 5599e02..fc2dc4a 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -83,6 +83,7 @@ struct pkt_rx_queue {
 
 struct pkt_tx_queue {
 	int sockfd;
+	unsigned int frame_data_size;
 
 	struct iovec *rd;
 	uint8_t *map;
@@ -206,13 +207,20 @@ eth_af_packet_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
 	framenum = pkt_q->framenum;
 	ppd = (struct tpacket2_hdr *) pkt_q->rd[framenum].iov_base;
 	for (i = 0; i < nb_pkts; i++) {
+		mbuf = *bufs++;
+
+		/* drop oversized packets */
+		if (rte_pktmbuf_data_len(mbuf) > pkt_q->frame_data_size) {
+			rte_pktmbuf_free(mbuf);
+			continue;
+		}
+
 		/* point at the next incoming frame */
 		if ((ppd->tp_status != TP_STATUS_AVAILABLE) &&
 		    (poll(&pfd, 1, -1) < 0))
-				continue;
+			break;
 
 		/* copy the tx frame data */
-		mbuf = bufs[num_tx];
 		pbuf = (uint8_t *) ppd + TPACKET2_HDRLEN -
 			sizeof(struct sockaddr_ll);
 		memcpy(pbuf, rte_pktmbuf_mtod(mbuf, void*), rte_pktmbuf_data_len(mbuf));
@@ -231,13 +239,13 @@ eth_af_packet_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
 
 	/* kick-off transmits */
 	if (sendto(pkt_q->sockfd, NULL, 0, MSG_DONTWAIT, NULL, 0) == -1)
-		return 0; /* error sending -- no packets transmitted */
+		num_tx = 0; /* error sending -- no packets transmitted */
 
 	pkt_q->framenum = framenum;
 	pkt_q->tx_pkts += num_tx;
-	pkt_q->err_pkts += nb_pkts - num_tx;
+	pkt_q->err_pkts += i - num_tx;
 	pkt_q->tx_bytes += num_tx_bytes;
-	return num_tx;
+	return i;
 }
 
 static int
@@ -634,6 +642,8 @@ rte_pmd_init_internals(const char *name,
 
 		tx_queue = &((*internals)->tx_queue[q]);
 		tx_queue->framecount = req->tp_frame_nr;
+		tx_queue->frame_data_size = req->tp_frame_size;
+		tx_queue->frame_data_size -= TPACKET2_HDRLEN - sizeof(struct sockaddr_ll);
 
 		tx_queue->map = rx_queue->map + req->tp_block_size * req->tp_block_nr;
 
-- 
2.10.2

Re: [dpdk-dev] [PATCH v2 09/13] PMD/af_packet: guard against buffer overruns in TX path

[John W. Linville]

On Tue, Dec 13, 2016 at 02:28:34AM +0100, Michał Mirosław wrote:
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>

Acked-by: John W. Linville <linville@tuxdriver.com>

> ---
>  drivers/net/af_packet/rte_eth_af_packet.c | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/af_packet/rte_eth_af_packet.c b/drivers/net/af_packet/rte_eth_af_packet.c
> index 5599e02..fc2dc4a 100644
> --- a/drivers/net/af_packet/rte_eth_af_packet.c
> +++ b/drivers/net/af_packet/rte_eth_af_packet.c
> @@ -83,6 +83,7 @@ struct pkt_rx_queue {
>  
>  struct pkt_tx_queue {
>  	int sockfd;
> +	unsigned int frame_data_size;
>  
>  	struct iovec *rd;
>  	uint8_t *map;
> @@ -206,13 +207,20 @@ eth_af_packet_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>  	framenum = pkt_q->framenum;
>  	ppd = (struct tpacket2_hdr *) pkt_q->rd[framenum].iov_base;
>  	for (i = 0; i < nb_pkts; i++) {
> +		mbuf = *bufs++;
> +
> +		/* drop oversized packets */
> +		if (rte_pktmbuf_data_len(mbuf) > pkt_q->frame_data_size) {
> +			rte_pktmbuf_free(mbuf);
> +			continue;
> +		}
> +
>  		/* point at the next incoming frame */
>  		if ((ppd->tp_status != TP_STATUS_AVAILABLE) &&
>  		    (poll(&pfd, 1, -1) < 0))
> -				continue;
> +			break;
>  
>  		/* copy the tx frame data */
> -		mbuf = bufs[num_tx];
>  		pbuf = (uint8_t *) ppd + TPACKET2_HDRLEN -
>  			sizeof(struct sockaddr_ll);
>  		memcpy(pbuf, rte_pktmbuf_mtod(mbuf, void*), rte_pktmbuf_data_len(mbuf));
> @@ -231,13 +239,13 @@ eth_af_packet_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>  
>  	/* kick-off transmits */
>  	if (sendto(pkt_q->sockfd, NULL, 0, MSG_DONTWAIT, NULL, 0) == -1)
> -		return 0; /* error sending -- no packets transmitted */
> +		num_tx = 0; /* error sending -- no packets transmitted */
>  
>  	pkt_q->framenum = framenum;
>  	pkt_q->tx_pkts += num_tx;
> -	pkt_q->err_pkts += nb_pkts - num_tx;
> +	pkt_q->err_pkts += i - num_tx;
>  	pkt_q->tx_bytes += num_tx_bytes;
> -	return num_tx;
> +	return i;
>  }
>  
>  static int
> @@ -634,6 +642,8 @@ rte_pmd_init_internals(const char *name,
>  
>  		tx_queue = &((*internals)->tx_queue[q]);
>  		tx_queue->framecount = req->tp_frame_nr;
> +		tx_queue->frame_data_size = req->tp_frame_size;
> +		tx_queue->frame_data_size -= TPACKET2_HDRLEN - sizeof(struct sockaddr_ll);
>  
>  		tx_queue->map = rx_queue->map + req->tp_block_size * req->tp_block_nr;
>  
> -- 
> 2.10.2
> 
> 

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [dpdk-dev] [PATCH v2 09/13] PMD/af_packet: guard against buffer overruns in TX path

[Ferruh Yigit]

On 12/13/2016 4:06 PM, John W. Linville wrote:
> On Tue, Dec 13, 2016 at 02:28:34AM +0100, Michał Mirosław wrote:
>> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> 
> Acked-by: John W. Linville <linville@tuxdriver.com>
> 

Applied to dpdk-next-net/master, thanks.

[dpdk-dev] [PATCH 11/13] KNI: guard against unterminated dev_info.name leading to BUG in alloc_netdev()

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 lib/librte_eal/linuxapp/kni/kni_misc.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c b/lib/librte_eal/linuxapp/kni/kni_misc.c
index f0247aa..14a2e3b 100644
--- a/lib/librte_eal/linuxapp/kni/kni_misc.c
+++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
@@ -344,6 +344,12 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
 		return -EIO;
 	}
 
+	/* Check if name is zero-ended */
+	if (strnlen(dev_info.name, sizeof(dev_info.name)) == sizeof(dev_info.name)) {
+		pr_err("kni.name not zero-terminated");
+		return -EINVAL;
+	}
+
 	/**
 	 * Check if the cpu core id is valid for binding.
 	 */
-- 
2.10.2

Re: [dpdk-dev] [PATCH 11/13] KNI: guard against unterminated dev_info.name leading to BUG in alloc_netdev()

[Ferruh Yigit]

On 12/13/2016 1:08 AM, Michał Mirosław wrote:
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> ---

Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

I guess no harm doing extra check on user input.

Re: [dpdk-dev] [PATCH 11/13] KNI: guard against unterminated dev_info.name leading to BUG in alloc_netdev()

[Michał Mirosław]

On Wed, Dec 14, 2016 at 05:33:11PM +0000, Ferruh Yigit wrote:
> On 12/13/2016 1:08 AM, Michał Mirosław wrote:
> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > ---
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
> 
> I guess no harm doing extra check on user input.

This actually prevents an OOPS that happens when you try to create KNI with
too long name.

Best Regards,
Michał Mirosław

Re: [dpdk-dev] [PATCH 11/13] KNI: guard against unterminated dev_info.name leading to BUG in alloc_netdev()

[Ferruh Yigit]

On 12/14/2016 5:37 PM, Michał Mirosław wrote:
> On Wed, Dec 14, 2016 at 05:33:11PM +0000, Ferruh Yigit wrote:
>> On 12/13/2016 1:08 AM, Michał Mirosław wrote:
>>> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
>>> ---
>>
>> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>
>> I guess no harm doing extra check on user input.
> 
> This actually prevents an OOPS that happens when you try to create KNI with
> too long name.

Thanks for fixing then.

Re: [dpdk-dev] [PATCH 11/13] KNI: guard against unterminated dev_info.name leading to BUG in alloc_netdev()

[Thomas Monjalon]

2016-12-14 17:33, Ferruh Yigit:
> On 12/13/2016 1:08 AM, Michał Mirosław wrote:
> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > ---
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Applied, thanks

[dpdk-dev] [PATCH 13/13] i40e: improve message grepability

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 drivers/net/i40e/i40e_ethdev.c | 198 +++++++++++++++--------------------------
 1 file changed, 73 insertions(+), 125 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 39fbcfe..4d73aca 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -763,8 +763,7 @@ i40e_add_tx_flow_control_drop_filter(struct i40e_pf *pf)
 				pf->main_vsi_seid, 0,
 				TRUE, NULL, NULL);
 	if (ret)
-		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control "
-				  " frames from VSIs.");
+		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control frames from VSIs.");
 }
 
 static int
@@ -963,8 +962,7 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
 	hw->back = I40E_PF_TO_ADAPTER(pf);
 	hw->hw_addr = (uint8_t *)(pci_dev->mem_resource[0].addr);
 	if (!hw->hw_addr) {
-		PMD_INIT_LOG(ERR, "Hardware is not available, "
-			     "as address is NULL");
+		PMD_INIT_LOG(ERR, "Hardware is not available, as address is NULL");
 		return -ENODEV;
 	}
 
@@ -1100,8 +1098,7 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
 	/* Set the global registers with default ether type value */
 	ret = i40e_vlan_tpid_set(dev, ETH_VLAN_TYPE_OUTER, ETHER_TYPE_VLAN);
 	if (ret != I40E_SUCCESS) {
-		PMD_INIT_LOG(ERR, "Failed to set the default outer "
-			     "VLAN ether type");
+		PMD_INIT_LOG(ERR, "Failed to set the default outer VLAN ether type");
 		goto err_setup_pf_switch;
 	}
 
@@ -1137,8 +1134,7 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
 	/* Should be after VSI initialized */
 	dev->data->mac_addrs = rte_zmalloc("i40e", len, 0);
 	if (!dev->data->mac_addrs) {
-		PMD_INIT_LOG(ERR, "Failed to allocated memory "
-					"for storing mac address");
+		PMD_INIT_LOG(ERR, "Failed to allocated memory for storing mac address");
 		goto err_mac_alloc;
 	}
 	ether_addr_copy((struct ether_addr *)hw->mac.perm_addr,
@@ -1703,8 +1699,9 @@ i40e_dev_start(struct rte_eth_dev *dev)
 				    dev->data->nb_rx_queues * sizeof(int),
 				    0);
 		if (!intr_handle->intr_vec) {
-			PMD_INIT_LOG(ERR, "Failed to allocate %d rx_queues"
-				     " intr_vec\n", dev->data->nb_rx_queues);
+			PMD_INIT_LOG(ERR,
+				"Failed to allocate %d rx_queues intr_vec\n",
+				dev->data->nb_rx_queues);
 			return -ENOMEM;
 		}
 	}
@@ -1777,8 +1774,8 @@ i40e_dev_start(struct rte_eth_dev *dev)
 		i40e_pf_enable_irq0(hw);
 
 		if (dev->data->dev_conf.intr_conf.lsc != 0)
-			PMD_INIT_LOG(INFO, "lsc won't enable because of"
-				     " no intr multiplex\n");
+			PMD_INIT_LOG(INFO,
+				"lsc won't enable because of no intr multiplex\n");
 	} else if (dev->data->dev_conf.intr_conf.lsc != 0) {
 		ret = i40e_aq_set_phy_int_mask(hw,
 					       ~(I40E_AQ_EVENT_LINK_UPDOWN |
@@ -2718,13 +2715,11 @@ i40e_vlan_tpid_set(struct rte_eth_dev *dev,
 	ret = i40e_aq_debug_read_register(hw, I40E_GL_SWT_L2TAGCTRL(reg_id),
 					  &reg_r, NULL);
 	if (ret != I40E_SUCCESS) {
-		PMD_DRV_LOG(ERR, "Fail to debug read from "
-			    "I40E_GL_SWT_L2TAGCTRL[%d]", reg_id);
+		PMD_DRV_LOG(ERR, "Fail to debug read from I40E_GL_SWT_L2TAGCTRL[%d]", reg_id);
 		ret = -EIO;
 		return ret;
 	}
-	PMD_DRV_LOG(DEBUG, "Debug read from I40E_GL_SWT_L2TAGCTRL[%d]: "
-		    "0x%08"PRIx64"", reg_id, reg_r);
+	PMD_DRV_LOG(DEBUG, "Debug read from I40E_GL_SWT_L2TAGCTRL[%d]: 0x%08"PRIx64"", reg_id, reg_r);
 
 	reg_w = reg_r & (~(I40E_GL_SWT_L2TAGCTRL_ETHERTYPE_MASK));
 	reg_w |= ((uint64_t)tpid << I40E_GL_SWT_L2TAGCTRL_ETHERTYPE_SHIFT);
@@ -2738,12 +2733,10 @@ i40e_vlan_tpid_set(struct rte_eth_dev *dev,
 					   reg_w, NULL);
 	if (ret != I40E_SUCCESS) {
 		ret = -EIO;
-		PMD_DRV_LOG(ERR, "Fail to debug write to "
-			    "I40E_GL_SWT_L2TAGCTRL[%d]", reg_id);
+		PMD_DRV_LOG(ERR, "Fail to debug write to I40E_GL_SWT_L2TAGCTRL[%d]", reg_id);
 		return ret;
 	}
-	PMD_DRV_LOG(DEBUG, "Debug write 0x%08"PRIx64" to "
-		    "I40E_GL_SWT_L2TAGCTRL[%d]", reg_w, reg_id);
+	PMD_DRV_LOG(DEBUG, "Debug write 0x%08"PRIx64" to I40E_GL_SWT_L2TAGCTRL[%d]", reg_w, reg_id);
 
 	return ret;
 }
@@ -2887,8 +2880,7 @@ i40e_flow_ctrl_set(struct rte_eth_dev *dev, struct rte_eth_fc_conf *fc_conf)
 	max_high_water = I40E_RXPBSIZE >> I40E_KILOSHIFT;
 	if ((fc_conf->high_water > max_high_water) ||
 			(fc_conf->high_water < fc_conf->low_water)) {
-		PMD_INIT_LOG(ERR, "Invalid high/low water setup value in KB, "
-			"High_water must <= %d.", max_high_water);
+		PMD_INIT_LOG(ERR, "Invalid high/low water setup value in KB, High_water must be <= %d.", max_high_water);
 		return -EINVAL;
 	}
 
@@ -3060,8 +3052,7 @@ i40e_macaddr_remove(struct rte_eth_dev *dev, uint32_t index)
 				/* No VMDQ pool enabled or configured */
 				if (!(pf->flags & I40E_FLAG_VMDQ) ||
 					(i > pf->nb_cfg_vmdq_vsi)) {
-					PMD_DRV_LOG(ERR, "No VMDQ pool enabled"
-							"/configured");
+					PMD_DRV_LOG(ERR, "No VMDQ pool enabled/configured");
 					return;
 				}
 				vsi = pf->vmdq[i - 1].vsi;
@@ -3262,9 +3253,8 @@ i40e_dev_rss_reta_update(struct rte_eth_dev *dev,
 
 	if (reta_size != lut_size ||
 		reta_size > ETH_RSS_RETA_SIZE_512) {
-		PMD_DRV_LOG(ERR, "The size of hash lookup table configured "
-			"(%d) doesn't match the number hardware can supported "
-					"(%d)\n", reta_size, lut_size);
+		PMD_DRV_LOG(ERR, "The size of hash lookup table configured (%d) doesn't match the number hardware can supported (%d)\n",
+			reta_size, lut_size);
 		return -EINVAL;
 	}
 
@@ -3303,9 +3293,8 @@ i40e_dev_rss_reta_query(struct rte_eth_dev *dev,
 
 	if (reta_size != lut_size ||
 		reta_size > ETH_RSS_RETA_SIZE_512) {
-		PMD_DRV_LOG(ERR, "The size of hash lookup table configured "
-			"(%d) doesn't match the number hardware can supported "
-					"(%d)\n", reta_size, lut_size);
+		PMD_DRV_LOG(ERR, "The size of hash lookup table configured (%d) doesn't match the number hardware can supported (%d)\n",
+			reta_size, lut_size);
 		return -EINVAL;
 	}
 
@@ -3538,9 +3527,8 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
 		pf->flags |= I40E_FLAG_SRIOV;
 		pf->vf_nb_qps = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF;
 		pf->vf_num = dev->pci_dev->max_vfs;
-		PMD_DRV_LOG(DEBUG, "%u VF VSIs, %u queues per VF VSI, "
-			    "in total %u queues", pf->vf_num, pf->vf_nb_qps,
-			    pf->vf_nb_qps * pf->vf_num);
+		PMD_DRV_LOG(DEBUG, "%u VF VSIs, %u queues per VF VSI, in total %u queues",
+			    pf->vf_num, pf->vf_nb_qps, pf->vf_nb_qps * pf->vf_num);
 	} else {
 		pf->vf_nb_qps = 0;
 		pf->vf_num = 0;
@@ -3568,14 +3556,12 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
 			if (pf->max_nb_vmdq_vsi) {
 				pf->flags |= I40E_FLAG_VMDQ;
 				pf->vmdq_nb_qps = pf->vmdq_nb_qp_max;
-				PMD_DRV_LOG(DEBUG, "%u VMDQ VSIs, %u queues "
-					    "per VMDQ VSI, in total %u queues",
+				PMD_DRV_LOG(DEBUG, "%u VMDQ VSIs, %u queues per VMDQ VSI, in total %u queues",
 					    pf->max_nb_vmdq_vsi,
 					    pf->vmdq_nb_qps, pf->vmdq_nb_qps *
 					    pf->max_nb_vmdq_vsi);
 			} else {
-				PMD_DRV_LOG(INFO, "No enough queues left for "
-					    "VMDq");
+				PMD_DRV_LOG(INFO, "No enough queues left for VMDq");
 			}
 		} else {
 			PMD_DRV_LOG(INFO, "No queue or VSI left for VMDq");
@@ -3588,15 +3574,13 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
 		pf->flags |= I40E_FLAG_DCB;
 
 	if (qp_count > hw->func_caps.num_tx_qp) {
-		PMD_DRV_LOG(ERR, "Failed to allocate %u queues, which exceeds "
-			    "the hardware maximum %u", qp_count,
-			    hw->func_caps.num_tx_qp);
+		PMD_DRV_LOG(ERR, "Failed to allocate %u queues, which exceeds the hardware maximum %u",
+			    qp_count, hw->func_caps.num_tx_qp);
 		return -EINVAL;
 	}
 	if (vsi_count > hw->func_caps.num_vsis) {
-		PMD_DRV_LOG(ERR, "Failed to allocate %u VSIs, which exceeds "
-			    "the hardware maximum %u", vsi_count,
-			    hw->func_caps.num_vsis);
+		PMD_DRV_LOG(ERR, "Failed to allocate %u VSIs, which exceeds the hardware maximum %u",
+			    vsi_count, hw->func_caps.num_vsis);
 		return -EINVAL;
 	}
 
@@ -3842,8 +3826,7 @@ i40e_res_pool_alloc(struct i40e_res_pool_info *pool,
 		 */
 		entry = rte_zmalloc("res_pool", sizeof(*entry), 0);
 		if (entry == NULL) {
-			PMD_DRV_LOG(ERR, "Failed to allocate memory for "
-				    "resource pool");
+			PMD_DRV_LOG(ERR, "Failed to allocate memory for resource pool");
 			return -ENOMEM;
 		}
 		entry->base = valid_entry->base;
@@ -3883,9 +3866,8 @@ validate_tcmap_parameter(struct i40e_vsi *vsi, uint8_t enabled_tcmap)
 	}
 
 	if (!bitmap_is_subset(hw->func_caps.enabled_tcmap, enabled_tcmap)) {
-		PMD_DRV_LOG(ERR, "Enabled TC map 0x%x not applicable to "
-			    "HW support 0x%x", hw->func_caps.enabled_tcmap,
-			    enabled_tcmap);
+		PMD_DRV_LOG(ERR, "Enabled TC map 0x%x not applicable to HW support 0x%x",
+			    hw->func_caps.enabled_tcmap, enabled_tcmap);
 		return I40E_NOT_SUPPORTED;
 	}
 	return I40E_SUCCESS;
@@ -4227,8 +4209,7 @@ i40e_update_default_filter_setting(struct i40e_vsi *vsi)
 		struct i40e_mac_filter *f;
 		struct ether_addr *mac;
 
-		PMD_DRV_LOG(WARNING, "Cannot remove the default "
-			    "macvlan filter");
+		PMD_DRV_LOG(WARNING, "Cannot remove the default macvlan filter");
 		/* It needs to add the permanent mac into mac list */
 		f = rte_zmalloc("macv_filter", sizeof(*f), 0);
 		if (f == NULL) {
@@ -4278,8 +4259,8 @@ i40e_vsi_get_bw_config(struct i40e_vsi *vsi)
 	ret = i40e_aq_query_vsi_ets_sla_config(hw, vsi->seid,
 					&ets_sla_config, NULL);
 	if (ret != I40E_SUCCESS) {
-		PMD_DRV_LOG(ERR, "VSI failed to get TC bandwdith "
-			    "configuration %u", hw->aq.asq_last_status);
+		PMD_DRV_LOG(ERR, "VSI failed to get TC bandwdith configuration %u",
+			    hw->aq.asq_last_status);
 		return ret;
 	}
 
@@ -4367,14 +4348,12 @@ i40e_vsi_setup(struct i40e_pf *pf,
 
 	if (type != I40E_VSI_MAIN && type != I40E_VSI_SRIOV &&
 	    uplink_vsi == NULL) {
-		PMD_DRV_LOG(ERR, "VSI setup failed, "
-			    "VSI link shouldn't be NULL");
+		PMD_DRV_LOG(ERR, "VSI setup failed, VSI link shouldn't be NULL");
 		return NULL;
 	}
 
 	if (type == I40E_VSI_MAIN && uplink_vsi != NULL) {
-		PMD_DRV_LOG(ERR, "VSI setup failed, MAIN VSI "
-			    "uplink VSI should be NULL");
+		PMD_DRV_LOG(ERR, "VSI setup failed, MAIN VSI uplink VSI should be NULL");
 		return NULL;
 	}
 
@@ -4525,8 +4504,7 @@ i40e_vsi_setup(struct i40e_pf *pf,
 		ret = i40e_vsi_config_tc_queue_mapping(vsi, &ctxt.info,
 						I40E_DEFAULT_TCMAP);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to configure "
-				    "TC queue mapping");
+			PMD_DRV_LOG(ERR, "Failed to configure TC queue mapping");
 			goto fail_msix_alloc;
 		}
 		ctxt.seid = vsi->seid;
@@ -4596,8 +4574,7 @@ i40e_vsi_setup(struct i40e_pf *pf,
 		ret = i40e_vsi_config_tc_queue_mapping(vsi, &ctxt.info,
 						I40E_DEFAULT_TCMAP);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to configure "
-				    "TC queue mapping");
+			PMD_DRV_LOG(ERR, "Failed to configure TC queue mapping");
 			goto fail_msix_alloc;
 		}
 		ctxt.info.up_enable_bits = I40E_DEFAULT_TCMAP;
@@ -4639,8 +4616,7 @@ i40e_vsi_setup(struct i40e_pf *pf,
 		ret = i40e_vsi_config_tc_queue_mapping(vsi, &ctxt.info,
 						I40E_DEFAULT_TCMAP);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to configure "
-					"TC queue mapping");
+			PMD_DRV_LOG(ERR, "Failed to configure TC queue mapping");
 			goto fail_msix_alloc;
 		}
 		ctxt.info.up_enable_bits = I40E_DEFAULT_TCMAP;
@@ -4657,8 +4633,7 @@ i40e_vsi_setup(struct i40e_pf *pf,
 		ret = i40e_vsi_config_tc_queue_mapping(vsi, &ctxt.info,
 						I40E_DEFAULT_TCMAP);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to configure "
-					"TC queue mapping.");
+			PMD_DRV_LOG(ERR, "Failed to configure TC queue mapping.");
 			goto fail_msix_alloc;
 		}
 		ctxt.info.up_enable_bits = I40E_DEFAULT_TCMAP;
@@ -4921,8 +4896,7 @@ i40e_pf_setup(struct i40e_pf *pf)
 		/* make queue allocated first, let FDIR use queue pair 0*/
 		ret = i40e_res_pool_alloc(&pf->qp_pool, I40E_DEFAULT_QP_NUM_FDIR);
 		if (ret != I40E_FDIR_QUEUE_ID) {
-			PMD_DRV_LOG(ERR, "queue allocation fails for FDIR :"
-				    " ret =%d", ret);
+			PMD_DRV_LOG(ERR, "queue allocation fails for FDIR: ret =%d", ret);
 			pf->flags &= ~I40E_FLAG_FDIR;
 		}
 	}
@@ -4945,8 +4919,8 @@ i40e_pf_setup(struct i40e_pf *pf)
 						hw->func_caps.rss_table_size);
 		return I40E_ERR_PARAM;
 	}
-	PMD_DRV_LOG(INFO, "Hardware capability of hash lookup table "
-			"size: %u\n", hw->func_caps.rss_table_size);
+	PMD_DRV_LOG(INFO, "Hardware capability of hash lookup table size: %u\n",
+		    hw->func_caps.rss_table_size);
 	pf->hash_lut_size = hw->func_caps.rss_table_size;
 
 	/* Enable ethtype and macvlan filters */
@@ -5196,8 +5170,7 @@ i40e_dev_rx_init(struct i40e_pf *pf)
 
 		ret = i40e_rx_queue_init(rxq);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to do RX queue "
-				    "initialization");
+			PMD_DRV_LOG(ERR, "Failed to do RX queue initialization");
 			break;
 		}
 	}
@@ -5481,8 +5454,8 @@ i40e_dev_handle_aq_msg(struct rte_eth_dev *dev)
 		ret = i40e_clean_arq_element(hw, &info, &pending);
 
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(INFO, "Failed to read msg from AdminQ, "
-				    "aq_err: %u", hw->aq.asq_last_status);
+			PMD_DRV_LOG(INFO, "Failed to read msg from AdminQ, aq_err: %u",
+				    hw->aq.asq_last_status);
 			break;
 		}
 		opcode = rte_le_to_cpu_16(info.desc.opcode);
@@ -5799,8 +5772,7 @@ i40e_find_all_vlan_for_mac(struct i40e_vsi *vsi,
 			for (k = 0; k < I40E_UINT32_BIT_SIZE; k++) {
 				if (vsi->vfta[j] & (1 << k)) {
 					if (i > num - 1) {
-						PMD_DRV_LOG(ERR, "vlan number "
-							    "not match");
+						PMD_DRV_LOG(ERR, "vlan number not match");
 						return I40E_ERR_PARAM;
 					}
 					(void)rte_memcpy(&mv_f[i].macaddr,
@@ -6281,8 +6253,7 @@ i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t key_len)
 
 		ret = i40e_aq_set_rss_key(hw, vsi->vsi_id, key_dw);
 		if (ret)
-			PMD_INIT_LOG(ERR, "Failed to configure RSS key "
-				     "via AQ");
+			PMD_INIT_LOG(ERR, "Failed to configure RSS key via AQ");
 	} else {
 		uint32_t *hash_key = (uint32_t *)key;
 		uint16_t i;
@@ -6546,8 +6517,7 @@ i40e_add_vxlan_port(struct i40e_pf *pf, uint16_t port)
 	/* Now check if there is space to add the new port */
 	idx = i40e_get_vxlan_port_idx(pf, 0);
 	if (idx < 0) {
-		PMD_DRV_LOG(ERR, "Maximum number of UDP ports reached,"
-			"not adding port %d", port);
+		PMD_DRV_LOG(ERR, "Maximum number of UDP ports reached, not adding port %d", port);
 		return -ENOSPC;
 	}
 
@@ -6918,15 +6888,13 @@ i40e_set_symmetric_hash_enable_per_port(struct i40e_hw *hw, uint8_t enable)
 
 	if (enable > 0) {
 		if (reg & I40E_PRTQF_CTL_0_HSYM_ENA_MASK) {
-			PMD_DRV_LOG(INFO, "Symmetric hash has already "
-							"been enabled");
+			PMD_DRV_LOG(INFO, "Symmetric hash has already been enabled");
 			return;
 		}
 		reg |= I40E_PRTQF_CTL_0_HSYM_ENA_MASK;
 	} else {
 		if (!(reg & I40E_PRTQF_CTL_0_HSYM_ENA_MASK)) {
-			PMD_DRV_LOG(INFO, "Symmetric hash has already "
-							"been disabled");
+			PMD_DRV_LOG(INFO, "Symmetric hash has already been disabled");
 			return;
 		}
 		reg &= ~I40E_PRTQF_CTL_0_HSYM_ENA_MASK;
@@ -7050,16 +7018,14 @@ i40e_set_hash_filter_global_config(struct i40e_hw *hw,
 	if (g_cfg->hash_func == RTE_ETH_HASH_FUNCTION_TOEPLITZ) {
 		/* Toeplitz */
 		if (reg & I40E_GLQF_CTL_HTOEP_MASK) {
-			PMD_DRV_LOG(DEBUG, "Hash function already set to "
-								"Toeplitz");
+			PMD_DRV_LOG(DEBUG, "Hash function already set to Toeplitz");
 			goto out;
 		}
 		reg |= I40E_GLQF_CTL_HTOEP_MASK;
 	} else if (g_cfg->hash_func == RTE_ETH_HASH_FUNCTION_SIMPLE_XOR) {
 		/* Simple XOR */
 		if (!(reg & I40E_GLQF_CTL_HTOEP_MASK)) {
-			PMD_DRV_LOG(DEBUG, "Hash function already set to "
-							"Simple XOR");
+			PMD_DRV_LOG(DEBUG, "Hash function already set to Simple XOR");
 			goto out;
 		}
 		reg &= ~I40E_GLQF_CTL_HTOEP_MASK;
@@ -8007,13 +7973,12 @@ i40e_ethertype_filter_set(struct i40e_pf *pf,
 	}
 	if (filter->ether_type == ETHER_TYPE_IPv4 ||
 		filter->ether_type == ETHER_TYPE_IPv6) {
-		PMD_DRV_LOG(ERR, "unsupported ether_type(0x%04x) in"
-			" control packet filter.", filter->ether_type);
+		PMD_DRV_LOG(ERR, "unsupported ether_type(0x%04x) in control packet filter.",
+			    filter->ether_type);
 		return -EINVAL;
 	}
 	if (filter->ether_type == ETHER_TYPE_VLAN)
-		PMD_DRV_LOG(WARNING, "filter vlan ether_type in first tag is"
-			" not supported.");
+		PMD_DRV_LOG(WARNING, "filter vlan ether_type in first tag is not supported.");
 
 	if (!(filter->flags & RTE_ETHTYPE_FLAGS_MAC))
 		flags |= I40E_AQC_ADD_CONTROL_PACKET_FLAGS_IGNORE_MAC;
@@ -8340,9 +8305,8 @@ i40e_configure_registers(struct i40e_hw *hw)
 		ret = i40e_aq_debug_write_register(hw, reg_table[i].addr,
 						reg_table[i].val, NULL);
 		if (ret < 0) {
-			PMD_DRV_LOG(ERR, "Failed to write 0x%"PRIx64" to the "
-				"address of 0x%"PRIx32, reg_table[i].val,
-							reg_table[i].addr);
+			PMD_DRV_LOG(ERR, "Failed to write 0x%"PRIx64" to the address of 0x%"PRIx32,
+				    reg_table[i].val, reg_table[i].addr);
 			break;
 		}
 		PMD_DRV_LOG(DEBUG, "Write 0x%"PRIx64" to the address of "
@@ -8387,8 +8351,7 @@ i40e_config_qinq(struct i40e_hw *hw, struct i40e_vsi *vsi)
 						   I40E_VSI_L2TAGSTXVALID(
 						   vsi->vsi_id), reg, NULL);
 		if (ret < 0) {
-			PMD_DRV_LOG(ERR, "Failed to update "
-				"VSI_L2TAGSTXVALID[%d]", vsi->vsi_id);
+			PMD_DRV_LOG(ERR, "Failed to update VSI_L2TAGSTXVALID[%d]", vsi->vsi_id);
 			return I40E_ERR_CONFIG;
 		}
 	}
@@ -8439,8 +8402,7 @@ i40e_aq_add_mirror_rule(struct i40e_hw *hw,
 
 	rte_memcpy(&desc.params.raw, &cmd, sizeof(cmd));
 	status = i40e_asq_send_command(hw, &desc, entries, buff_len, NULL);
-	PMD_DRV_LOG(INFO, "i40e_aq_add_mirror_rule, aq_status %d,"
-			 "rule_id = %u"
+	PMD_DRV_LOG(INFO, "i40e_aq_add_mirror_rule, aq_status %d, rule_id = %u"
 			 " mirror_rules_used = %u, mirror_rules_free = %u,",
 			 hw->aq.asq_last_status, resp->rule_id,
 			 resp->mirror_rules_used, resp->mirror_rules_free);
@@ -8521,8 +8483,7 @@ i40e_mirror_rule_set(struct rte_eth_dev *dev,
 	PMD_DRV_LOG(DEBUG, "i40e_mirror_rule_set: sw_id = %d.", sw_id);
 
 	if (pf->main_vsi->veb == NULL || pf->vfs == NULL) {
-		PMD_DRV_LOG(ERR, "mirror rule can not be configured"
-			" without veb or vfs.");
+		PMD_DRV_LOG(ERR, "mirror rule can not be configured without veb or vfs.");
 		return -ENOSYS;
 	}
 	if (pf->nb_mirror_rule > I40E_MAX_MIRROR_RULES) {
@@ -8554,8 +8515,7 @@ i40e_mirror_rule_set(struct rte_eth_dev *dev,
 					mirr_rule->entries,
 					mirr_rule->num_entries, mirr_rule->id);
 			if (ret < 0) {
-				PMD_DRV_LOG(ERR, "failed to remove mirror rule:"
-						   " ret = %d, aq_err = %d.",
+				PMD_DRV_LOG(ERR, "failed to remove mirror rule: ret = %d, aq_err = %d.",
 						   ret, hw->aq.asq_last_status);
 				return -ENOSYS;
 			}
@@ -8645,8 +8605,7 @@ i40e_mirror_rule_set(struct rte_eth_dev *dev,
 				      mirr_rule->rule_type, mirr_rule->entries,
 				      j, &rule_id);
 	if (ret < 0) {
-		PMD_DRV_LOG(ERR, "failed to add mirror rule:"
-				   " ret = %d, aq_err = %d.",
+		PMD_DRV_LOG(ERR, "failed to add mirror rule: ret = %d, aq_err = %d.",
 				   ret, hw->aq.asq_last_status);
 		rte_free(mirr_rule);
 		return -ENOSYS;
@@ -8699,8 +8658,7 @@ i40e_mirror_rule_reset(struct rte_eth_dev *dev, uint8_t sw_id)
 				mirr_rule->entries,
 				mirr_rule->num_entries, mirr_rule->id);
 		if (ret < 0) {
-			PMD_DRV_LOG(ERR, "failed to remove mirror rule:"
-					   " status = %d, aq_err = %d.",
+			PMD_DRV_LOG(ERR, "failed to remove mirror rule: status = %d, aq_err = %d.",
 					   ret, hw->aq.asq_last_status);
 			return -ENOSYS;
 		}
@@ -9133,8 +9091,7 @@ i40e_config_switch_comp_tc(struct i40e_veb *veb, uint8_t tc_map)
 	ret = i40e_aq_config_switch_comp_bw_config(hw, veb->seid,
 						   &veb_bw, NULL);
 	if (ret) {
-		PMD_INIT_LOG(ERR, "AQ command Config switch_comp BW allocation"
-				  " per TC failed = %d",
+		PMD_INIT_LOG(ERR, "AQ command Config switch_comp BW allocation per TC failed = %d",
 				  hw->aq.asq_last_status);
 		return ret;
 	}
@@ -9143,16 +9100,14 @@ i40e_config_switch_comp_tc(struct i40e_veb *veb, uint8_t tc_map)
 	ret = i40e_aq_query_switch_comp_ets_config(hw, veb->seid,
 						   &ets_query, NULL);
 	if (ret != I40E_SUCCESS) {
-		PMD_DRV_LOG(ERR, "Failed to get switch_comp ETS"
-				 " configuration %u", hw->aq.asq_last_status);
+		PMD_DRV_LOG(ERR, "Failed to get switch_comp ETS configuration %u", hw->aq.asq_last_status);
 		return ret;
 	}
 	memset(&bw_query, 0, sizeof(bw_query));
 	ret = i40e_aq_query_switch_comp_bw_config(hw, veb->seid,
 						  &bw_query, NULL);
 	if (ret != I40E_SUCCESS) {
-		PMD_DRV_LOG(ERR, "Failed to get switch_comp bandwidth"
-				 " configuration %u", hw->aq.asq_last_status);
+		PMD_DRV_LOG(ERR, "Failed to get switch_comp bandwidth configuration %u", hw->aq.asq_last_status);
 		return ret;
 	}
 
@@ -9217,8 +9172,7 @@ i40e_vsi_config_tc(struct i40e_vsi *vsi, uint8_t tc_map)
 	}
 	ret = i40e_aq_config_vsi_tc_bw(hw, vsi->seid, &bw_data, NULL);
 	if (ret) {
-		PMD_INIT_LOG(ERR, "AQ command Config VSI BW allocation"
-			" per TC failed = %d",
+		PMD_INIT_LOG(ERR, "AQ command Config VSI BW allocation per TC failed = %d",
 			hw->aq.asq_last_status);
 		goto out;
 	}
@@ -9239,8 +9193,7 @@ i40e_vsi_config_tc(struct i40e_vsi *vsi, uint8_t tc_map)
 	/* Update the VSI after updating the VSI queue-mapping information */
 	ret = i40e_aq_update_vsi_params(hw, &ctxt, NULL);
 	if (ret) {
-		PMD_INIT_LOG(ERR, "Failed to configure "
-			    "TC queue mapping = %d",
+		PMD_INIT_LOG(ERR, "Failed to configure TC queue mapping = %d",
 			    hw->aq.asq_last_status);
 		goto out;
 	}
@@ -9293,8 +9246,7 @@ i40e_dcb_hw_configure(struct i40e_pf *pf,
 	/* Use the FW API if FW > v4.4*/
 	if (!(((hw->aq.fw_maj_ver == 4) && (hw->aq.fw_min_ver >= 4)) ||
 	      (hw->aq.fw_maj_ver >= 5))) {
-		PMD_INIT_LOG(ERR, "FW < v4.4, can not use FW LLDP API"
-				  " to configure DCB");
+		PMD_INIT_LOG(ERR, "FW < v4.4, can not use FW LLDP API to configure DCB");
 		return I40E_ERR_FIRMWARE_API_VERSION;
 	}
 
@@ -9421,14 +9373,12 @@ i40e_dcb_init_configure(struct rte_eth_dev *dev, bool sw_dcb)
 						I40E_APP_PROTOID_FCOE;
 			ret = i40e_set_dcb_config(hw);
 			if (ret) {
-				PMD_INIT_LOG(ERR, "default dcb config fails."
-					" err = %d, aq_err = %d.", ret,
+				PMD_INIT_LOG(ERR, "default dcb config fails. err = %d, aq_err = %d.", ret,
 					  hw->aq.asq_last_status);
 				return -ENOSYS;
 			}
 		} else {
-			PMD_INIT_LOG(ERR, "DCB initialization in FW fails,"
-					  " err = %d, aq_err = %d.", ret,
+			PMD_INIT_LOG(ERR, "DCB initialization in FW fails, err = %d, aq_err = %d.", ret,
 					  hw->aq.asq_last_status);
 			return -ENOTSUP;
 		}
@@ -9440,13 +9390,11 @@ i40e_dcb_init_configure(struct rte_eth_dev *dev, bool sw_dcb)
 		ret = i40e_init_dcb(hw);
 		if (!ret) {
 			if (hw->dcbx_status == I40E_DCBX_STATUS_DISABLED) {
-				PMD_INIT_LOG(ERR, "HW doesn't support"
-						  " DCBX offload.");
+				PMD_INIT_LOG(ERR, "HW doesn't support DCBX offload.");
 				return -ENOTSUP;
 			}
 		} else {
-			PMD_INIT_LOG(ERR, "DCBX configuration failed, err = %d,"
-					  " aq_err = %d.", ret,
+			PMD_INIT_LOG(ERR, "DCBX configuration failed, err = %d, aq_err = %d.", ret,
 					  hw->aq.asq_last_status);
 			return -ENOTSUP;
 		}
-- 
2.10.2

Re: [dpdk-dev] [PATCH 13/13] i40e: improve message grepability

[Wu, Jingjing]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> Sent: Tuesday, December 13, 2016 9:08 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH 13/13] i40e: improve message grepability
> 
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> ---
>  drivers/net/i40e/i40e_ethdev.c | 198 +++++++++++++++--------------------------
>  1 file changed, 73 insertions(+), 125 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 39fbcfe..4d73aca 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -763,8 +763,7 @@ i40e_add_tx_flow_control_drop_filter(struct i40e_pf
> *pf)
>  				pf->main_vsi_seid, 0,
>  				TRUE, NULL, NULL);
>  	if (ret)
> -		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control "
> -				  " frames from VSIs.");
> +		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control
> frames
> +from VSIs.");
>  }

You are right, it makes grep easily. But it will break the coding style "Line length is recommended to be not more than 80 characters, including comments."

Any comments from committers?

Thanks
Jingjing

Re: [dpdk-dev] [PATCH 13/13] i40e: improve message grepability

[Bruce Richardson]

On Wed, Dec 28, 2016 at 03:51:56AM +0000, Wu, Jingjing wrote:
> 
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > Sent: Tuesday, December 13, 2016 9:08 AM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH 13/13] i40e: improve message grepability
> > 
> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > ---
> >  drivers/net/i40e/i40e_ethdev.c | 198 +++++++++++++++--------------------------
> >  1 file changed, 73 insertions(+), 125 deletions(-)
> > 
> > diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> > index 39fbcfe..4d73aca 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -763,8 +763,7 @@ i40e_add_tx_flow_control_drop_filter(struct i40e_pf
> > *pf)
> >  				pf->main_vsi_seid, 0,
> >  				TRUE, NULL, NULL);
> >  	if (ret)
> > -		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control "
> > -				  " frames from VSIs.");
> > +		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control
> > frames
> > +from VSIs.");
> >  }
> 
> You are right, it makes grep easily. But it will break the coding style "Line length is recommended to be not more than 80 characters, including comments."
> 
> Any comments from committers?
> 
Being able to grep error messages is more important that having lines
wrapped at 80 characters. I believe checkpatch ignores long strings when
checking line lengths.

/Bruce

Re: [dpdk-dev] [PATCH 13/13] i40e: improve message grepability

[Thomas Monjalon]

2017-01-09 12:02, Bruce Richardson:
> On Wed, Dec 28, 2016 at 03:51:56AM +0000, Wu, Jingjing wrote:
> > 
> > 
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > > Sent: Tuesday, December 13, 2016 9:08 AM
> > > To: dev@dpdk.org
> > > Subject: [dpdk-dev] [PATCH 13/13] i40e: improve message grepability
> > > 
> > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > ---
> > >  drivers/net/i40e/i40e_ethdev.c | 198 +++++++++++++++--------------------------
> > >  1 file changed, 73 insertions(+), 125 deletions(-)
> > > 
> > > diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> > > index 39fbcfe..4d73aca 100644
> > > --- a/drivers/net/i40e/i40e_ethdev.c
> > > +++ b/drivers/net/i40e/i40e_ethdev.c
> > > @@ -763,8 +763,7 @@ i40e_add_tx_flow_control_drop_filter(struct i40e_pf
> > > *pf)
> > >  				pf->main_vsi_seid, 0,
> > >  				TRUE, NULL, NULL);
> > >  	if (ret)
> > > -		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control "
> > > -				  " frames from VSIs.");
> > > +		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control
> > > frames
> > > +from VSIs.");
> > >  }
> > 
> > You are right, it makes grep easily. But it will break the coding style "Line length is recommended to be not more than 80 characters, including comments."
> > 
> > Any comments from committers?
> > 
> Being able to grep error messages is more important that having lines
> wrapped at 80 characters. I believe checkpatch ignores long strings when
> checking line lengths.

I agree keeping strings is more important than checkpatch conformity.
Please, if checkpatch complains, try to tune the script checkpatch.sh.
There are some options to manage strings.

Re: [dpdk-dev] [PATCH 13/13] i40e: improve message grepability

[Stephen Hemminger]

On Mon, 09 Jan 2017 14:18:58 +0100
Thomas Monjalon <thomas.monjalon@6wind.com> wrote:

> 2017-01-09 12:02, Bruce Richardson:
> > On Wed, Dec 28, 2016 at 03:51:56AM +0000, Wu, Jingjing wrote:  
> > > 
> > >   
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > > > Sent: Tuesday, December 13, 2016 9:08 AM
> > > > To: dev@dpdk.org
> > > > Subject: [dpdk-dev] [PATCH 13/13] i40e: improve message grepability
> > > > 
> > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > > ---
> > > >  drivers/net/i40e/i40e_ethdev.c | 198 +++++++++++++++--------------------------
> > > >  1 file changed, 73 insertions(+), 125 deletions(-)
> > > > 
> > > > diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> > > > index 39fbcfe..4d73aca 100644
> > > > --- a/drivers/net/i40e/i40e_ethdev.c
> > > > +++ b/drivers/net/i40e/i40e_ethdev.c
> > > > @@ -763,8 +763,7 @@ i40e_add_tx_flow_control_drop_filter(struct i40e_pf
> > > > *pf)
> > > >  				pf->main_vsi_seid, 0,
> > > >  				TRUE, NULL, NULL);
> > > >  	if (ret)
> > > > -		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control "
> > > > -				  " frames from VSIs.");
> > > > +		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control
> > > > frames
> > > > +from VSIs.");
> > > >  }  
> > > 
> > > You are right, it makes grep easily. But it will break the coding style "Line length is recommended to be not more than 80 characters, including comments."
> > > 
> > > Any comments from committers?
> > >   
> > Being able to grep error messages is more important that having lines
> > wrapped at 80 characters. I believe checkpatch ignores long strings when
> > checking line lengths.  
> 
> I agree keeping strings is more important than checkpatch conformity.
> Please, if checkpatch complains, try to tune the script checkpatch.sh.
> There are some options to manage strings.

Checkpatch does not complain as long as string is on one line.

i.e
	PMD_INIT_LOG(ERR,
	             ""Failed to add filter to drop flow control frames from VSIs.");

Re: [dpdk-dev] [PATCH 13/13] i40e: improve message grepability

[Ferruh Yigit]

On 12/13/2016 1:08 AM, Michał Mirosław wrote:
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> ---

<...>

>  	if (ret)
> -		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control "
> -				  " frames from VSIs.");
> +		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control frames from VSIs.");

According latest discussion, msg integrity has priority over line
limitation.

But can you please break the lines while keeping whole msg, like:
> +		PMD_INIT_LOG(ERR,
			"Failed to add filter to drop flow control frames from VSIs.");

<...>

>  	if (ret != I40E_SUCCESS) {
> -		PMD_DRV_LOG(ERR, "Fail to debug read from "
> -			    "I40E_GL_SWT_L2TAGCTRL[%d]", reg_id);
> +		PMD_DRV_LOG(ERR, "Fail to debug read from I40E_GL_SWT_L2TAGCTRL[%d]", reg_id);

And can you wrap arguments into next line:
+		PMD_DRV_LOG(ERR,
			"Fail to debug read from I40E_GL_SWT_L2TAGCTRL[%d]",
			reg_id);

<...>

[dpdk-dev] [PATCH] i40e: improve message grepability

[Michał Mirosław]

Join message lines for easier grepping.
PRIxXX are left glued to strings as they are in other parts of the file.

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>

---
 drivers/net/i40e/i40e_ethdev.c | 308 +++++++++++++++++++++--------------------
 1 file changed, 160 insertions(+), 148 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index db2aebdb..00c15f87 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -764,8 +764,8 @@ i40e_add_tx_flow_control_drop_filter(struct i40e_pf *pf)
 				pf->main_vsi_seid, 0,
 				TRUE, NULL, NULL);
 	if (ret)
-		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control "
-				  " frames from VSIs.");
+		PMD_INIT_LOG(ERR,
+			     "Failed to add filter to drop flow control frames from VSIs.");
 }
 
 static int
@@ -967,8 +967,8 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
 	hw->back = I40E_PF_TO_ADAPTER(pf);
 	hw->hw_addr = (uint8_t *)(pci_dev->mem_resource[0].addr);
 	if (!hw->hw_addr) {
-		PMD_INIT_LOG(ERR, "Hardware is not available, "
-			     "as address is NULL");
+		PMD_INIT_LOG(ERR,
+			     "Hardware is not available, as address is NULL");
 		return -ENODEV;
 	}
 
@@ -1104,8 +1104,8 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
 	/* Set the global registers with default ether type value */
 	ret = i40e_vlan_tpid_set(dev, ETH_VLAN_TYPE_OUTER, ETHER_TYPE_VLAN);
 	if (ret != I40E_SUCCESS) {
-		PMD_INIT_LOG(ERR, "Failed to set the default outer "
-			     "VLAN ether type");
+		PMD_INIT_LOG(ERR,
+			     "Failed to set the default outer VLAN ether type");
 		goto err_setup_pf_switch;
 	}
 
@@ -1141,8 +1141,8 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
 	/* Should be after VSI initialized */
 	dev->data->mac_addrs = rte_zmalloc("i40e", len, 0);
 	if (!dev->data->mac_addrs) {
-		PMD_INIT_LOG(ERR, "Failed to allocated memory "
-					"for storing mac address");
+		PMD_INIT_LOG(ERR,
+			     "Failed to allocated memory for storing mac address");
 		goto err_mac_alloc;
 	}
 	ether_addr_copy((struct ether_addr *)hw->mac.perm_addr,
@@ -1714,8 +1714,9 @@ i40e_dev_start(struct rte_eth_dev *dev)
 				    dev->data->nb_rx_queues * sizeof(int),
 				    0);
 		if (!intr_handle->intr_vec) {
-			PMD_INIT_LOG(ERR, "Failed to allocate %d rx_queues"
-				     " intr_vec\n", dev->data->nb_rx_queues);
+			PMD_INIT_LOG(ERR,
+				"Failed to allocate %d rx_queues intr_vec\n",
+				dev->data->nb_rx_queues);
 			return -ENOMEM;
 		}
 	}
@@ -1788,8 +1789,8 @@ i40e_dev_start(struct rte_eth_dev *dev)
 		i40e_pf_enable_irq0(hw);
 
 		if (dev->data->dev_conf.intr_conf.lsc != 0)
-			PMD_INIT_LOG(INFO, "lsc won't enable because of"
-				     " no intr multiplex\n");
+			PMD_INIT_LOG(INFO,
+				"lsc won't enable because of no intr multiplex\n");
 	} else if (dev->data->dev_conf.intr_conf.lsc != 0) {
 		ret = i40e_aq_set_phy_int_mask(hw,
 					       ~(I40E_AQ_EVENT_LINK_UPDOWN |
@@ -2740,13 +2741,15 @@ i40e_vlan_tpid_set(struct rte_eth_dev *dev,
 	ret = i40e_aq_debug_read_register(hw, I40E_GL_SWT_L2TAGCTRL(reg_id),
 					  &reg_r, NULL);
 	if (ret != I40E_SUCCESS) {
-		PMD_DRV_LOG(ERR, "Fail to debug read from "
-			    "I40E_GL_SWT_L2TAGCTRL[%d]", reg_id);
+		PMD_DRV_LOG(ERR,
+			   "Fail to debug read from I40E_GL_SWT_L2TAGCTRL[%d]",
+			   reg_id);
 		ret = -EIO;
 		return ret;
 	}
-	PMD_DRV_LOG(DEBUG, "Debug read from I40E_GL_SWT_L2TAGCTRL[%d]: "
-		    "0x%08"PRIx64"", reg_id, reg_r);
+	PMD_DRV_LOG(DEBUG,
+		    "Debug read from I40E_GL_SWT_L2TAGCTRL[%d]: 0x%08"PRIx64,
+		    reg_id, reg_r);
 
 	reg_w = reg_r & (~(I40E_GL_SWT_L2TAGCTRL_ETHERTYPE_MASK));
 	reg_w |= ((uint64_t)tpid << I40E_GL_SWT_L2TAGCTRL_ETHERTYPE_SHIFT);
@@ -2760,12 +2763,14 @@ i40e_vlan_tpid_set(struct rte_eth_dev *dev,
 					   reg_w, NULL);
 	if (ret != I40E_SUCCESS) {
 		ret = -EIO;
-		PMD_DRV_LOG(ERR, "Fail to debug write to "
-			    "I40E_GL_SWT_L2TAGCTRL[%d]", reg_id);
+		PMD_DRV_LOG(ERR,
+			    "Fail to debug write to I40E_GL_SWT_L2TAGCTRL[%d]",
+			    reg_id);
 		return ret;
 	}
-	PMD_DRV_LOG(DEBUG, "Debug write 0x%08"PRIx64" to "
-		    "I40E_GL_SWT_L2TAGCTRL[%d]", reg_w, reg_id);
+	PMD_DRV_LOG(DEBUG,
+		    "Debug write 0x%08"PRIx64" to I40E_GL_SWT_L2TAGCTRL[%d]",
+		    reg_w, reg_id);
 
 	return ret;
 }
@@ -2909,8 +2914,9 @@ i40e_flow_ctrl_set(struct rte_eth_dev *dev, struct rte_eth_fc_conf *fc_conf)
 	max_high_water = I40E_RXPBSIZE >> I40E_KILOSHIFT;
 	if ((fc_conf->high_water > max_high_water) ||
 			(fc_conf->high_water < fc_conf->low_water)) {
-		PMD_INIT_LOG(ERR, "Invalid high/low water setup value in KB, "
-			"High_water must <= %d.", max_high_water);
+		PMD_INIT_LOG(ERR,
+			     "Invalid high/low water setup value in KB, High_water must be <= %d.",
+			     max_high_water);
 		return -EINVAL;
 	}
 
@@ -3082,8 +3088,8 @@ i40e_macaddr_remove(struct rte_eth_dev *dev, uint32_t index)
 				/* No VMDQ pool enabled or configured */
 				if (!(pf->flags & I40E_FLAG_VMDQ) ||
 					(i > pf->nb_cfg_vmdq_vsi)) {
-					PMD_DRV_LOG(ERR, "No VMDQ pool enabled"
-							"/configured");
+					PMD_DRV_LOG(ERR,
+						    "No VMDQ pool enabled/configured");
 					return;
 				}
 				vsi = pf->vmdq[i - 1].vsi;
@@ -3284,9 +3290,9 @@ i40e_dev_rss_reta_update(struct rte_eth_dev *dev,
 
 	if (reta_size != lut_size ||
 		reta_size > ETH_RSS_RETA_SIZE_512) {
-		PMD_DRV_LOG(ERR, "The size of hash lookup table configured "
-			"(%d) doesn't match the number hardware can supported "
-					"(%d)\n", reta_size, lut_size);
+		PMD_DRV_LOG(ERR,
+			    "The size of hash lookup table configured (%d) doesn't match the number hardware can supported (%d)\n",
+			    reta_size, lut_size);
 		return -EINVAL;
 	}
 
@@ -3325,9 +3331,9 @@ i40e_dev_rss_reta_query(struct rte_eth_dev *dev,
 
 	if (reta_size != lut_size ||
 		reta_size > ETH_RSS_RETA_SIZE_512) {
-		PMD_DRV_LOG(ERR, "The size of hash lookup table configured "
-			"(%d) doesn't match the number hardware can supported "
-					"(%d)\n", reta_size, lut_size);
+		PMD_DRV_LOG(ERR,
+			    "The size of hash lookup table configured (%d) doesn't match the number hardware can supported (%d)\n",
+			    reta_size, lut_size);
 		return -EINVAL;
 	}
 
@@ -3382,8 +3388,9 @@ i40e_allocate_dma_mem_d(__attribute__((unused)) struct i40e_hw *hw,
 	mem->va = mz->addr;
 	mem->pa = rte_mem_phy2mch(mz->memseg_id, mz->phys_addr);
 	mem->zone = (const void *)mz;
-	PMD_DRV_LOG(DEBUG, "memzone %s allocated with physical address: "
-		    "%"PRIu64, mz->name, mem->pa);
+	PMD_DRV_LOG(DEBUG,
+		    "memzone %s allocated with physical address: %"PRIu64,
+		    mz->name, mem->pa);
 
 	return I40E_SUCCESS;
 }
@@ -3400,9 +3407,9 @@ i40e_free_dma_mem_d(__attribute__((unused)) struct i40e_hw *hw,
 	if (!mem)
 		return I40E_ERR_PARAM;
 
-	PMD_DRV_LOG(DEBUG, "memzone %s to be freed with physical address: "
-		    "%"PRIu64, ((const struct rte_memzone *)mem->zone)->name,
-		    mem->pa);
+	PMD_DRV_LOG(DEBUG,
+		    "memzone %s to be freed with physical address: %"PRIu64,
+		    ((const struct rte_memzone *)mem->zone)->name, mem->pa);
 	rte_memzone_free((const struct rte_memzone *)mem->zone);
 	mem->zone = NULL;
 	mem->va = NULL;
@@ -3561,8 +3568,9 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
 		pf->flags |= I40E_FLAG_SRIOV;
 		pf->vf_nb_qps = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF;
 		pf->vf_num = pci_dev->max_vfs;
-		PMD_DRV_LOG(DEBUG, "%u VF VSIs, %u queues per VF VSI, "
-			    "in total %u queues", pf->vf_num, pf->vf_nb_qps,
+		PMD_DRV_LOG(DEBUG,
+			    "%u VF VSIs, %u queues per VF VSI, in total %u queues",
+			    pf->vf_num, pf->vf_nb_qps,
 			    pf->vf_nb_qps * pf->vf_num);
 	} else {
 		pf->vf_nb_qps = 0;
@@ -3591,14 +3599,14 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
 			if (pf->max_nb_vmdq_vsi) {
 				pf->flags |= I40E_FLAG_VMDQ;
 				pf->vmdq_nb_qps = pf->vmdq_nb_qp_max;
-				PMD_DRV_LOG(DEBUG, "%u VMDQ VSIs, %u queues "
-					    "per VMDQ VSI, in total %u queues",
+				PMD_DRV_LOG(DEBUG,
+					    "%u VMDQ VSIs, %u queues per VMDQ VSI, in total %u queues",
 					    pf->max_nb_vmdq_vsi,
 					    pf->vmdq_nb_qps, pf->vmdq_nb_qps *
 					    pf->max_nb_vmdq_vsi);
 			} else {
-				PMD_DRV_LOG(INFO, "No enough queues left for "
-					    "VMDq");
+				PMD_DRV_LOG(INFO,
+					    "No enough queues left for VMDq");
 			}
 		} else {
 			PMD_DRV_LOG(INFO, "No queue or VSI left for VMDq");
@@ -3611,15 +3619,15 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
 		pf->flags |= I40E_FLAG_DCB;
 
 	if (qp_count > hw->func_caps.num_tx_qp) {
-		PMD_DRV_LOG(ERR, "Failed to allocate %u queues, which exceeds "
-			    "the hardware maximum %u", qp_count,
-			    hw->func_caps.num_tx_qp);
+		PMD_DRV_LOG(ERR,
+			    "Failed to allocate %u queues, which exceeds the hardware maximum %u",
+			    qp_count, hw->func_caps.num_tx_qp);
 		return -EINVAL;
 	}
 	if (vsi_count > hw->func_caps.num_vsis) {
-		PMD_DRV_LOG(ERR, "Failed to allocate %u VSIs, which exceeds "
-			    "the hardware maximum %u", vsi_count,
-			    hw->func_caps.num_vsis);
+		PMD_DRV_LOG(ERR,
+			    "Failed to allocate %u VSIs, which exceeds the hardware maximum %u",
+			    vsi_count, hw->func_caps.num_vsis);
 		return -EINVAL;
 	}
 
@@ -3865,8 +3873,8 @@ i40e_res_pool_alloc(struct i40e_res_pool_info *pool,
 		 */
 		entry = rte_zmalloc("res_pool", sizeof(*entry), 0);
 		if (entry == NULL) {
-			PMD_DRV_LOG(ERR, "Failed to allocate memory for "
-				    "resource pool");
+			PMD_DRV_LOG(ERR,
+				    "Failed to allocate memory for resource pool");
 			return -ENOMEM;
 		}
 		entry->base = valid_entry->base;
@@ -3906,9 +3914,9 @@ validate_tcmap_parameter(struct i40e_vsi *vsi, uint8_t enabled_tcmap)
 	}
 
 	if (!bitmap_is_subset(hw->func_caps.enabled_tcmap, enabled_tcmap)) {
-		PMD_DRV_LOG(ERR, "Enabled TC map 0x%x not applicable to "
-			    "HW support 0x%x", hw->func_caps.enabled_tcmap,
-			    enabled_tcmap);
+		PMD_DRV_LOG(ERR,
+			    "Enabled TC map 0x%x not applicable to HW support 0x%x",
+			    hw->func_caps.enabled_tcmap, enabled_tcmap);
 		return I40E_NOT_SUPPORTED;
 	}
 	return I40E_SUCCESS;
@@ -4250,8 +4258,8 @@ i40e_update_default_filter_setting(struct i40e_vsi *vsi)
 		struct i40e_mac_filter *f;
 		struct ether_addr *mac;
 
-		PMD_DRV_LOG(WARNING, "Cannot remove the default "
-			    "macvlan filter");
+		PMD_DRV_LOG(WARNING,
+			    "Cannot remove the default macvlan filter");
 		/* It needs to add the permanent mac into mac list */
 		f = rte_zmalloc("macv_filter", sizeof(*f), 0);
 		if (f == NULL) {
@@ -4301,8 +4309,9 @@ i40e_vsi_get_bw_config(struct i40e_vsi *vsi)
 	ret = i40e_aq_query_vsi_ets_sla_config(hw, vsi->seid,
 					&ets_sla_config, NULL);
 	if (ret != I40E_SUCCESS) {
-		PMD_DRV_LOG(ERR, "VSI failed to get TC bandwdith "
-			    "configuration %u", hw->aq.asq_last_status);
+		PMD_DRV_LOG(ERR,
+			    "VSI failed to get TC bandwdith configuration %u",
+			    hw->aq.asq_last_status);
 		return ret;
 	}
 
@@ -4390,14 +4399,14 @@ i40e_vsi_setup(struct i40e_pf *pf,
 
 	if (type != I40E_VSI_MAIN && type != I40E_VSI_SRIOV &&
 	    uplink_vsi == NULL) {
-		PMD_DRV_LOG(ERR, "VSI setup failed, "
-			    "VSI link shouldn't be NULL");
+		PMD_DRV_LOG(ERR,
+			    "VSI setup failed, VSI link shouldn't be NULL");
 		return NULL;
 	}
 
 	if (type == I40E_VSI_MAIN && uplink_vsi != NULL) {
-		PMD_DRV_LOG(ERR, "VSI setup failed, MAIN VSI "
-			    "uplink VSI should be NULL");
+		PMD_DRV_LOG(ERR,
+			    "VSI setup failed, MAIN VSI uplink VSI should be NULL");
 		return NULL;
 	}
 
@@ -4548,8 +4557,8 @@ i40e_vsi_setup(struct i40e_pf *pf,
 		ret = i40e_vsi_config_tc_queue_mapping(vsi, &ctxt.info,
 						I40E_DEFAULT_TCMAP);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to configure "
-				    "TC queue mapping");
+			PMD_DRV_LOG(ERR,
+				    "Failed to configure TC queue mapping");
 			goto fail_msix_alloc;
 		}
 		ctxt.seid = vsi->seid;
@@ -4619,8 +4628,8 @@ i40e_vsi_setup(struct i40e_pf *pf,
 		ret = i40e_vsi_config_tc_queue_mapping(vsi, &ctxt.info,
 						I40E_DEFAULT_TCMAP);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to configure "
-				    "TC queue mapping");
+			PMD_DRV_LOG(ERR,
+				    "Failed to configure TC queue mapping");
 			goto fail_msix_alloc;
 		}
 		ctxt.info.up_enable_bits = I40E_DEFAULT_TCMAP;
@@ -4662,8 +4671,8 @@ i40e_vsi_setup(struct i40e_pf *pf,
 		ret = i40e_vsi_config_tc_queue_mapping(vsi, &ctxt.info,
 						I40E_DEFAULT_TCMAP);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to configure "
-					"TC queue mapping");
+			PMD_DRV_LOG(ERR,
+				    "Failed to configure TC queue mapping");
 			goto fail_msix_alloc;
 		}
 		ctxt.info.up_enable_bits = I40E_DEFAULT_TCMAP;
@@ -4680,8 +4689,8 @@ i40e_vsi_setup(struct i40e_pf *pf,
 		ret = i40e_vsi_config_tc_queue_mapping(vsi, &ctxt.info,
 						I40E_DEFAULT_TCMAP);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to configure "
-					"TC queue mapping.");
+			PMD_DRV_LOG(ERR,
+				    "Failed to configure TC queue mapping.");
 			goto fail_msix_alloc;
 		}
 		ctxt.info.up_enable_bits = I40E_DEFAULT_TCMAP;
@@ -4944,8 +4953,9 @@ i40e_pf_setup(struct i40e_pf *pf)
 		/* make queue allocated first, let FDIR use queue pair 0*/
 		ret = i40e_res_pool_alloc(&pf->qp_pool, I40E_DEFAULT_QP_NUM_FDIR);
 		if (ret != I40E_FDIR_QUEUE_ID) {
-			PMD_DRV_LOG(ERR, "queue allocation fails for FDIR :"
-				    " ret =%d", ret);
+			PMD_DRV_LOG(ERR,
+				    "queue allocation fails for FDIR: ret =%d",
+				    ret);
 			pf->flags &= ~I40E_FLAG_FDIR;
 		}
 	}
@@ -4968,8 +4978,8 @@ i40e_pf_setup(struct i40e_pf *pf)
 						hw->func_caps.rss_table_size);
 		return I40E_ERR_PARAM;
 	}
-	PMD_DRV_LOG(INFO, "Hardware capability of hash lookup table "
-			"size: %u\n", hw->func_caps.rss_table_size);
+	PMD_DRV_LOG(INFO, "Hardware capability of hash lookup table size: %u\n",
+		    hw->func_caps.rss_table_size);
 	pf->hash_lut_size = hw->func_caps.rss_table_size;
 
 	/* Enable ethtype and macvlan filters */
@@ -5219,8 +5229,8 @@ i40e_dev_rx_init(struct i40e_pf *pf)
 
 		ret = i40e_rx_queue_init(rxq);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to do RX queue "
-				    "initialization");
+			PMD_DRV_LOG(ERR,
+				    "Failed to do RX queue initialization");
 			break;
 		}
 	}
@@ -5504,8 +5514,9 @@ i40e_dev_handle_aq_msg(struct rte_eth_dev *dev)
 		ret = i40e_clean_arq_element(hw, &info, &pending);
 
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(INFO, "Failed to read msg from AdminQ, "
-				    "aq_err: %u", hw->aq.asq_last_status);
+			PMD_DRV_LOG(INFO,
+				    "Failed to read msg from AdminQ, aq_err: %u",
+				    hw->aq.asq_last_status);
 			break;
 		}
 		opcode = rte_le_to_cpu_16(info.desc.opcode);
@@ -5822,8 +5833,8 @@ i40e_find_all_vlan_for_mac(struct i40e_vsi *vsi,
 			for (k = 0; k < I40E_UINT32_BIT_SIZE; k++) {
 				if (vsi->vfta[j] & (1 << k)) {
 					if (i > num - 1) {
-						PMD_DRV_LOG(ERR, "vlan number "
-							    "not match");
+						PMD_DRV_LOG(ERR,
+							    "vlan number doesn't match");
 						return I40E_ERR_PARAM;
 					}
 					(void)rte_memcpy(&mv_f[i].macaddr,
@@ -6304,8 +6315,7 @@ i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t key_len)
 
 		ret = i40e_aq_set_rss_key(hw, vsi->vsi_id, key_dw);
 		if (ret)
-			PMD_INIT_LOG(ERR, "Failed to configure RSS key "
-				     "via AQ");
+			PMD_INIT_LOG(ERR, "Failed to configure RSS key via AQ");
 	} else {
 		uint32_t *hash_key = (uint32_t *)key;
 		uint16_t i;
@@ -6569,8 +6579,9 @@ i40e_add_vxlan_port(struct i40e_pf *pf, uint16_t port)
 	/* Now check if there is space to add the new port */
 	idx = i40e_get_vxlan_port_idx(pf, 0);
 	if (idx < 0) {
-		PMD_DRV_LOG(ERR, "Maximum number of UDP ports reached,"
-			"not adding port %d", port);
+		PMD_DRV_LOG(ERR,
+			    "Maximum number of UDP ports reached, not adding port %d",
+			    port);
 		return -ENOSPC;
 	}
 
@@ -6941,15 +6952,15 @@ i40e_set_symmetric_hash_enable_per_port(struct i40e_hw *hw, uint8_t enable)
 
 	if (enable > 0) {
 		if (reg & I40E_PRTQF_CTL_0_HSYM_ENA_MASK) {
-			PMD_DRV_LOG(INFO, "Symmetric hash has already "
-							"been enabled");
+			PMD_DRV_LOG(INFO,
+				    "Symmetric hash has already been enabled");
 			return;
 		}
 		reg |= I40E_PRTQF_CTL_0_HSYM_ENA_MASK;
 	} else {
 		if (!(reg & I40E_PRTQF_CTL_0_HSYM_ENA_MASK)) {
-			PMD_DRV_LOG(INFO, "Symmetric hash has already "
-							"been disabled");
+			PMD_DRV_LOG(INFO,
+				    "Symmetric hash has already been disabled");
 			return;
 		}
 		reg &= ~I40E_PRTQF_CTL_0_HSYM_ENA_MASK;
@@ -7073,16 +7084,16 @@ i40e_set_hash_filter_global_config(struct i40e_hw *hw,
 	if (g_cfg->hash_func == RTE_ETH_HASH_FUNCTION_TOEPLITZ) {
 		/* Toeplitz */
 		if (reg & I40E_GLQF_CTL_HTOEP_MASK) {
-			PMD_DRV_LOG(DEBUG, "Hash function already set to "
-								"Toeplitz");
+			PMD_DRV_LOG(DEBUG,
+				    "Hash function already set to Toeplitz");
 			goto out;
 		}
 		reg |= I40E_GLQF_CTL_HTOEP_MASK;
 	} else if (g_cfg->hash_func == RTE_ETH_HASH_FUNCTION_SIMPLE_XOR) {
 		/* Simple XOR */
 		if (!(reg & I40E_GLQF_CTL_HTOEP_MASK)) {
-			PMD_DRV_LOG(DEBUG, "Hash function already set to "
-							"Simple XOR");
+			PMD_DRV_LOG(DEBUG,
+				    "Hash function already set to Simple XOR");
 			goto out;
 		}
 		reg &= ~I40E_GLQF_CTL_HTOEP_MASK;
@@ -8030,13 +8041,14 @@ i40e_ethertype_filter_set(struct i40e_pf *pf,
 	}
 	if (filter->ether_type == ETHER_TYPE_IPv4 ||
 		filter->ether_type == ETHER_TYPE_IPv6) {
-		PMD_DRV_LOG(ERR, "unsupported ether_type(0x%04x) in"
-			" control packet filter.", filter->ether_type);
+		PMD_DRV_LOG(ERR,
+			    "unsupported ether_type(0x%04x) in control packet filter.",
+			    filter->ether_type);
 		return -EINVAL;
 	}
 	if (filter->ether_type == ETHER_TYPE_VLAN)
-		PMD_DRV_LOG(WARNING, "filter vlan ether_type in first tag is"
-			" not supported.");
+		PMD_DRV_LOG(WARNING,
+			    "filter vlan ether_type in first tag is not supported.");
 
 	if (!(filter->flags & RTE_ETHTYPE_FLAGS_MAC))
 		flags |= I40E_AQC_ADD_CONTROL_PACKET_FLAGS_IGNORE_MAC;
@@ -8051,11 +8063,10 @@ i40e_ethertype_filter_set(struct i40e_pf *pf,
 			pf->main_vsi->seid,
 			filter->queue, add, &stats, NULL);
 
-	PMD_DRV_LOG(INFO, "add/rem control packet filter, return %d,"
-			 " mac_etype_used = %u, etype_used = %u,"
-			 " mac_etype_free = %u, etype_free = %u\n",
-			 ret, stats.mac_etype_used, stats.etype_used,
-			 stats.mac_etype_free, stats.etype_free);
+	PMD_DRV_LOG(INFO,
+		    "add/rem control packet filter, return %d, mac_etype_used = %u, etype_used = %u, mac_etype_free = %u, etype_free = %u\n",
+		    ret, stats.mac_etype_used, stats.etype_used,
+		    stats.mac_etype_free, stats.etype_free);
 	if (ret < 0)
 		return -ENOSYS;
 	return 0;
@@ -8364,9 +8375,9 @@ i40e_configure_registers(struct i40e_hw *hw)
 		ret = i40e_aq_debug_write_register(hw, reg_table[i].addr,
 						reg_table[i].val, NULL);
 		if (ret < 0) {
-			PMD_DRV_LOG(ERR, "Failed to write 0x%"PRIx64" to the "
-				"address of 0x%"PRIx32, reg_table[i].val,
-							reg_table[i].addr);
+			PMD_DRV_LOG(ERR,
+				    "Failed to write 0x%"PRIx64" to the address of 0x%"PRIx32,
+				    reg_table[i].val, reg_table[i].addr);
 			break;
 		}
 		PMD_DRV_LOG(DEBUG, "Write 0x%"PRIx64" to the address of "
@@ -8411,8 +8422,9 @@ i40e_config_qinq(struct i40e_hw *hw, struct i40e_vsi *vsi)
 						   I40E_VSI_L2TAGSTXVALID(
 						   vsi->vsi_id), reg, NULL);
 		if (ret < 0) {
-			PMD_DRV_LOG(ERR, "Failed to update "
-				"VSI_L2TAGSTXVALID[%d]", vsi->vsi_id);
+			PMD_DRV_LOG(ERR,
+				    "Failed to update VSI_L2TAGSTXVALID[%d]",
+				    vsi->vsi_id);
 			return I40E_ERR_CONFIG;
 		}
 	}
@@ -8463,11 +8475,10 @@ i40e_aq_add_mirror_rule(struct i40e_hw *hw,
 
 	rte_memcpy(&desc.params.raw, &cmd, sizeof(cmd));
 	status = i40e_asq_send_command(hw, &desc, entries, buff_len, NULL);
-	PMD_DRV_LOG(INFO, "i40e_aq_add_mirror_rule, aq_status %d,"
-			 "rule_id = %u"
-			 " mirror_rules_used = %u, mirror_rules_free = %u,",
-			 hw->aq.asq_last_status, resp->rule_id,
-			 resp->mirror_rules_used, resp->mirror_rules_free);
+	PMD_DRV_LOG(INFO,
+		    "i40e_aq_add_mirror_rule, aq_status %d, rule_id = %u mirror_rules_used = %u, mirror_rules_free = %u,",
+		    hw->aq.asq_last_status, resp->rule_id,
+		    resp->mirror_rules_used, resp->mirror_rules_free);
 	*rule_id = rte_le_to_cpu_16(resp->rule_id);
 
 	return status;
@@ -8545,8 +8556,8 @@ i40e_mirror_rule_set(struct rte_eth_dev *dev,
 	PMD_DRV_LOG(DEBUG, "i40e_mirror_rule_set: sw_id = %d.", sw_id);
 
 	if (pf->main_vsi->veb == NULL || pf->vfs == NULL) {
-		PMD_DRV_LOG(ERR, "mirror rule can not be configured"
-			" without veb or vfs.");
+		PMD_DRV_LOG(ERR,
+			    "mirror rule can not be configured without veb or vfs.");
 		return -ENOSYS;
 	}
 	if (pf->nb_mirror_rule > I40E_MAX_MIRROR_RULES) {
@@ -8578,9 +8589,9 @@ i40e_mirror_rule_set(struct rte_eth_dev *dev,
 					mirr_rule->entries,
 					mirr_rule->num_entries, mirr_rule->id);
 			if (ret < 0) {
-				PMD_DRV_LOG(ERR, "failed to remove mirror rule:"
-						   " ret = %d, aq_err = %d.",
-						   ret, hw->aq.asq_last_status);
+				PMD_DRV_LOG(ERR,
+					    "failed to remove mirror rule: ret = %d, aq_err = %d.",
+					    ret, hw->aq.asq_last_status);
 				return -ENOSYS;
 			}
 			TAILQ_REMOVE(&pf->mirror_list, mirr_rule, rules);
@@ -8669,9 +8680,9 @@ i40e_mirror_rule_set(struct rte_eth_dev *dev,
 				      mirr_rule->rule_type, mirr_rule->entries,
 				      j, &rule_id);
 	if (ret < 0) {
-		PMD_DRV_LOG(ERR, "failed to add mirror rule:"
-				   " ret = %d, aq_err = %d.",
-				   ret, hw->aq.asq_last_status);
+		PMD_DRV_LOG(ERR,
+			    "failed to add mirror rule: ret = %d, aq_err = %d.",
+			    ret, hw->aq.asq_last_status);
 		rte_free(mirr_rule);
 		return -ENOSYS;
 	}
@@ -8723,9 +8734,9 @@ i40e_mirror_rule_reset(struct rte_eth_dev *dev, uint8_t sw_id)
 				mirr_rule->entries,
 				mirr_rule->num_entries, mirr_rule->id);
 		if (ret < 0) {
-			PMD_DRV_LOG(ERR, "failed to remove mirror rule:"
-					   " status = %d, aq_err = %d.",
-					   ret, hw->aq.asq_last_status);
+			PMD_DRV_LOG(ERR,
+				    "failed to remove mirror rule: status = %d, aq_err = %d.",
+				    ret, hw->aq.asq_last_status);
 			return -ENOSYS;
 		}
 		TAILQ_REMOVE(&pf->mirror_list, mirr_rule, rules);
@@ -9157,9 +9168,9 @@ i40e_config_switch_comp_tc(struct i40e_veb *veb, uint8_t tc_map)
 	ret = i40e_aq_config_switch_comp_bw_config(hw, veb->seid,
 						   &veb_bw, NULL);
 	if (ret) {
-		PMD_INIT_LOG(ERR, "AQ command Config switch_comp BW allocation"
-				  " per TC failed = %d",
-				  hw->aq.asq_last_status);
+		PMD_INIT_LOG(ERR,
+			     "AQ command Config switch_comp BW allocation per TC failed = %d",
+			     hw->aq.asq_last_status);
 		return ret;
 	}
 
@@ -9167,16 +9178,18 @@ i40e_config_switch_comp_tc(struct i40e_veb *veb, uint8_t tc_map)
 	ret = i40e_aq_query_switch_comp_ets_config(hw, veb->seid,
 						   &ets_query, NULL);
 	if (ret != I40E_SUCCESS) {
-		PMD_DRV_LOG(ERR, "Failed to get switch_comp ETS"
-				 " configuration %u", hw->aq.asq_last_status);
+		PMD_DRV_LOG(ERR,
+			    "Failed to get switch_comp ETS configuration %u",
+			    hw->aq.asq_last_status);
 		return ret;
 	}
 	memset(&bw_query, 0, sizeof(bw_query));
 	ret = i40e_aq_query_switch_comp_bw_config(hw, veb->seid,
 						  &bw_query, NULL);
 	if (ret != I40E_SUCCESS) {
-		PMD_DRV_LOG(ERR, "Failed to get switch_comp bandwidth"
-				 " configuration %u", hw->aq.asq_last_status);
+		PMD_DRV_LOG(ERR,
+			    "Failed to get switch_comp bandwidth configuration %u",
+			    hw->aq.asq_last_status);
 		return ret;
 	}
 
@@ -9241,9 +9254,9 @@ i40e_vsi_config_tc(struct i40e_vsi *vsi, uint8_t tc_map)
 	}
 	ret = i40e_aq_config_vsi_tc_bw(hw, vsi->seid, &bw_data, NULL);
 	if (ret) {
-		PMD_INIT_LOG(ERR, "AQ command Config VSI BW allocation"
-			" per TC failed = %d",
-			hw->aq.asq_last_status);
+		PMD_INIT_LOG(ERR,
+			     "AQ command Config VSI BW allocation per TC failed = %d",
+			     hw->aq.asq_last_status);
 		goto out;
 	}
 	for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++)
@@ -9263,9 +9276,8 @@ i40e_vsi_config_tc(struct i40e_vsi *vsi, uint8_t tc_map)
 	/* Update the VSI after updating the VSI queue-mapping information */
 	ret = i40e_aq_update_vsi_params(hw, &ctxt, NULL);
 	if (ret) {
-		PMD_INIT_LOG(ERR, "Failed to configure "
-			    "TC queue mapping = %d",
-			    hw->aq.asq_last_status);
+		PMD_INIT_LOG(ERR, "Failed to configure TC queue mapping = %d",
+			     hw->aq.asq_last_status);
 		goto out;
 	}
 	/* update the local VSI info with updated queue map */
@@ -9317,8 +9329,8 @@ i40e_dcb_hw_configure(struct i40e_pf *pf,
 	/* Use the FW API if FW > v4.4*/
 	if (!(((hw->aq.fw_maj_ver == 4) && (hw->aq.fw_min_ver >= 4)) ||
 	      (hw->aq.fw_maj_ver >= 5))) {
-		PMD_INIT_LOG(ERR, "FW < v4.4, can not use FW LLDP API"
-				  " to configure DCB");
+		PMD_INIT_LOG(ERR,
+			     "FW < v4.4, can not use FW LLDP API to configure DCB");
 		return I40E_ERR_FIRMWARE_API_VERSION;
 	}
 
@@ -9384,8 +9396,8 @@ i40e_dcb_hw_configure(struct i40e_pf *pf,
 							 I40E_DEFAULT_TCMAP);
 			if (ret)
 				PMD_INIT_LOG(WARNING,
-					 "Failed configuring TC for VSI seid=%d\n",
-					 vsi_list->vsi->seid);
+					     "Failed configuring TC for VSI seid=%d\n",
+					     vsi_list->vsi->seid);
 			/* continue */
 		}
 	}
@@ -9445,15 +9457,15 @@ i40e_dcb_init_configure(struct rte_eth_dev *dev, bool sw_dcb)
 						I40E_APP_PROTOID_FCOE;
 			ret = i40e_set_dcb_config(hw);
 			if (ret) {
-				PMD_INIT_LOG(ERR, "default dcb config fails."
-					" err = %d, aq_err = %d.", ret,
-					  hw->aq.asq_last_status);
+				PMD_INIT_LOG(ERR,
+					     "default dcb config fails. err = %d, aq_err = %d.",
+					     ret, hw->aq.asq_last_status);
 				return -ENOSYS;
 			}
 		} else {
-			PMD_INIT_LOG(ERR, "DCB initialization in FW fails,"
-					  " err = %d, aq_err = %d.", ret,
-					  hw->aq.asq_last_status);
+			PMD_INIT_LOG(ERR,
+				     "DCB initialization in FW fails, err = %d, aq_err = %d.",
+				     ret, hw->aq.asq_last_status);
 			return -ENOTSUP;
 		}
 	} else {
@@ -9464,14 +9476,14 @@ i40e_dcb_init_configure(struct rte_eth_dev *dev, bool sw_dcb)
 		ret = i40e_init_dcb(hw);
 		if (!ret) {
 			if (hw->dcbx_status == I40E_DCBX_STATUS_DISABLED) {
-				PMD_INIT_LOG(ERR, "HW doesn't support"
-						  " DCBX offload.");
+				PMD_INIT_LOG(ERR,
+					     "HW doesn't support DCBX offload.");
 				return -ENOTSUP;
 			}
 		} else {
-			PMD_INIT_LOG(ERR, "DCBX configuration failed, err = %d,"
-					  " aq_err = %d.", ret,
-					  hw->aq.asq_last_status);
+			PMD_INIT_LOG(ERR,
+				     "DCBX configuration failed, err = %d, aq_err = %d.",
+				     ret, hw->aq.asq_last_status);
 			return -ENOTSUP;
 		}
 	}
-- 
2.11.0

Re: [dpdk-dev] [PATCH] i40e: improve message grepability

[Ferruh Yigit]

On 1/11/2017 9:49 AM, Michał Mirosław wrote:
> Join message lines for easier grepping.
> PRIxXX are left glued to strings as they are in other parts of the file.

I can't apply this cleanly, would you mind rebasing on top of latest
next-net?

Also there is a minor nit below.

Thanks,
ferruh

> 
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> 
> ---
>  drivers/net/i40e/i40e_ethdev.c | 308 +++++++++++++++++++++--------------------
>  1 file changed, 160 insertions(+), 148 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index db2aebdb..00c15f87 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -764,8 +764,8 @@ i40e_add_tx_flow_control_drop_filter(struct i40e_pf *pf)
>  				pf->main_vsi_seid, 0,
>  				TRUE, NULL, NULL);
>  	if (ret)
> -		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control "
> -				  " frames from VSIs.");
> +		PMD_INIT_LOG(ERR,
> +			     "Failed to add filter to drop flow control frames from VSIs.");

Most messages aligned to "(", but single tab can give more room for the
msg (4 more chars J), and tab is preferred one according DPDK coding
convention.

I don't have a strong opinion, what do you think?

<...>
> @@ -1788,8 +1789,8 @@ i40e_dev_start(struct rte_eth_dev *dev)
>  		i40e_pf_enable_irq0(hw);
>  
>  		if (dev->data->dev_conf.intr_conf.lsc != 0)
> -			PMD_INIT_LOG(INFO, "lsc won't enable because of"
> -				     " no intr multiplex\n");
> +			PMD_INIT_LOG(INFO,
> +				"lsc won't enable because of no intr multiplex\n");

Like this one is using tab.

<...>

[dpdk-dev] [PATCH v3 1/1] i40e: improve message grepability

[Michał Mirosław]

From: Michał Mirosław <michal.miroslaw@atendesoftware.pl>

Join message lines for easier grepping.
PRIxXX are left glued to strings as they are in other parts of the file.

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
v2: move long strings on a line by themselves
v3: indent modified lines with TAB only

Change-Id: Idbaa3392d8112f96a9f15818f6ee1b5174a50c87
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
 drivers/net/i40e/i40e_ethdev.c | 312 +++++++++++++++++++++--------------------
 1 file changed, 161 insertions(+), 151 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 24a3ac806..95be29df0 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -719,8 +719,8 @@ i40e_add_tx_flow_control_drop_filter(struct i40e_pf *pf)
 				pf->main_vsi_seid, 0,
 				TRUE, NULL, NULL);
 	if (ret)
-		PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control "
-				  " frames from VSIs.");
+		PMD_INIT_LOG(ERR,
+			"Failed to add filter to drop flow control frames from VSIs.");
 }
 
 static int
@@ -1050,8 +1050,8 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
 	hw->back = I40E_PF_TO_ADAPTER(pf);
 	hw->hw_addr = (uint8_t *)(pci_dev->mem_resource[0].addr);
 	if (!hw->hw_addr) {
-		PMD_INIT_LOG(ERR, "Hardware is not available, "
-			     "as address is NULL");
+		PMD_INIT_LOG(ERR,
+			"Hardware is not available, as address is NULL");
 		return -ENODEV;
 	}
 
@@ -1187,8 +1187,8 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
 	/* Set the global registers with default ether type value */
 	ret = i40e_vlan_tpid_set(dev, ETH_VLAN_TYPE_OUTER, ETHER_TYPE_VLAN);
 	if (ret != I40E_SUCCESS) {
-		PMD_INIT_LOG(ERR, "Failed to set the default outer "
-			     "VLAN ether type");
+		PMD_INIT_LOG(ERR,
+			"Failed to set the default outer VLAN ether type");
 		goto err_setup_pf_switch;
 	}
 
@@ -1224,8 +1224,8 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
 	/* Should be after VSI initialized */
 	dev->data->mac_addrs = rte_zmalloc("i40e", len, 0);
 	if (!dev->data->mac_addrs) {
-		PMD_INIT_LOG(ERR, "Failed to allocated memory "
-					"for storing mac address");
+		PMD_INIT_LOG(ERR,
+			"Failed to allocated memory for storing mac address");
 		goto err_mac_alloc;
 	}
 	ether_addr_copy((struct ether_addr *)hw->mac.perm_addr,
@@ -1889,8 +1889,9 @@ i40e_dev_start(struct rte_eth_dev *dev)
 				    dev->data->nb_rx_queues * sizeof(int),
 				    0);
 		if (!intr_handle->intr_vec) {
-			PMD_INIT_LOG(ERR, "Failed to allocate %d rx_queues"
-				     " intr_vec\n", dev->data->nb_rx_queues);
+			PMD_INIT_LOG(ERR,
+				"Failed to allocate %d rx_queues intr_vec\n",
+				dev->data->nb_rx_queues);
 			return -ENOMEM;
 		}
 	}
@@ -1963,8 +1964,8 @@ i40e_dev_start(struct rte_eth_dev *dev)
 		i40e_pf_enable_irq0(hw);
 
 		if (dev->data->dev_conf.intr_conf.lsc != 0)
-			PMD_INIT_LOG(INFO, "lsc won't enable because of"
-				     " no intr multiplex\n");
+			PMD_INIT_LOG(INFO,
+				"lsc won't enable because of no intr multiplex\n");
 	} else if (dev->data->dev_conf.intr_conf.lsc != 0) {
 		ret = i40e_aq_set_phy_int_mask(hw,
 					       ~(I40E_AQ_EVENT_LINK_UPDOWN |
@@ -2916,13 +2917,15 @@ i40e_vlan_tpid_set(struct rte_eth_dev *dev,
 	ret = i40e_aq_debug_read_register(hw, I40E_GL_SWT_L2TAGCTRL(reg_id),
 					  &reg_r, NULL);
 	if (ret != I40E_SUCCESS) {
-		PMD_DRV_LOG(ERR, "Fail to debug read from "
-			    "I40E_GL_SWT_L2TAGCTRL[%d]", reg_id);
+		PMD_DRV_LOG(ERR,
+			   "Fail to debug read from I40E_GL_SWT_L2TAGCTRL[%d]",
+			   reg_id);
 		ret = -EIO;
 		return ret;
 	}
-	PMD_DRV_LOG(DEBUG, "Debug read from I40E_GL_SWT_L2TAGCTRL[%d]: "
-		    "0x%08"PRIx64"", reg_id, reg_r);
+	PMD_DRV_LOG(DEBUG,
+		"Debug read from I40E_GL_SWT_L2TAGCTRL[%d]: 0x%08"PRIx64,
+		reg_id, reg_r);
 
 	reg_w = reg_r & (~(I40E_GL_SWT_L2TAGCTRL_ETHERTYPE_MASK));
 	reg_w |= ((uint64_t)tpid << I40E_GL_SWT_L2TAGCTRL_ETHERTYPE_SHIFT);
@@ -2936,12 +2939,14 @@ i40e_vlan_tpid_set(struct rte_eth_dev *dev,
 					   reg_w, NULL);
 	if (ret != I40E_SUCCESS) {
 		ret = -EIO;
-		PMD_DRV_LOG(ERR, "Fail to debug write to "
-			    "I40E_GL_SWT_L2TAGCTRL[%d]", reg_id);
+		PMD_DRV_LOG(ERR,
+			"Fail to debug write to I40E_GL_SWT_L2TAGCTRL[%d]",
+			reg_id);
 		return ret;
 	}
-	PMD_DRV_LOG(DEBUG, "Debug write 0x%08"PRIx64" to "
-		    "I40E_GL_SWT_L2TAGCTRL[%d]", reg_w, reg_id);
+	PMD_DRV_LOG(DEBUG,
+		"Debug write 0x%08"PRIx64" to I40E_GL_SWT_L2TAGCTRL[%d]",
+		reg_w, reg_id);
 
 	return ret;
 }
@@ -3085,8 +3090,9 @@ i40e_flow_ctrl_set(struct rte_eth_dev *dev, struct rte_eth_fc_conf *fc_conf)
 	max_high_water = I40E_RXPBSIZE >> I40E_KILOSHIFT;
 	if ((fc_conf->high_water > max_high_water) ||
 			(fc_conf->high_water < fc_conf->low_water)) {
-		PMD_INIT_LOG(ERR, "Invalid high/low water setup value in KB, "
-			"High_water must <= %d.", max_high_water);
+		PMD_INIT_LOG(ERR,
+			"Invalid high/low water setup value in KB, High_water must be <= %d.",
+			max_high_water);
 		return -EINVAL;
 	}
 
@@ -3258,8 +3264,8 @@ i40e_macaddr_remove(struct rte_eth_dev *dev, uint32_t index)
 				/* No VMDQ pool enabled or configured */
 				if (!(pf->flags & I40E_FLAG_VMDQ) ||
 					(i > pf->nb_cfg_vmdq_vsi)) {
-					PMD_DRV_LOG(ERR, "No VMDQ pool enabled"
-							"/configured");
+					PMD_DRV_LOG(ERR,
+						"No VMDQ pool enabled/configured");
 					return;
 				}
 				vsi = pf->vmdq[i - 1].vsi;
@@ -3460,9 +3466,9 @@ i40e_dev_rss_reta_update(struct rte_eth_dev *dev,
 
 	if (reta_size != lut_size ||
 		reta_size > ETH_RSS_RETA_SIZE_512) {
-		PMD_DRV_LOG(ERR, "The size of hash lookup table configured "
-			"(%d) doesn't match the number hardware can supported "
-					"(%d)\n", reta_size, lut_size);
+		PMD_DRV_LOG(ERR,
+			"The size of hash lookup table configured (%d) doesn't match the number hardware can supported (%d)\n",
+			reta_size, lut_size);
 		return -EINVAL;
 	}
 
@@ -3501,9 +3507,9 @@ i40e_dev_rss_reta_query(struct rte_eth_dev *dev,
 
 	if (reta_size != lut_size ||
 		reta_size > ETH_RSS_RETA_SIZE_512) {
-		PMD_DRV_LOG(ERR, "The size of hash lookup table configured "
-			"(%d) doesn't match the number hardware can supported "
-					"(%d)\n", reta_size, lut_size);
+		PMD_DRV_LOG(ERR,
+			"The size of hash lookup table configured (%d) doesn't match the number hardware can supported (%d)\n",
+			reta_size, lut_size);
 		return -EINVAL;
 	}
 
@@ -3558,8 +3564,9 @@ i40e_allocate_dma_mem_d(__attribute__((unused)) struct i40e_hw *hw,
 	mem->va = mz->addr;
 	mem->pa = rte_mem_phy2mch(mz->memseg_id, mz->phys_addr);
 	mem->zone = (const void *)mz;
-	PMD_DRV_LOG(DEBUG, "memzone %s allocated with physical address: "
-		    "%"PRIu64, mz->name, mem->pa);
+	PMD_DRV_LOG(DEBUG,
+		"memzone %s allocated with physical address: %"PRIu64,
+		mz->name, mem->pa);
 
 	return I40E_SUCCESS;
 }
@@ -3576,9 +3583,9 @@ i40e_free_dma_mem_d(__attribute__((unused)) struct i40e_hw *hw,
 	if (!mem)
 		return I40E_ERR_PARAM;
 
-	PMD_DRV_LOG(DEBUG, "memzone %s to be freed with physical address: "
-		    "%"PRIu64, ((const struct rte_memzone *)mem->zone)->name,
-		    mem->pa);
+	PMD_DRV_LOG(DEBUG,
+		"memzone %s to be freed with physical address: %"PRIu64,
+		((const struct rte_memzone *)mem->zone)->name, mem->pa);
 	rte_memzone_free((const struct rte_memzone *)mem->zone);
 	mem->zone = NULL;
 	mem->va = NULL;
@@ -3737,9 +3744,9 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
 		pf->flags |= I40E_FLAG_SRIOV;
 		pf->vf_nb_qps = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF;
 		pf->vf_num = pci_dev->max_vfs;
-		PMD_DRV_LOG(DEBUG, "%u VF VSIs, %u queues per VF VSI, "
-			    "in total %u queues", pf->vf_num, pf->vf_nb_qps,
-			    pf->vf_nb_qps * pf->vf_num);
+		PMD_DRV_LOG(DEBUG,
+			"%u VF VSIs, %u queues per VF VSI, in total %u queues",
+			pf->vf_num, pf->vf_nb_qps, pf->vf_nb_qps * pf->vf_num);
 	} else {
 		pf->vf_nb_qps = 0;
 		pf->vf_num = 0;
@@ -3767,14 +3774,13 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
 			if (pf->max_nb_vmdq_vsi) {
 				pf->flags |= I40E_FLAG_VMDQ;
 				pf->vmdq_nb_qps = pf->vmdq_nb_qp_max;
-				PMD_DRV_LOG(DEBUG, "%u VMDQ VSIs, %u queues "
-					    "per VMDQ VSI, in total %u queues",
-					    pf->max_nb_vmdq_vsi,
-					    pf->vmdq_nb_qps, pf->vmdq_nb_qps *
-					    pf->max_nb_vmdq_vsi);
+				PMD_DRV_LOG(DEBUG,
+					"%u VMDQ VSIs, %u queues per VMDQ VSI, in total %u queues",
+					pf->max_nb_vmdq_vsi, pf->vmdq_nb_qps,
+					pf->vmdq_nb_qps * pf->max_nb_vmdq_vsi);
 			} else {
-				PMD_DRV_LOG(INFO, "No enough queues left for "
-					    "VMDq");
+				PMD_DRV_LOG(INFO,
+					"No enough queues left for VMDq");
 			}
 		} else {
 			PMD_DRV_LOG(INFO, "No queue or VSI left for VMDq");
@@ -3787,15 +3793,15 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
 		pf->flags |= I40E_FLAG_DCB;
 
 	if (qp_count > hw->func_caps.num_tx_qp) {
-		PMD_DRV_LOG(ERR, "Failed to allocate %u queues, which exceeds "
-			    "the hardware maximum %u", qp_count,
-			    hw->func_caps.num_tx_qp);
+		PMD_DRV_LOG(ERR,
+			"Failed to allocate %u queues, which exceeds the hardware maximum %u",
+			qp_count, hw->func_caps.num_tx_qp);
 		return -EINVAL;
 	}
 	if (vsi_count > hw->func_caps.num_vsis) {
-		PMD_DRV_LOG(ERR, "Failed to allocate %u VSIs, which exceeds "
-			    "the hardware maximum %u", vsi_count,
-			    hw->func_caps.num_vsis);
+		PMD_DRV_LOG(ERR,
+			"Failed to allocate %u VSIs, which exceeds the hardware maximum %u",
+			vsi_count, hw->func_caps.num_vsis);
 		return -EINVAL;
 	}
 
@@ -4041,8 +4047,8 @@ i40e_res_pool_alloc(struct i40e_res_pool_info *pool,
 		 */
 		entry = rte_zmalloc("res_pool", sizeof(*entry), 0);
 		if (entry == NULL) {
-			PMD_DRV_LOG(ERR, "Failed to allocate memory for "
-				    "resource pool");
+			PMD_DRV_LOG(ERR,
+				"Failed to allocate memory for resource pool");
 			return -ENOMEM;
 		}
 		entry->base = valid_entry->base;
@@ -4082,9 +4088,9 @@ validate_tcmap_parameter(struct i40e_vsi *vsi, uint8_t enabled_tcmap)
 	}
 
 	if (!bitmap_is_subset(hw->func_caps.enabled_tcmap, enabled_tcmap)) {
-		PMD_DRV_LOG(ERR, "Enabled TC map 0x%x not applicable to "
-			    "HW support 0x%x", hw->func_caps.enabled_tcmap,
-			    enabled_tcmap);
+		PMD_DRV_LOG(ERR,
+			"Enabled TC map 0x%x not applicable to HW support 0x%x",
+			hw->func_caps.enabled_tcmap, enabled_tcmap);
 		return I40E_NOT_SUPPORTED;
 	}
 	return I40E_SUCCESS;
@@ -4426,8 +4432,8 @@ i40e_update_default_filter_setting(struct i40e_vsi *vsi)
 		struct i40e_mac_filter *f;
 		struct ether_addr *mac;
 
-		PMD_DRV_LOG(WARNING, "Cannot remove the default "
-			    "macvlan filter");
+		PMD_DRV_LOG(WARNING,
+			"Cannot remove the default macvlan filter");
 		/* It needs to add the permanent mac into mac list */
 		f = rte_zmalloc("macv_filter", sizeof(*f), 0);
 		if (f == NULL) {
@@ -4477,8 +4483,9 @@ i40e_vsi_get_bw_config(struct i40e_vsi *vsi)
 	ret = i40e_aq_query_vsi_ets_sla_config(hw, vsi->seid,
 					&ets_sla_config, NULL);
 	if (ret != I40E_SUCCESS) {
-		PMD_DRV_LOG(ERR, "VSI failed to get TC bandwdith "
-			    "configuration %u", hw->aq.asq_last_status);
+		PMD_DRV_LOG(ERR,
+			"VSI failed to get TC bandwdith configuration %u",
+			hw->aq.asq_last_status);
 		return ret;
 	}
 
@@ -4566,14 +4573,14 @@ i40e_vsi_setup(struct i40e_pf *pf,
 
 	if (type != I40E_VSI_MAIN && type != I40E_VSI_SRIOV &&
 	    uplink_vsi == NULL) {
-		PMD_DRV_LOG(ERR, "VSI setup failed, "
-			    "VSI link shouldn't be NULL");
+		PMD_DRV_LOG(ERR,
+			"VSI setup failed, VSI link shouldn't be NULL");
 		return NULL;
 	}
 
 	if (type == I40E_VSI_MAIN && uplink_vsi != NULL) {
-		PMD_DRV_LOG(ERR, "VSI setup failed, MAIN VSI "
-			    "uplink VSI should be NULL");
+		PMD_DRV_LOG(ERR,
+			"VSI setup failed, MAIN VSI uplink VSI should be NULL");
 		return NULL;
 	}
 
@@ -4724,8 +4731,8 @@ i40e_vsi_setup(struct i40e_pf *pf,
 		ret = i40e_vsi_config_tc_queue_mapping(vsi, &ctxt.info,
 						I40E_DEFAULT_TCMAP);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to configure "
-				    "TC queue mapping");
+			PMD_DRV_LOG(ERR,
+				"Failed to configure TC queue mapping");
 			goto fail_msix_alloc;
 		}
 		ctxt.seid = vsi->seid;
@@ -4795,8 +4802,8 @@ i40e_vsi_setup(struct i40e_pf *pf,
 		ret = i40e_vsi_config_tc_queue_mapping(vsi, &ctxt.info,
 						I40E_DEFAULT_TCMAP);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to configure "
-				    "TC queue mapping");
+			PMD_DRV_LOG(ERR,
+				"Failed to configure TC queue mapping");
 			goto fail_msix_alloc;
 		}
 		ctxt.info.up_enable_bits = I40E_DEFAULT_TCMAP;
@@ -4838,8 +4845,8 @@ i40e_vsi_setup(struct i40e_pf *pf,
 		ret = i40e_vsi_config_tc_queue_mapping(vsi, &ctxt.info,
 						I40E_DEFAULT_TCMAP);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to configure "
-					"TC queue mapping");
+			PMD_DRV_LOG(ERR,
+				"Failed to configure TC queue mapping");
 			goto fail_msix_alloc;
 		}
 		ctxt.info.up_enable_bits = I40E_DEFAULT_TCMAP;
@@ -4856,8 +4863,8 @@ i40e_vsi_setup(struct i40e_pf *pf,
 		ret = i40e_vsi_config_tc_queue_mapping(vsi, &ctxt.info,
 						I40E_DEFAULT_TCMAP);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to configure "
-					"TC queue mapping.");
+			PMD_DRV_LOG(ERR,
+				"Failed to configure TC queue mapping.");
 			goto fail_msix_alloc;
 		}
 		ctxt.info.up_enable_bits = I40E_DEFAULT_TCMAP;
@@ -5120,8 +5127,9 @@ i40e_pf_setup(struct i40e_pf *pf)
 		/* make queue allocated first, let FDIR use queue pair 0*/
 		ret = i40e_res_pool_alloc(&pf->qp_pool, I40E_DEFAULT_QP_NUM_FDIR);
 		if (ret != I40E_FDIR_QUEUE_ID) {
-			PMD_DRV_LOG(ERR, "queue allocation fails for FDIR :"
-				    " ret =%d", ret);
+			PMD_DRV_LOG(ERR,
+				"queue allocation fails for FDIR: ret =%d",
+				ret);
 			pf->flags &= ~I40E_FLAG_FDIR;
 		}
 	}
@@ -5144,8 +5152,8 @@ i40e_pf_setup(struct i40e_pf *pf)
 						hw->func_caps.rss_table_size);
 		return I40E_ERR_PARAM;
 	}
-	PMD_DRV_LOG(INFO, "Hardware capability of hash lookup table "
-			"size: %u\n", hw->func_caps.rss_table_size);
+	PMD_DRV_LOG(INFO, "Hardware capability of hash lookup table size: %u\n",
+		hw->func_caps.rss_table_size);
 	pf->hash_lut_size = hw->func_caps.rss_table_size;
 
 	/* Enable ethtype and macvlan filters */
@@ -5395,8 +5403,8 @@ i40e_dev_rx_init(struct i40e_pf *pf)
 
 		ret = i40e_rx_queue_init(rxq);
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(ERR, "Failed to do RX queue "
-				    "initialization");
+			PMD_DRV_LOG(ERR,
+				"Failed to do RX queue initialization");
 			break;
 		}
 	}
@@ -5680,8 +5688,9 @@ i40e_dev_handle_aq_msg(struct rte_eth_dev *dev)
 		ret = i40e_clean_arq_element(hw, &info, &pending);
 
 		if (ret != I40E_SUCCESS) {
-			PMD_DRV_LOG(INFO, "Failed to read msg from AdminQ, "
-				    "aq_err: %u", hw->aq.asq_last_status);
+			PMD_DRV_LOG(INFO,
+				"Failed to read msg from AdminQ, aq_err: %u",
+				hw->aq.asq_last_status);
 			break;
 		}
 		opcode = rte_le_to_cpu_16(info.desc.opcode);
@@ -5998,8 +6007,8 @@ i40e_find_all_vlan_for_mac(struct i40e_vsi *vsi,
 			for (k = 0; k < I40E_UINT32_BIT_SIZE; k++) {
 				if (vsi->vfta[j] & (1 << k)) {
 					if (i > num - 1) {
-						PMD_DRV_LOG(ERR, "vlan number "
-							    "not match");
+						PMD_DRV_LOG(ERR,
+							"vlan number doesn't match");
 						return I40E_ERR_PARAM;
 					}
 					(void)rte_memcpy(&mv_f[i].macaddr,
@@ -6472,8 +6481,7 @@ i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t key_len)
 
 		ret = i40e_aq_set_rss_key(hw, vsi->vsi_id, key_dw);
 		if (ret)
-			PMD_INIT_LOG(ERR, "Failed to configure RSS key "
-				     "via AQ");
+			PMD_INIT_LOG(ERR, "Failed to configure RSS key via AQ");
 	} else {
 		uint32_t *hash_key = (uint32_t *)key;
 		uint16_t i;
@@ -6846,8 +6854,9 @@ i40e_add_vxlan_port(struct i40e_pf *pf, uint16_t port)
 	/* Now check if there is space to add the new port */
 	idx = i40e_get_vxlan_port_idx(pf, 0);
 	if (idx < 0) {
-		PMD_DRV_LOG(ERR, "Maximum number of UDP ports reached,"
-			"not adding port %d", port);
+		PMD_DRV_LOG(ERR,
+			"Maximum number of UDP ports reached, not adding port %d",
+			port);
 		return -ENOSPC;
 	}
 
@@ -7218,15 +7227,15 @@ i40e_set_symmetric_hash_enable_per_port(struct i40e_hw *hw, uint8_t enable)
 
 	if (enable > 0) {
 		if (reg & I40E_PRTQF_CTL_0_HSYM_ENA_MASK) {
-			PMD_DRV_LOG(INFO, "Symmetric hash has already "
-							"been enabled");
+			PMD_DRV_LOG(INFO,
+				"Symmetric hash has already been enabled");
 			return;
 		}
 		reg |= I40E_PRTQF_CTL_0_HSYM_ENA_MASK;
 	} else {
 		if (!(reg & I40E_PRTQF_CTL_0_HSYM_ENA_MASK)) {
-			PMD_DRV_LOG(INFO, "Symmetric hash has already "
-							"been disabled");
+			PMD_DRV_LOG(INFO,
+				"Symmetric hash has already been disabled");
 			return;
 		}
 		reg &= ~I40E_PRTQF_CTL_0_HSYM_ENA_MASK;
@@ -7350,16 +7359,16 @@ i40e_set_hash_filter_global_config(struct i40e_hw *hw,
 	if (g_cfg->hash_func == RTE_ETH_HASH_FUNCTION_TOEPLITZ) {
 		/* Toeplitz */
 		if (reg & I40E_GLQF_CTL_HTOEP_MASK) {
-			PMD_DRV_LOG(DEBUG, "Hash function already set to "
-								"Toeplitz");
+			PMD_DRV_LOG(DEBUG,
+				"Hash function already set to Toeplitz");
 			goto out;
 		}
 		reg |= I40E_GLQF_CTL_HTOEP_MASK;
 	} else if (g_cfg->hash_func == RTE_ETH_HASH_FUNCTION_SIMPLE_XOR) {
 		/* Simple XOR */
 		if (!(reg & I40E_GLQF_CTL_HTOEP_MASK)) {
-			PMD_DRV_LOG(DEBUG, "Hash function already set to "
-							"Simple XOR");
+			PMD_DRV_LOG(DEBUG,
+				"Hash function already set to Simple XOR");
 			goto out;
 		}
 		reg &= ~I40E_GLQF_CTL_HTOEP_MASK;
@@ -8362,13 +8371,14 @@ i40e_ethertype_filter_set(struct i40e_pf *pf,
 	}
 	if (filter->ether_type == ETHER_TYPE_IPv4 ||
 		filter->ether_type == ETHER_TYPE_IPv6) {
-		PMD_DRV_LOG(ERR, "unsupported ether_type(0x%04x) in"
-			" control packet filter.", filter->ether_type);
+		PMD_DRV_LOG(ERR,
+			"unsupported ether_type(0x%04x) in control packet filter.",
+			filter->ether_type);
 		return -EINVAL;
 	}
 	if (filter->ether_type == ETHER_TYPE_VLAN)
-		PMD_DRV_LOG(WARNING, "filter vlan ether_type in first tag is"
-			" not supported.");
+		PMD_DRV_LOG(WARNING,
+			"filter vlan ether_type in first tag is not supported.");
 
 	/* Check if there is the filter in SW list */
 	memset(&check_filter, 0, sizeof(check_filter));
@@ -8398,11 +8408,10 @@ i40e_ethertype_filter_set(struct i40e_pf *pf,
 			pf->main_vsi->seid,
 			filter->queue, add, &stats, NULL);
 
-	PMD_DRV_LOG(INFO, "add/rem control packet filter, return %d,"
-			 " mac_etype_used = %u, etype_used = %u,"
-			 " mac_etype_free = %u, etype_free = %u\n",
-			 ret, stats.mac_etype_used, stats.etype_used,
-			 stats.mac_etype_free, stats.etype_free);
+	PMD_DRV_LOG(INFO,
+		"add/rem control packet filter, return %d, mac_etype_used = %u, etype_used = %u, mac_etype_free = %u, etype_free = %u\n",
+		ret, stats.mac_etype_used, stats.etype_used,
+		stats.mac_etype_free, stats.etype_free);
 	if (ret < 0)
 		return -ENOSYS;
 
@@ -8720,9 +8729,9 @@ i40e_configure_registers(struct i40e_hw *hw)
 		ret = i40e_aq_debug_write_register(hw, reg_table[i].addr,
 						reg_table[i].val, NULL);
 		if (ret < 0) {
-			PMD_DRV_LOG(ERR, "Failed to write 0x%"PRIx64" to the "
-				"address of 0x%"PRIx32, reg_table[i].val,
-							reg_table[i].addr);
+			PMD_DRV_LOG(ERR,
+				"Failed to write 0x%"PRIx64" to the address of 0x%"PRIx32,
+				reg_table[i].val, reg_table[i].addr);
 			break;
 		}
 		PMD_DRV_LOG(DEBUG, "Write 0x%"PRIx64" to the address of "
@@ -8767,8 +8776,9 @@ i40e_config_qinq(struct i40e_hw *hw, struct i40e_vsi *vsi)
 						   I40E_VSI_L2TAGSTXVALID(
 						   vsi->vsi_id), reg, NULL);
 		if (ret < 0) {
-			PMD_DRV_LOG(ERR, "Failed to update "
-				"VSI_L2TAGSTXVALID[%d]", vsi->vsi_id);
+			PMD_DRV_LOG(ERR,
+				"Failed to update VSI_L2TAGSTXVALID[%d]",
+				vsi->vsi_id);
 			return I40E_ERR_CONFIG;
 		}
 	}
@@ -8819,11 +8829,10 @@ i40e_aq_add_mirror_rule(struct i40e_hw *hw,
 
 	rte_memcpy(&desc.params.raw, &cmd, sizeof(cmd));
 	status = i40e_asq_send_command(hw, &desc, entries, buff_len, NULL);
-	PMD_DRV_LOG(INFO, "i40e_aq_add_mirror_rule, aq_status %d,"
-			 "rule_id = %u"
-			 " mirror_rules_used = %u, mirror_rules_free = %u,",
-			 hw->aq.asq_last_status, resp->rule_id,
-			 resp->mirror_rules_used, resp->mirror_rules_free);
+	PMD_DRV_LOG(INFO,
+		"i40e_aq_add_mirror_rule, aq_status %d, rule_id = %u mirror_rules_used = %u, mirror_rules_free = %u,",
+		hw->aq.asq_last_status, resp->rule_id,
+		resp->mirror_rules_used, resp->mirror_rules_free);
 	*rule_id = rte_le_to_cpu_16(resp->rule_id);
 
 	return status;
@@ -8901,8 +8910,8 @@ i40e_mirror_rule_set(struct rte_eth_dev *dev,
 	PMD_DRV_LOG(DEBUG, "i40e_mirror_rule_set: sw_id = %d.", sw_id);
 
 	if (pf->main_vsi->veb == NULL || pf->vfs == NULL) {
-		PMD_DRV_LOG(ERR, "mirror rule can not be configured"
-			" without veb or vfs.");
+		PMD_DRV_LOG(ERR,
+			"mirror rule can not be configured without veb or vfs.");
 		return -ENOSYS;
 	}
 	if (pf->nb_mirror_rule > I40E_MAX_MIRROR_RULES) {
@@ -8934,9 +8943,9 @@ i40e_mirror_rule_set(struct rte_eth_dev *dev,
 					mirr_rule->entries,
 					mirr_rule->num_entries, mirr_rule->id);
 			if (ret < 0) {
-				PMD_DRV_LOG(ERR, "failed to remove mirror rule:"
-						   " ret = %d, aq_err = %d.",
-						   ret, hw->aq.asq_last_status);
+				PMD_DRV_LOG(ERR,
+					"failed to remove mirror rule: ret = %d, aq_err = %d.",
+					ret, hw->aq.asq_last_status);
 				return -ENOSYS;
 			}
 			TAILQ_REMOVE(&pf->mirror_list, mirr_rule, rules);
@@ -9025,9 +9034,9 @@ i40e_mirror_rule_set(struct rte_eth_dev *dev,
 				      mirr_rule->rule_type, mirr_rule->entries,
 				      j, &rule_id);
 	if (ret < 0) {
-		PMD_DRV_LOG(ERR, "failed to add mirror rule:"
-				   " ret = %d, aq_err = %d.",
-				   ret, hw->aq.asq_last_status);
+		PMD_DRV_LOG(ERR,
+			"failed to add mirror rule: ret = %d, aq_err = %d.",
+			ret, hw->aq.asq_last_status);
 		rte_free(mirr_rule);
 		return -ENOSYS;
 	}
@@ -9079,9 +9088,9 @@ i40e_mirror_rule_reset(struct rte_eth_dev *dev, uint8_t sw_id)
 				mirr_rule->entries,
 				mirr_rule->num_entries, mirr_rule->id);
 		if (ret < 0) {
-			PMD_DRV_LOG(ERR, "failed to remove mirror rule:"
-					   " status = %d, aq_err = %d.",
-					   ret, hw->aq.asq_last_status);
+			PMD_DRV_LOG(ERR,
+				"failed to remove mirror rule: status = %d, aq_err = %d.",
+				ret, hw->aq.asq_last_status);
 			return -ENOSYS;
 		}
 		TAILQ_REMOVE(&pf->mirror_list, mirr_rule, rules);
@@ -9513,9 +9522,9 @@ i40e_config_switch_comp_tc(struct i40e_veb *veb, uint8_t tc_map)
 	ret = i40e_aq_config_switch_comp_bw_config(hw, veb->seid,
 						   &veb_bw, NULL);
 	if (ret) {
-		PMD_INIT_LOG(ERR, "AQ command Config switch_comp BW allocation"
-				  " per TC failed = %d",
-				  hw->aq.asq_last_status);
+		PMD_INIT_LOG(ERR,
+			"AQ command Config switch_comp BW allocation per TC failed = %d",
+			hw->aq.asq_last_status);
 		return ret;
 	}
 
@@ -9523,16 +9532,18 @@ i40e_config_switch_comp_tc(struct i40e_veb *veb, uint8_t tc_map)
 	ret = i40e_aq_query_switch_comp_ets_config(hw, veb->seid,
 						   &ets_query, NULL);
 	if (ret != I40E_SUCCESS) {
-		PMD_DRV_LOG(ERR, "Failed to get switch_comp ETS"
-				 " configuration %u", hw->aq.asq_last_status);
+		PMD_DRV_LOG(ERR,
+			"Failed to get switch_comp ETS configuration %u",
+			hw->aq.asq_last_status);
 		return ret;
 	}
 	memset(&bw_query, 0, sizeof(bw_query));
 	ret = i40e_aq_query_switch_comp_bw_config(hw, veb->seid,
 						  &bw_query, NULL);
 	if (ret != I40E_SUCCESS) {
-		PMD_DRV_LOG(ERR, "Failed to get switch_comp bandwidth"
-				 " configuration %u", hw->aq.asq_last_status);
+		PMD_DRV_LOG(ERR,
+			"Failed to get switch_comp bandwidth configuration %u",
+			hw->aq.asq_last_status);
 		return ret;
 	}
 
@@ -9597,8 +9608,8 @@ i40e_vsi_config_tc(struct i40e_vsi *vsi, uint8_t tc_map)
 	}
 	ret = i40e_aq_config_vsi_tc_bw(hw, vsi->seid, &bw_data, NULL);
 	if (ret) {
-		PMD_INIT_LOG(ERR, "AQ command Config VSI BW allocation"
-			" per TC failed = %d",
+		PMD_INIT_LOG(ERR,
+			"AQ command Config VSI BW allocation per TC failed = %d",
 			hw->aq.asq_last_status);
 		goto out;
 	}
@@ -9619,9 +9630,8 @@ i40e_vsi_config_tc(struct i40e_vsi *vsi, uint8_t tc_map)
 	/* Update the VSI after updating the VSI queue-mapping information */
 	ret = i40e_aq_update_vsi_params(hw, &ctxt, NULL);
 	if (ret) {
-		PMD_INIT_LOG(ERR, "Failed to configure "
-			    "TC queue mapping = %d",
-			    hw->aq.asq_last_status);
+		PMD_INIT_LOG(ERR, "Failed to configure TC queue mapping = %d",
+			hw->aq.asq_last_status);
 		goto out;
 	}
 	/* update the local VSI info with updated queue map */
@@ -9673,8 +9683,8 @@ i40e_dcb_hw_configure(struct i40e_pf *pf,
 	/* Use the FW API if FW > v4.4*/
 	if (!(((hw->aq.fw_maj_ver == 4) && (hw->aq.fw_min_ver >= 4)) ||
 	      (hw->aq.fw_maj_ver >= 5))) {
-		PMD_INIT_LOG(ERR, "FW < v4.4, can not use FW LLDP API"
-				  " to configure DCB");
+		PMD_INIT_LOG(ERR,
+			"FW < v4.4, can not use FW LLDP API to configure DCB");
 		return I40E_ERR_FIRMWARE_API_VERSION;
 	}
 
@@ -9740,8 +9750,8 @@ i40e_dcb_hw_configure(struct i40e_pf *pf,
 							 I40E_DEFAULT_TCMAP);
 			if (ret)
 				PMD_INIT_LOG(WARNING,
-					 "Failed configuring TC for VSI seid=%d\n",
-					 vsi_list->vsi->seid);
+					"Failed configuring TC for VSI seid=%d\n",
+					vsi_list->vsi->seid);
 			/* continue */
 		}
 	}
@@ -9801,15 +9811,15 @@ i40e_dcb_init_configure(struct rte_eth_dev *dev, bool sw_dcb)
 						I40E_APP_PROTOID_FCOE;
 			ret = i40e_set_dcb_config(hw);
 			if (ret) {
-				PMD_INIT_LOG(ERR, "default dcb config fails."
-					" err = %d, aq_err = %d.", ret,
-					  hw->aq.asq_last_status);
+				PMD_INIT_LOG(ERR,
+					"default dcb config fails. err = %d, aq_err = %d.",
+					ret, hw->aq.asq_last_status);
 				return -ENOSYS;
 			}
 		} else {
-			PMD_INIT_LOG(ERR, "DCB initialization in FW fails,"
-					  " err = %d, aq_err = %d.", ret,
-					  hw->aq.asq_last_status);
+			PMD_INIT_LOG(ERR,
+				"DCB initialization in FW fails, err = %d, aq_err = %d.",
+				ret, hw->aq.asq_last_status);
 			return -ENOTSUP;
 		}
 	} else {
@@ -9820,14 +9830,14 @@ i40e_dcb_init_configure(struct rte_eth_dev *dev, bool sw_dcb)
 		ret = i40e_init_dcb(hw);
 		if (!ret) {
 			if (hw->dcbx_status == I40E_DCBX_STATUS_DISABLED) {
-				PMD_INIT_LOG(ERR, "HW doesn't support"
-						  " DCBX offload.");
+				PMD_INIT_LOG(ERR,
+					"HW doesn't support DCBX offload.");
 				return -ENOTSUP;
 			}
 		} else {
-			PMD_INIT_LOG(ERR, "DCBX configuration failed, err = %d,"
-					  " aq_err = %d.", ret,
-					  hw->aq.asq_last_status);
+			PMD_INIT_LOG(ERR,
+				"DCBX configuration failed, err = %d, aq_err = %d.",
+				ret, hw->aq.asq_last_status);
 			return -ENOTSUP;
 		}
 	}
-- 
2.11.0

Re: [dpdk-dev] [PATCH v3 1/1] i40e: improve message grepability

[Ferruh Yigit]

On 1/11/2017 5:13 PM, Michał Mirosław wrote:
> From: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> 
> Join message lines for easier grepping.
> PRIxXX are left glued to strings as they are in other parts of the file.
> 
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>

Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Re: [dpdk-dev] [PATCH v3 1/1] i40e: improve message grepability

[Ferruh Yigit]

On 1/11/2017 5:50 PM, Ferruh Yigit wrote:
> On 1/11/2017 5:13 PM, Michał Mirosław wrote:
>> From: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
>>
>> Join message lines for easier grepping.
>> PRIxXX are left glued to strings as they are in other parts of the file.
>>
>> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Applied to dpdk-next-net/master, thanks.

[dpdk-dev] [PATCH 12/13] i40e: return -errno when intr setup fails

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 drivers/net/i40e/i40e_ethdev.c               | 5 +++--
 lib/librte_eal/linuxapp/eal/eal_interrupts.c | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 67778ba..39fbcfe 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1692,8 +1692,9 @@ i40e_dev_start(struct rte_eth_dev *dev)
 	     !RTE_ETH_DEV_SRIOV(dev).active) &&
 	    dev->data->dev_conf.intr_conf.rxq != 0) {
 		intr_vector = dev->data->nb_rx_queues;
-		if (rte_intr_efd_enable(intr_handle, intr_vector))
-			return -1;
+		ret = rte_intr_efd_enable(intr_handle, intr_vector);
+		if (ret)
+			return ret;
 	}
 
 	if (rte_intr_dp_is_en(intr_handle) && !intr_handle->intr_vec) {
diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
index 47a3b20..f7a8ce3 100644
--- a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
+++ b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
@@ -1157,7 +1157,7 @@ rte_intr_efd_enable(struct rte_intr_handle *intr_handle, uint32_t nb_efd)
 				RTE_LOG(ERR, EAL,
 					"can't setup eventfd, error %i (%s)\n",
 					errno, strerror(errno));
-				return -1;
+				return -errno;
 			}
 			intr_handle->efds[i] = fd;
 		}
-- 
2.10.2

Re: [dpdk-dev] [PATCH 12/13] i40e: return -errno when intr setup fails

[Ferruh Yigit]

On 12/13/2016 1:08 AM, Michał Mirosław wrote:
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> ---
>  drivers/net/i40e/i40e_ethdev.c               | 5 +++--
>  lib/librte_eal/linuxapp/eal/eal_interrupts.c | 2 +-
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 67778ba..39fbcfe 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -1692,8 +1692,9 @@ i40e_dev_start(struct rte_eth_dev *dev)
>  	     !RTE_ETH_DEV_SRIOV(dev).active) &&
>  	    dev->data->dev_conf.intr_conf.rxq != 0) {
>  		intr_vector = dev->data->nb_rx_queues;
> -		if (rte_intr_efd_enable(intr_handle, intr_vector))
> -			return -1;
> +		ret = rte_intr_efd_enable(intr_handle, intr_vector);
> +		if (ret)
> +			return ret;

What is the benefit of returning -errno instead of -1?

>  	}
>  
>  	if (rte_intr_dp_is_en(intr_handle) && !intr_handle->intr_vec) {
> diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> index 47a3b20..f7a8ce3 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> @@ -1157,7 +1157,7 @@ rte_intr_efd_enable(struct rte_intr_handle *intr_handle, uint32_t nb_efd)
>  				RTE_LOG(ERR, EAL,
>  					"can't setup eventfd, error %i (%s)\n",
>  					errno, strerror(errno));
> -				return -1;
> +				return -errno;
>  			}
>  			intr_handle->efds[i] = fd;
>  		}
> 

Re: [dpdk-dev] [PATCH 12/13] i40e: return -errno when intr setup fails

[Michał Mirosław]

On Thu, Dec 22, 2016 at 03:45:35PM +0000, Ferruh Yigit wrote:
> On 12/13/2016 1:08 AM, Michał Mirosław wrote:
> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > ---
> >  drivers/net/i40e/i40e_ethdev.c               | 5 +++--
> >  lib/librte_eal/linuxapp/eal/eal_interrupts.c | 2 +-
> >  2 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> > index 67778ba..39fbcfe 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -1692,8 +1692,9 @@ i40e_dev_start(struct rte_eth_dev *dev)
> >  	     !RTE_ETH_DEV_SRIOV(dev).active) &&
> >  	    dev->data->dev_conf.intr_conf.rxq != 0) {
> >  		intr_vector = dev->data->nb_rx_queues;
> > -		if (rte_intr_efd_enable(intr_handle, intr_vector))
> > -			return -1;
> > +		ret = rte_intr_efd_enable(intr_handle, intr_vector);
> > +		if (ret)
> > +			return ret;
> 
> What is the benefit of returning -errno instead of -1?

Information. Besides, all other error returns from i40e_dev_start return
negated error code (-1 happens to be -EPERM, which further confuses
the poor developer who's diagnosing the failure).

Best Regards,
Michał Mirosław

Re: [dpdk-dev] [PATCH 12/13] i40e: return -errno when intr setup fails

[Wu, Jingjing]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> Sent: Tuesday, December 13, 2016 9:08 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH 12/13] i40e: return -errno when intr setup fails
> 
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> ---
>  drivers/net/i40e/i40e_ethdev.c               | 5 +++--
>  lib/librte_eal/linuxapp/eal/eal_interrupts.c | 2 +-
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 67778ba..39fbcfe 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -1692,8 +1692,9 @@ i40e_dev_start(struct rte_eth_dev *dev)
>  	     !RTE_ETH_DEV_SRIOV(dev).active) &&
>  	    dev->data->dev_conf.intr_conf.rxq != 0) {
>  		intr_vector = dev->data->nb_rx_queues;
> -		if (rte_intr_efd_enable(intr_handle, intr_vector))
> -			return -1;
> +		ret = rte_intr_efd_enable(intr_handle, intr_vector);
> +		if (ret)
> +			return ret;
>  	}
> 
>  	if (rte_intr_dp_is_en(intr_handle) && !intr_handle->intr_vec) { diff --git
> a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> index 47a3b20..f7a8ce3 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> @@ -1157,7 +1157,7 @@ rte_intr_efd_enable(struct rte_intr_handle
> *intr_handle, uint32_t nb_efd)
>  				RTE_LOG(ERR, EAL,
>  					"can't setup eventfd, error %i (%s)\n",
>  					errno, strerror(errno));
> -				return -1;
> +				return -errno;
>  			}
>  			intr_handle->efds[i] = fd;
>  		}
> --

Reviewed-by: Jingjing Wu <jingjing.wu@intel.com>

Re: [dpdk-dev] [PATCH 12/13] i40e: return -errno when intr setup fails

[Ferruh Yigit]

On 12/28/2016 3:47 AM, Wu, Jingjing wrote:
> 
> 
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
>> Sent: Tuesday, December 13, 2016 9:08 AM
>> To: dev@dpdk.org
>> Subject: [dpdk-dev] [PATCH 12/13] i40e: return -errno when intr setup fails
>>
>> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>

> Reviewed-by: Jingjing Wu <jingjing.wu@intel.com>
> 

Applied to dpdk-next-net/master, thanks.

[dpdk-dev] [PATCH v2] acl: allow zero verdict

[Michał Mirosław]

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
v2: fixes prog_guide and ACL tests

---
 app/test/test_acl.c                                  | 13 -------------
 doc/guides/prog_guide/packet_classif_access_ctrl.rst |  3 ++-
 lib/librte_acl/rte_acl.c                             |  3 +--
 lib/librte_acl/rte_acl.h                             |  2 --
 lib/librte_table/rte_table_acl.c                     |  2 +-
 5 files changed, 4 insertions(+), 19 deletions(-)

diff --git a/app/test/test_acl.c b/app/test/test_acl.c
index be744ec..c6b511f 100644
--- a/app/test/test_acl.c
+++ b/app/test/test_acl.c
@@ -1357,19 +1357,6 @@ test_invalid_rules(void)
 		goto err;
 	}
 
-	rule.dst_mask_len = 0;
-	rule.src_mask_len = 0;
-	rule.data.userdata = 0;
-
-	/* try adding this rule (it should fail because userdata is invalid) */
-	ret = rte_acl_ipv4vlan_add_rules(acx, &rule, 1);
-	if (ret == 0) {
-		printf("Line %i: Adding a rule with invalid user data "
-				"should have failed!\n", __LINE__);
-		rte_acl_free(acx);
-		return -1;
-	}
-
 	rte_acl_free(acx);
 
 	return 0;
diff --git a/doc/guides/prog_guide/packet_classif_access_ctrl.rst b/doc/guides/prog_guide/packet_classif_access_ctrl.rst
index 5fd3d34..a6bee9b 100644
--- a/doc/guides/prog_guide/packet_classif_access_ctrl.rst
+++ b/doc/guides/prog_guide/packet_classif_access_ctrl.rst
@@ -329,8 +329,9 @@ When creating a set of rules, for each rule, additional information must be supp
     Each set could be assigned its own category and by combining them into a single database,
     one lookup returns a result for each of the four sets.
 
-*   **userdata**: A user-defined field that could be any value except zero.
+*   **userdata**: A user-defined value.
     For each category, a successful match returns the userdata field of the highest priority matched rule.
+    When no rules match, returned value is zero.
 
 .. note::
 
diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
index 8b7e92c..d1f40be 100644
--- a/lib/librte_acl/rte_acl.c
+++ b/lib/librte_acl/rte_acl.c
@@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
 	if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
 			rd->category_mask) == 0 ||
 			rd->priority > RTE_ACL_MAX_PRIORITY ||
-			rd->priority < RTE_ACL_MIN_PRIORITY ||
-			rd->userdata == RTE_ACL_INVALID_USERDATA)
+			rd->priority < RTE_ACL_MIN_PRIORITY)
 		return -EINVAL;
 	return 0;
 }
diff --git a/lib/librte_acl/rte_acl.h b/lib/librte_acl/rte_acl.h
index caa91f7..b53179a 100644
--- a/lib/librte_acl/rte_acl.h
+++ b/lib/librte_acl/rte_acl.h
@@ -120,8 +120,6 @@ enum {
 	RTE_ACL_MIN_PRIORITY = 0,
 };
 
-#define	RTE_ACL_INVALID_USERDATA	0
-
 #define	RTE_ACL_MASKLEN_TO_BITMASK(v, s)	\
 ((v) == 0 ? (v) : (typeof(v))((uint64_t)-1 << ((s) * CHAR_BIT - (v))))
 
diff --git a/lib/librte_table/rte_table_acl.c b/lib/librte_table/rte_table_acl.c
index 8f1f8ce..94b69a9 100644
--- a/lib/librte_table/rte_table_acl.c
+++ b/lib/librte_table/rte_table_acl.c
@@ -792,7 +792,7 @@ rte_table_acl_lookup(
 
 		pkts_mask &= ~pkt_mask;
 
-		if (action_table_pos != RTE_ACL_INVALID_USERDATA) {
+		if (action_table_pos != 0) {
 			pkts_out_mask |= pkt_mask;
 			entries[pkt_pos] = (void *)
 				&acl->memory[action_table_pos *
-- 
2.10.2

Re: [dpdk-dev] [PATCH v2] acl: allow zero verdict

[Ananyev, Konstantin]

> -----Original Message-----
> From: Michał Mirosław [mailto:mirq-linux@rere.qmqm.pl]
> Sent: Wednesday, December 14, 2016 5:24 PM
> To: dev@dpdk.org
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Subject: [PATCH v2] acl: allow zero verdict
> 
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> ---
> v2: fixes prog_guide and ACL tests
> 
> ---
>  app/test/test_acl.c                                  | 13 -------------
>  doc/guides/prog_guide/packet_classif_access_ctrl.rst |  3 ++-
>  lib/librte_acl/rte_acl.c                             |  3 +--
>  lib/librte_acl/rte_acl.h                             |  2 --
>  lib/librte_table/rte_table_acl.c                     |  2 +-
>  5 files changed, 4 insertions(+), 19 deletions(-)
> 
> diff --git a/app/test/test_acl.c b/app/test/test_acl.c
> index be744ec..c6b511f 100644
> --- a/app/test/test_acl.c
> +++ b/app/test/test_acl.c
> @@ -1357,19 +1357,6 @@ test_invalid_rules(void)
>  		goto err;
>  	}
> 
> -	rule.dst_mask_len = 0;
> -	rule.src_mask_len = 0;
> -	rule.data.userdata = 0;
> -
> -	/* try adding this rule (it should fail because userdata is invalid) */
> -	ret = rte_acl_ipv4vlan_add_rules(acx, &rule, 1);
> -	if (ret == 0) {
> -		printf("Line %i: Adding a rule with invalid user data "
> -				"should have failed!\n", __LINE__);
> -		rte_acl_free(acx);
> -		return -1;
> -	}
> -
>  	rte_acl_free(acx);
> 
>  	return 0;
> diff --git a/doc/guides/prog_guide/packet_classif_access_ctrl.rst b/doc/guides/prog_guide/packet_classif_access_ctrl.rst
> index 5fd3d34..a6bee9b 100644
> --- a/doc/guides/prog_guide/packet_classif_access_ctrl.rst
> +++ b/doc/guides/prog_guide/packet_classif_access_ctrl.rst
> @@ -329,8 +329,9 @@ When creating a set of rules, for each rule, additional information must be supp
>      Each set could be assigned its own category and by combining them into a single database,
>      one lookup returns a result for each of the four sets.
> 
> -*   **userdata**: A user-defined field that could be any value except zero.
> +*   **userdata**: A user-defined value.
>      For each category, a successful match returns the userdata field of the highest priority matched rule.
> +    When no rules match, returned value is zero.

Might be good to add some extra explanation here:
"When no rules match, returned value is zero.
So while rules with userdata equal zero are allowed,
such rules would always return 'no match' found when hit."
Or might be some better wording could be found.
Konstantin
 
> 
>  .. note::
> 
> diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> index 8b7e92c..d1f40be 100644
> --- a/lib/librte_acl/rte_acl.c
> +++ b/lib/librte_acl/rte_acl.c
> @@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
>  	if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
>  			rd->category_mask) == 0 ||
>  			rd->priority > RTE_ACL_MAX_PRIORITY ||
> -			rd->priority < RTE_ACL_MIN_PRIORITY ||
> -			rd->userdata == RTE_ACL_INVALID_USERDATA)
> +			rd->priority < RTE_ACL_MIN_PRIORITY)
>  		return -EINVAL;
>  	return 0;
>  }
> diff --git a/lib/librte_acl/rte_acl.h b/lib/librte_acl/rte_acl.h
> index caa91f7..b53179a 100644
> --- a/lib/librte_acl/rte_acl.h
> +++ b/lib/librte_acl/rte_acl.h
> @@ -120,8 +120,6 @@ enum {
>  	RTE_ACL_MIN_PRIORITY = 0,
>  };
> 
> -#define	RTE_ACL_INVALID_USERDATA	0
> -
>  #define	RTE_ACL_MASKLEN_TO_BITMASK(v, s)	\
>  ((v) == 0 ? (v) : (typeof(v))((uint64_t)-1 << ((s) * CHAR_BIT - (v))))
> 
> diff --git a/lib/librte_table/rte_table_acl.c b/lib/librte_table/rte_table_acl.c
> index 8f1f8ce..94b69a9 100644
> --- a/lib/librte_table/rte_table_acl.c
> +++ b/lib/librte_table/rte_table_acl.c
> @@ -792,7 +792,7 @@ rte_table_acl_lookup(
> 
>  		pkts_mask &= ~pkt_mask;
> 
> -		if (action_table_pos != RTE_ACL_INVALID_USERDATA) {
> +		if (action_table_pos != 0) {
>  			pkts_out_mask |= pkt_mask;
>  			entries[pkt_pos] = (void *)
>  				&acl->memory[action_table_pos *
> --
> 2.10.2

[dpdk-dev] [PATCH] acl: remove invalid test

[Michał Mirosław]

rte_acl_add_rules() has no way of checking rule size.

This was hidden because the test effectively checked that
adding a rule with userdata == 0 failed.

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 app/test/test_acl.c | 20 --------------------
 1 file changed, 20 deletions(-)

diff --git a/app/test/test_acl.c b/app/test/test_acl.c
index 28955f0..be744ec 100644
--- a/app/test/test_acl.c
+++ b/app/test/test_acl.c
@@ -1515,26 +1515,6 @@ test_invalid_parameters(void)
 	/* free ACL context */
 	rte_acl_free(acx);
 
-	/* set wrong rule_size so that adding any rules would fail */
-	param.rule_size = RTE_ACL_IPV4VLAN_RULE_SZ + 4;
-	acx = rte_acl_create(&param);
-	if (acx == NULL) {
-		printf("Line %i: ACL context creation failed!\n", __LINE__);
-		return -1;
-	}
-
-	/* try adding a rule with size different from context rule_size */
-	result = rte_acl_ipv4vlan_add_rules(acx, &rule, 1);
-	if (result == 0) {
-		printf("Line %i: Adding an invalid sized rule "
-				"should have failed!\n", __LINE__);
-		rte_acl_free(acx);
-		return -1;
-	}
-
-	/* free ACL context */
-	rte_acl_free(acx);
-
 
 	/**
 	 * rte_acl_ipv4vlan_build
-- 
2.10.2

Re: [dpdk-dev] [PATCH] acl: remove invalid test

[Ananyev, Konstantin]

Hi Michal,

> -----Original Message-----
> From: Michał Mirosław [mailto:mirq-linux@rere.qmqm.pl]
> Sent: Wednesday, December 14, 2016 5:24 PM
> To: dev@dpdk.org
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Subject: [PATCH] acl: remove invalid test
> 
> rte_acl_add_rules() has no way of checking rule size.
> 
> This was hidden because the test effectively checked that
> adding a rule with userdata == 0 failed.

I suppose that changes have to be inside:
[PATCH v2] acl: allow zero verdict.

Konstantin 


> 
> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> ---
>  app/test/test_acl.c | 20 --------------------
>  1 file changed, 20 deletions(-)
> 
> diff --git a/app/test/test_acl.c b/app/test/test_acl.c
> index 28955f0..be744ec 100644
> --- a/app/test/test_acl.c
> +++ b/app/test/test_acl.c
> @@ -1515,26 +1515,6 @@ test_invalid_parameters(void)
>  	/* free ACL context */
>  	rte_acl_free(acx);
> 
> -	/* set wrong rule_size so that adding any rules would fail */
> -	param.rule_size = RTE_ACL_IPV4VLAN_RULE_SZ + 4;
> -	acx = rte_acl_create(&param);
> -	if (acx == NULL) {
> -		printf("Line %i: ACL context creation failed!\n", __LINE__);
> -		return -1;
> -	}
> -
> -	/* try adding a rule with size different from context rule_size */
> -	result = rte_acl_ipv4vlan_add_rules(acx, &rule, 1);
> -	if (result == 0) {
> -		printf("Line %i: Adding an invalid sized rule "
> -				"should have failed!\n", __LINE__);
> -		rte_acl_free(acx);
> -		return -1;
> -	}
> -
> -	/* free ACL context */
> -	rte_acl_free(acx);
> -
> 
>  	/**
>  	 * rte_acl_ipv4vlan_build
> --
> 2.10.2

Re: [dpdk-dev] [PATCH] acl: remove invalid test

[Michal Miroslaw]

On Mon, Dec 19, 2016 at 06:48:52PM +0000, Ananyev, Konstantin wrote:
> Hi Michal,
> 
> > -----Original Message-----
> > From: Michał Mirosław [mailto:mirq-linux@rere.qmqm.pl]
> > Sent: Wednesday, December 14, 2016 5:24 PM
> > To: dev@dpdk.org
> > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > Subject: [PATCH] acl: remove invalid test
> > 
> > rte_acl_add_rules() has no way of checking rule size.
> > 
> > This was hidden because the test effectively checked that
> > adding a rule with userdata == 0 failed.
> I suppose that changes have to be inside:
> [PATCH v2] acl: allow zero verdict.

The 'allow zero verdict' patch depends on this one if we are to not have
a breaking tests inbetween. Otherwise, it is an independent change.

I guess I can merge them, though, if you prefer it that way.

Best Regards,
Michał Mirosław

Re: [dpdk-dev] [PATCH] acl: remove invalid test

[Ananyev, Konstantin]

> -----Original Message-----
> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> Sent: Friday, December 23, 2016 1:48 AM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [PATCH] acl: remove invalid test
> 
> On Mon, Dec 19, 2016 at 06:48:52PM +0000, Ananyev, Konstantin wrote:
> > Hi Michal,
> >
> > > -----Original Message-----
> > > From: Michał Mirosław [mailto:mirq-linux@rere.qmqm.pl]
> > > Sent: Wednesday, December 14, 2016 5:24 PM
> > > To: dev@dpdk.org
> > > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > Subject: [PATCH] acl: remove invalid test
> > >
> > > rte_acl_add_rules() has no way of checking rule size.
> > >
> > > This was hidden because the test effectively checked that
> > > adding a rule with userdata == 0 failed.
> > I suppose that changes have to be inside:
> > [PATCH v2] acl: allow zero verdict.
> 
> The 'allow zero verdict' patch depends on this one if we are to not have
> a breaking tests inbetween. 

Exactly, that's why I think they either has to be in one series of patches,
with this one coming first and ' PATCH v2] acl: allow zero verdict' as the second one,
or just merge them into one.

Konstantin

>Otherwise, it is an independent change.
> 
> I guess I can merge them, though, if you prefer it that way.
> 
> Best Regards,
> Michał Mirosław

Re: [dpdk-dev] [PATCH] acl: remove invalid test

[Thomas Monjalon]

2016-12-23 09:36, Ananyev, Konstantin:
> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > On Mon, Dec 19, 2016 at 06:48:52PM +0000, Ananyev, Konstantin wrote:
> > > I suppose that changes have to be inside:
> > > [PATCH v2] acl: allow zero verdict.
> > 
> > The 'allow zero verdict' patch depends on this one if we are to not have
> > a breaking tests inbetween. 
> 
> Exactly, that's why I think they either has to be in one series of patches,
> with this one coming first and ' PATCH v2] acl: allow zero verdict' as the second one,
> or just merge them into one.

No progress here.
Konstantin, do you ack this patch?
I could apply it as a standalone patch.

Re: [dpdk-dev] [PATCH] acl: remove invalid test

[Ananyev, Konstantin]

Hi Thomas,

> 
> 2016-12-23 09:36, Ananyev, Konstantin:
> > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > > On Mon, Dec 19, 2016 at 06:48:52PM +0000, Ananyev, Konstantin wrote:
> > > > I suppose that changes have to be inside:
> > > > [PATCH v2] acl: allow zero verdict.
> > >
> > > The 'allow zero verdict' patch depends on this one if we are to not have
> > > a breaking tests inbetween.
> >
> > Exactly, that's why I think they either has to be in one series of patches,
> > with this one coming first and ' PATCH v2] acl: allow zero verdict' as the second one,
> > or just merge them into one.
> 
> No progress here.
> Konstantin, do you ack this patch?

Yes, I do.
I just thought that the author would resubmit it as part of 
' PATCH v2] acl: allow zero verdict'
to comply with DPDK patch submission rules.
Konstantin

> I could apply it as a standalone patch.

Re: [dpdk-dev] [PATCH] acl: remove invalid test

[Michal Miroslaw]

On Wed, Jan 18, 2017 at 09:51:45AM +0000, Ananyev, Konstantin wrote:
> Hi Thomas,
> 
> > 
> > 2016-12-23 09:36, Ananyev, Konstantin:
> > > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > > > On Mon, Dec 19, 2016 at 06:48:52PM +0000, Ananyev, Konstantin wrote:
> > > > > I suppose that changes have to be inside:
> > > > > [PATCH v2] acl: allow zero verdict.
> > > >
> > > > The 'allow zero verdict' patch depends on this one if we are to not have
> > > > a breaking tests inbetween.
> > >
> > > Exactly, that's why I think they either has to be in one series of patches,
> > > with this one coming first and ' PATCH v2] acl: allow zero verdict' as the second one,
> > > or just merge them into one.
> > No progress here.
> > Konstantin, do you ack this patch?
> Yes, I do.
> I just thought that the author would resubmit it as part of 
> ' PATCH v2] acl: allow zero verdict'
> to comply with DPDK patch submission rules.
> Konstantin
> > I could apply it as a standalone patch.

Sorry for the delay. I'll do just that in a moment.

Best Regards,
Michał Mirosław