[dpdk-dev] [PATCH 01/10] bnx2x: Set cache line based on build configuration

[Patil, Harish]

>

>Hi Harish,
>
>On 7/12/2016 6:39 AM, Harish Patil wrote:
>>>
>>> Correctly hint the cache line size.  Remove unused macros associated
>>> with the cache line size.
>>>
>>> Fixes: 540a211084a7 ("bnx2x: driver core")
>>>
>>> Signed-off-by: Chas Williams <3chas3 at gmail.com>
>>> ---
>>> drivers/net/bnx2x/bnx2x.h | 5 +
>>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
>>> index 135a6eb..852ec94 100644
>>> --- a/drivers/net/bnx2x/bnx2x.h
>>> +++ b/drivers/net/bnx2x/bnx2x.h
>>> @@ -302,10 +302,7 @@ struct bnx2x_device_type {
>>> /* TCP with Timestamp Option (32) + IPv6 (40) */
>>>
>>> /* max supported alignment is 256 (8 shift) */
>>> -#define BNX2X_RX_ALIGN_SHIFT 8
>>> -/* FW uses 2 cache lines alignment for start packet and size  */
>>> -#define BNX2X_FW_RX_ALIGN_START (1 << BNX2X_RX_ALIGN_SHIFT)
>>> -#define BNX2X_FW_RX_ALIGN_END   (1 << BNX2X_RX_ALIGN_SHIFT)
>>> +#define BNX2X_RX_ALIGN_SHIFT  RTE_MAX(6, min(8,
>>>RTE_CACHE_LINE_SIZE_LOG2))
>>>
>>> #define BNX2X_PXP_DRAM_ALIGN (BNX2X_RX_ALIGN_SHIFT - 5)
>>>
>>> --
>>> 2.5.5
>>>
>>>
>> 
>> Acked-by: Harish Patil 
>> 
>
>Is the Ack for this patch (01/10) or for the series?
>
>Thanks,
>ferruh
>
>

Hi Ferruh,
I meant it for only this patch.
Let me scan thru? for the series and ack.
Thanks,
Harish

Re: [dpdk-dev] [PATCH 6/7] mbuf: introduce new Tx offload flag for MPLS-in-UDP

[Patil, Harish]

>

>On 5/28/2017 9:37 AM, Rasesh Mody wrote:
>> From: Harish Patil 
>> 
>> Some PMDs need to know the tunnel type in order to handle advance TX
>> features. This patch adds a new TX offload flag for MPLS-in-UDP packets.
>> 
>> Signed-off-by: Harish Patil 
>> ---
>>  lib/librte_mbuf/rte_mbuf.c |2 ++
>>  lib/librte_mbuf/rte_mbuf.h |   17 ++---
>>  2 files changed, 12 insertions(+), 7 deletions(-)
>
>CC: Olivier MATZ 
>
>This patch updates rte_mbuf, so the patchset will wait for the ACK for
>this patch first.
>
>Thanks,
>ferruh
>
>
Hi Ferruh,
Please note that this mbuf change is an independent patch.
Let me know if you want us to provide it as a separate patch.
Only patch 7/7 depends on the mbuf patch.

Thanks,
Harish

Re: [dpdk-dev] [PATCH v2 1/2] mbuf: introduce new Tx offload flag for MPLS-in-UDP

[Patil, Harish]

>Hi Rasesh,
>
>On Wed, 7 Jun 2017 00:43:48 -0700, Rasesh Mody 
>wrote:
>> From: Harish Patil 
>> 
>> Some PMDs need to know the tunnel type in order to handle advance TX
>> features. This patch adds a new TX offload flag for MPLS-in-UDP packets.
>> 
>> Signed-off-by: Harish Patil 
>> ---
>>  lib/librte_mbuf/rte_mbuf.c |2 ++
>>  lib/librte_mbuf/rte_mbuf.h |   17 ++---
>>  2 files changed, 12 insertions(+), 7 deletions(-)
>> 
>> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
>> index 0e3e36a..c2793fb 100644
>> --- a/lib/librte_mbuf/rte_mbuf.c
>> +++ b/lib/librte_mbuf/rte_mbuf.c
>> @@ -410,6 +410,7 @@ const char *rte_get_tx_ol_flag_name(uint64_t mask)
>>  case PKT_TX_TUNNEL_IPIP: return "PKT_TX_TUNNEL_IPIP";
>>  case PKT_TX_TUNNEL_GENEVE: return "PKT_TX_TUNNEL_GENEVE";
>>  case PKT_TX_MACSEC: return "PKT_TX_MACSEC";
>> +case PKT_TX_TUNNEL_MPLSINUDP: return "PKT_TX_TUNNEL_MPLSINUDP";
>>  default: return NULL;
>>  }
>>  }
>> @@ -441,6 +442,7 @@ const char *rte_get_tx_ol_flag_name(uint64_t mask)
>>  { PKT_TX_TUNNEL_GENEVE, PKT_TX_TUNNEL_MASK,
>>"PKT_TX_TUNNEL_NONE" },
>>  { PKT_TX_MACSEC, PKT_TX_MACSEC, NULL },
>> +{ PKT_TX_TUNNEL_MPLSINUDP, PKT_TX_TUNNEL_MPLSINUDP, NULL },
>>  };
>>  const char *name;
>>  unsigned int i;
>> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
>> index 1cb0310..27ad421 100644
>> --- a/lib/librte_mbuf/rte_mbuf.h
>> +++ b/lib/librte_mbuf/rte_mbuf.h
>> @@ -197,19 +197,22 @@
>>   * Offload the MACsec. This flag must be set by the application to
>>enable
>>   * this offload feature for a packet to be transmitted.
>>   */
>> -#define PKT_TX_MACSEC(1ULL << 44)
>> +#define PKT_TX_MACSEC(1ULL << 43)
>
>I'm not sure it is suitable to change the value of an existing
>flag, since it breaks the ABI.
>
>
>>  /**
>> - * Bits 45:48 used for the tunnel type.
>> + * Bits 44:48 used for the tunnel type.
>>   * When doing Tx offload like TSO or checksum, the HW needs to
>>configure the
>>   * tunnel type into the HW descriptors.
>>   */
>> -#define PKT_TX_TUNNEL_VXLAN   (0x1ULL << 45)
>> -#define PKT_TX_TUNNEL_GRE (0x2ULL << 45)
>> -#define PKT_TX_TUNNEL_IPIP(0x3ULL << 45)
>> -#define PKT_TX_TUNNEL_GENEVE  (0x4ULL << 45)
>> +/**< TX packet with MPLS-in-UDP RFC 7510 header. */
>> +#define PKT_TX_TUNNEL_MPLSINUDP (0x1ULL << 44)
>> +
>> +#define PKT_TX_TUNNEL_VXLAN   (0x2ULL << 44)
>> +#define PKT_TX_TUNNEL_GRE (0x3ULL << 44)
>> +#define PKT_TX_TUNNEL_IPIP(0x4ULL << 44)
>> +#define PKT_TX_TUNNEL_GENEVE  (0x5ULL << 45)
>>  /* add new TX TUNNEL type here */
>> -#define PKT_TX_TUNNEL_MASK(0xFULL << 45)
>> +#define PKT_TX_TUNNEL_MASK(0x1FULL << 44)
>>  
>>  /**
>>   * Second VLAN insertion (QinQ) flag.
>
>I dont understand why adding
>#define PKT_TX_TUNNEL_MPLSINUDP (0x5ULL << 45)
>wouldn't do the job?
>
>Currently, the tunnel mask is 0xF << 45, which gives 16 possible values.

[Harish]  Hi Olivier,
Not too sure whether I understand your comment.
My understanding is that those are bitmapped values for each Tx tunnel
type in the range [48:45].
They are not values. So defining PKT_TX_TUNNEL_MPLSINUDP (0x5ULL << 45)
won’t work.

Currently bits[48:45] are reserved for Tx tunnel types. Bits[63:49] and
bit 44 are already taken.
Bits [43:18] are free. That’s why we see a code comment there:

/* add new RX flags here */

/* add new TX flags here */

So I could have added MPLSINUDP as:
#define PKT_TX_TUNNEL_MPLSINUDP (1ULL << 18)


But I wanted to group all Tx tunnel types together which is logical and
update PKT_TX_TUNNEL_MASK accordingly. So to accommodate the new MPLSoUDP
flag, I had to move PKT_TX_MACSECto one bit position back from 44
to 43 and hence the code comment:
- * Bits 45:48 used for the tunnel type.
+ * Bits 44:48 used for the tunnel type.

But if this would cause a ABI breakage the option is to use bit 18 as
shown above and update the mask accordingly.

But the down side of this is that it will not be grouped together.
Please let me know if this is okay?

Thanks,
Harish
>
>Regards,
>Olivier
>

Re: [dpdk-dev] [PATCH v2 1/2] mbuf: introduce new Tx offload flag for MPLS-in-UDP

[Patil, Harish]

>

>On Thu, 8 Jun 2017 21:46:00 +0000, "Patil, Harish"
> wrote:
>> >Hi Rasesh,
>> >
>> >On Wed, 7 Jun 2017 00:43:48 -0700, Rasesh Mody 
>> >wrote:  
>> >> From: Harish Patil 
>> >> 
>> >> Some PMDs need to know the tunnel type in order to handle advance TX
>> >> features. This patch adds a new TX offload flag for MPLS-in-UDP
>>packets.
>> >> 
>> >> Signed-off-by: Harish Patil 
>> >> ---
>> >>  lib/librte_mbuf/rte_mbuf.c |2 ++
>> >>  lib/librte_mbuf/rte_mbuf.h |   17 ++---
>> >>  2 files changed, 12 insertions(+), 7 deletions(-)
>> >> 
>> >> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
>> >> index 0e3e36a..c2793fb 100644
>> >> --- a/lib/librte_mbuf/rte_mbuf.c
>> >> +++ b/lib/librte_mbuf/rte_mbuf.c
>> >> @@ -410,6 +410,7 @@ const char *rte_get_tx_ol_flag_name(uint64_t
>>mask)
>> >>   case PKT_TX_TUNNEL_IPIP: return "PKT_TX_TUNNEL_IPIP";
>> >>   case PKT_TX_TUNNEL_GENEVE: return "PKT_TX_TUNNEL_GENEVE";
>> >>   case PKT_TX_MACSEC: return "PKT_TX_MACSEC";
>> >> + case PKT_TX_TUNNEL_MPLSINUDP: return "PKT_TX_TUNNEL_MPLSINUDP";
>> >>   default: return NULL;
>> >>   }
>> >>  }
>> >> @@ -441,6 +442,7 @@ const char *rte_get_tx_ol_flag_name(uint64_t
>>mask)
>> >>   { PKT_TX_TUNNEL_GENEVE, PKT_TX_TUNNEL_MASK,
>> >> "PKT_TX_TUNNEL_NONE" },
>> >>   { PKT_TX_MACSEC, PKT_TX_MACSEC, NULL },
>> >> + { PKT_TX_TUNNEL_MPLSINUDP, PKT_TX_TUNNEL_MPLSINUDP, NULL },
>> >>   };
>> >>   const char *name;
>> >>   unsigned int i;
>> >> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
>> >> index 1cb0310..27ad421 100644
>> >> --- a/lib/librte_mbuf/rte_mbuf.h
>> >> +++ b/lib/librte_mbuf/rte_mbuf.h
>> >> @@ -197,19 +197,22 @@
>> >>   * Offload the MACsec. This flag must be set by the application to
>> >>enable
>> >>   * this offload feature for a packet to be transmitted.
>> >>   */
>> >> -#define PKT_TX_MACSEC(1ULL << 44)
>> >> +#define PKT_TX_MACSEC(1ULL << 43)
>> >
>> >I'm not sure it is suitable to change the value of an existing
>> >flag, since it breaks the ABI.
>> >
>> >  
>> >>  /**
>> >> - * Bits 45:48 used for the tunnel type.
>> >> + * Bits 44:48 used for the tunnel type.
>> >>   * When doing Tx offload like TSO or checksum, the HW needs to
>> >>configure the
>> >>   * tunnel type into the HW descriptors.
>> >>   */
>> >> -#define PKT_TX_TUNNEL_VXLAN   (0x1ULL << 45)
>> >> -#define PKT_TX_TUNNEL_GRE (0x2ULL << 45)
>> >> -#define PKT_TX_TUNNEL_IPIP(0x3ULL << 45)
>> >> -#define PKT_TX_TUNNEL_GENEVE  (0x4ULL << 45)
>> >> +/**< TX packet with MPLS-in-UDP RFC 7510 header. */
>> >> +#define PKT_TX_TUNNEL_MPLSINUDP (0x1ULL << 44)
>> >> +
>> >> +#define PKT_TX_TUNNEL_VXLAN   (0x2ULL << 44)
>> >> +#define PKT_TX_TUNNEL_GRE (0x3ULL << 44)
>> >> +#define PKT_TX_TUNNEL_IPIP(0x4ULL << 44)
>> >> +#define PKT_TX_TUNNEL_GENEVE  (0x5ULL << 45)
>> >>  /* add new TX TUNNEL type here */
>> >> -#define PKT_TX_TUNNEL_MASK(0xFULL << 45)
>> >> +#define PKT_TX_TUNNEL_MASK(0x1FULL << 44)
>> >>  
>> >>  /**
>> >>   * Second VLAN insertion (QinQ) flag.
>> >
>> >I dont understand why adding
>> >#define PKT_TX_TUNNEL_MPLSINUDP (0x5ULL << 45)
>> >wouldn't do the job?
>> >
>> >Currently, the tunnel mask is 0xF << 45, which gives 16 possible
>>values.  
>> 
>> [Harish]  Hi Olivier,
>> Not too sure whether I understand your comment.
>> My understanding is that those are bitmapped values for each Tx tunnel
>> type in the range [48:45].
>> They are not values. So defining PKT_TX_TUNNEL_MPLSINUDP (0x5ULL << 45)
>> won’t work.
>
>Currently, we have:
>
>#define PKT_TX_TUNNEL_VXLAN   (0x1ULL << 45)
>in binary: 000..000[0001]000..000
>
>#define PKT_TX_TUNNEL_GRE (0x2ULL << 45)
>in binary: 000..000[0010]000..000
>
>#define PKT_TX_TUNNEL_IPIP(0x3ULL << 45)
>in binary: 000..000[0011]000..000
>
>#define PKT_TX_TUNNEL_GENEVE  (0x4ULL << 45)
>in binary: 000..000[0100]000..000
>
>So, I'm still saying there's a room for 11 more values.
>
>
>
>Olivier
>
[Harish] Okay thanks, got it. I shall send the v2 patch.
I have to update the driver also to use it as a value rather than as
bitmapped value.
 

Re: [dpdk-dev] [PATCH v7 1/7] qede: add base driver

[Patil, Harish]

>

><...>
>
 +
 +#
 +# Add extra flags for base ecore driver files # to disable warnings
 +in them # # BASE_DRIVER_OBJS=$(patsubst %.c,%.o,$(notdir $(wildcard
 +$(SRCDIR)/base/*.c))) $(foreach obj, $(BASE_DRIVER_OBJS), $(eval
 +CFLAGS+=$(CFLAGS_BASE_DRIVER)))
>>>
>>> My eyes just caught this one, above line adds $(CFLAGS_BASE_DRIVER)
>>> many times to $(CFLAGS), but real intentions is add to obj specific
>>>CFLAGS
>>> and only being limited to base files.
>>>
>>> Like:
>>> $(foreach obj, $(BASE_DRIVER_OBJS), $(eval
>>> CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER)))
>>>
>>> Can you please fix this?
>> 
>> We will look into this, we plan to submit the fix as separate bug fix
>>patch in 17.05 timeframe.
>
>Reminder.

Hi Ferruh,
Yes, we are going to submit this along side few bug fixes.
Thanks.

>
>> 
>> Thanks!
>> -Rasesh
>> 
>>>
>>> Fixing this may give some build errors on non-base driver files,
>>>although not
>>> sure.
>>>
>>> Thanks,
>>> ferruh
>

Re: [dpdk-dev] [PATCH v2] app/testpmd: add bitrate stats option

[Patil, Harish]

>From: Remy Horton 
>
>Bit-rate collation should only be done by one core. This patch adds
>an option to select which core performs the bit-rate calculation,
>which is also disabled by default.
>
>Fixes: 7e4441c8efb9 ("app/testpmd: add bitrate statistics calculation")
>
>Signed-off-by: Remy Horton 
>Acked-by: Pablo de Lara 
>---
>
>Changes in v2:
>- Added parameter to documentation
>
> app/test-pmd/parameters.c | 19 +-
> app/test-pmd/testpmd.c| 36
>+--
> app/test-pmd/testpmd.h|  5 +
> doc/guides/testpmd_app_ug/run_app.rst |  4 
> 4 files changed, 53 insertions(+), 11 deletions(-)
>
>diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
>index 3f4d3a2..a0300eb 100644
>--- a/app/test-pmd/parameters.c
>+++ b/app/test-pmd/parameters.c
>@@ -201,7 +201,9 @@ usage(char* progname)
>   printf("  --disable-link-check: disable check on link status when "
>  "starting/stopping ports.\n");
>   printf("  --no-lsc-interrupt: disable link status change interrupt.\n");
>-  printf("  --no-rmv-interrupt: disable device removal interrupt.");
>+  printf("  --no-rmv-interrupt: disable device removal interrupt.\n");
>+  printf("  --bitrate-stats=N: set the logical core N to perform "
>+  "bit-rate calculation.\n");
> }
> 
> #ifdef RTE_LIBRTE_CMDLINE
>@@ -536,6 +538,9 @@ launch_args_parse(int argc, char** argv)
> #ifdef RTE_LIBRTE_LATENCY_STATS
>   { "latencystats",   1, 0, 0 },
> #endif
>+#ifdef RTE_LIBRTE_BITRATE
>+  { "bitrate-stats",  1, 0, 0 },
>+#endif
>   { "disable-crc-strip",  0, 0, 0 },
>   { "enable-lro", 0, 0, 0 },
>   { "enable-rx-cksum",0, 0, 0 },
>@@ -793,6 +798,18 @@ launch_args_parse(int argc, char** argv)
>" must be >= 0\n", n);
>   }
> #endif
>+#ifdef RTE_LIBRTE_BITRATE
>+  if (!strcmp(lgopts[opt_idx].name, "bitrate-stats")) {
>+  n = atoi(optarg);
>+  if (n >= 0) {
>+  bitrate_lcore_id = (lcoreid_t) n;
>+  bitrate_enabled = 1;
>+  } else
>+  rte_exit(EXIT_FAILURE,
>+   "invalid lcore id %d for 
>bitrate stats"
>+   " must be >= 0\n", n);
>+  }
>+#endif
>   if (!strcmp(lgopts[opt_idx].name, "disable-crc-strip"))
>   rx_mode.hw_strip_crc = 0;
>   if (!strcmp(lgopts[opt_idx].name, "enable-lro"))
>diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
>index 3a57348..cfd5382 100644
>--- a/app/test-pmd/testpmd.c
>+++ b/app/test-pmd/testpmd.c
>@@ -355,8 +355,12 @@ uint16_t nb_rx_queue_stats_mappings = 0;
> 
> unsigned max_socket = 0;
> 
>+#ifdef RTE_LIBRTE_BITRATE
> /* Bitrate statistics */
> struct rte_stats_bitrates *bitrate_data;
>+lcoreid_t bitrate_lcore_id;
>+uint8_t bitrate_enabled;
>+#endif
> 
> /* Forward function declarations */
> static void map_port_queue_stats_mapping_registers(uint8_t pi, struct
>rte_port *port);
>@@ -962,12 +966,18 @@ run_pkt_fwd_on_lcore(struct fwd_lcore *fc,
>packet_fwd_t pkt_fwd)
>   for (sm_id = 0; sm_id < nb_fs; sm_id++)
>   (*pkt_fwd)(fsm[sm_id]);
> #ifdef RTE_LIBRTE_BITRATE
>-  tics_current = rte_rdtsc();
>-  if (tics_current - tics_datum >= tics_per_1sec) {
>-  /* Periodic bitrate calculation */
>-  for (idx_port = 0; idx_port < cnt_ports; idx_port++)
>-  rte_stats_bitrate_calc(bitrate_data, idx_port);
>-  tics_datum = tics_current;
>+  if (bitrate_enabled != 0 &&
>+  bitrate_lcore_id == rte_lcore_id()) {
>+  tics_current = rte_rdtsc();
>+  if (tics_current - tics_datum >= tics_per_1sec) {
>+  /* Periodic bitrate calculation */
>+  for (idx_port = 0;
>+  idx_port < cnt_ports;
>+  idx_port++)
>+  rte_stats_bitrate_calc(bitrate_data,
>+  idx_port);
>+  tics_datum = tics_current;
>+  }
>   }
> #endif
> #ifdef RTE_LIBRTE_LATENCY_STATS
>@@ -2238,6 +2248,9 @@ main(int argc, char** argv)
>   rte_panic("Empty set of forwarding logical cores - check the "
> "core mask supplied in the command parameters\n");
> 
>+  /* Bitra

[dpdk-dev] app/testpmd: compilation error with bitrate/latency config flags disabled

[Patil, Harish]

Hi,
Seeing compilation errors with DPDK 17.05-rc3 when I happened to disable
bitrate/latency configs during our internal testing.
CONFIG_RTE_LIBRTE_BITRATE=n and
CONFIG_RTE_LIBRTE_LATENCY_STATS=n.

/home/root1/hpatil/17.05-rc3/dpdk/app/test-pmd/testpmd.c: In function
?main?:
/home/root1/hpatil/17.05-rc3/dpdk/app/test-pmd/testpmd.c:2242:2: error:
?bitrate_enabled? undeclared (first use in this function)
  bitrate_enabled = 0;
  ^
/home/root1/hpatil/17.05-rc3/dpdk/app/test-pmd/testpmd.c:2242:2: note:
each undeclared identifier is reported only once for each function it
appears in
make[5]: *** [testpmd.o] Error 1
make[5]: *** Waiting for unfinished jobs

Does the patch you sent for review: "[PATCH] app/testpmd: disable latency
stats by default” address this?
Please check.

Thanks,

harish

Re: [dpdk-dev] [PATCH] net/bnx2x: reserve enough headroom for mbuf prepend

[Patil, Harish]

From: zhouyangchao mailto:zhouya...@gmail.com>>
Date: Wednesday, March 7, 2018 at 10:57 PM
To: Ferruh Yigit mailto:ferruh.yi...@intel.com>>
Cc: "dev@dpdk.org" mailto:dev@dpdk.org>>, 
Harish Patil mailto:harish.pa...@cavium.com>>, "Mody, 
Rasesh" mailto:rasesh.m...@cavium.com>>
Subject: Re: [dpdk-dev] [PATCH] net/bnx2x: reserve enough headroom for mbuf 
prepend

When allocating a new mbuf for Rx, the value of m->data_off should be
reset to its default value (RTE_PKTMBUF_HEADROOM), instead of reusing
the previous undefined value, which could cause the packet to have a too
small or too high headroom.

On Mon, Mar 5, 2018 at 11:28 PM Ferruh Yigit 
mailto:ferruh.yi...@intel.com>> wrote:
On 2/6/2018 11:21 AM, zhouyangchao wrote:

Can you please provide more information why this patch is needed?

> Signed-off-by: Yangchao Zhou mailto:zhouya...@gmail.com>>
> ---
>  drivers/net/bnx2x/bnx2x_rxtx.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/bnx2x/bnx2x_rxtx.c b/drivers/net/bnx2x/bnx2x_rxtx.c
> index a0d4ac9..d8a3225 100644
> --- a/drivers/net/bnx2x/bnx2x_rxtx.c
> +++ b/drivers/net/bnx2x/bnx2x_rxtx.c
> @@ -140,7 +140,8 @@ bnx2x_dev_rx_queue_setup(struct rte_eth_dev *dev,
>   return -ENOMEM;
>   }
>   rxq->sw_ring[idx] = mbuf;
> - rxq->rx_ring[idx] = mbuf->buf_iova;
> + rxq->rx_ring[idx] =
> + rte_cpu_to_le_64(rte_mbuf_data_iova_default(mbuf));
>   }
>   rxq->pkt_first_seg = NULL;
>   rxq->pkt_last_seg = NULL;
> @@ -400,7 +401,8 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts, 
> uint16_t nb_pkts)
>
>   rx_mb = rxq->sw_ring[bd_cons];
>   rxq->sw_ring[bd_cons] = new_mb;
> - rxq->rx_ring[bd_prod] = new_mb->buf_iova;
> + rxq->rx_ring[bd_prod] =
> + rte_cpu_to_le_64(rte_mbuf_data_iova_default(new_mb));
>
>   rx_pref = NEXT_RX_BD(bd_cons) & MAX_RX_BD(rxq);
>   rte_prefetch0(rxq->sw_ring[rx_pref]);
> @@ -409,7 +411,7 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts, 
> uint16_t nb_pkts)
>   rte_prefetch0(&rxq->sw_ring[rx_pref]);
>   }
>
> - rx_mb->data_off = pad;
> + rx_mb->data_off = pad + RTE_PKTMBUF_HEADROOM;
>   rx_mb->nb_segs = 1;
>   rx_mb->next = NULL;
>   rx_mb->pkt_len = rx_mb->data_len = len;
>


Acked-by: Harish Patil mailto:harish.pa...@cavium.com>>

Re: [dpdk-dev] [PATCH v3 02/10] app/testpmd: convert to new Ethdev Rx offloads API

[Patil, Harish]

-Original Message-
From: dev  on behalf of Shahaf Shuler

Date: Tuesday, December 26, 2017 at 1:44 AM
To: "jingjing...@intel.com" ,
"ferruh.yi...@intel.com" 
Cc: "dev@dpdk.org" 
Subject: [dpdk-dev] [PATCH v3 02/10] app/testpmd: convert to new Ethdev
Rx  offloads API

>Ethdev Rx offloads API has changed since:
>
>commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API")
>
>Convert the application to use the new API. The is no functionality
>changes rather simple conversion of the flags.
>
>Signed-off-by: Shahaf Shuler 
>---
> app/test-pmd/cmdline.c| 51 +++---
> app/test-pmd/config.c | 36 +++--
> app/test-pmd/parameters.c | 32 +-
> app/test-pmd/testpmd.c| 19 +++-
> 4 files changed, 77 insertions(+), 61 deletions(-)
>
>diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
>index f71d96301..d8c73a9b1 100644
>--- a/app/test-pmd/cmdline.c
>+++ b/app/test-pmd/cmdline.c
>@@ -1577,6 +1577,7 @@ cmd_config_max_pkt_len_parsed(void *parsed_result,
>   __attribute__((unused)) void *data)
> {
>   struct cmd_config_max_pkt_len_result *res = parsed_result;
>+  uint64_t rx_offloads = rx_mode.offloads;
> 
>   if (!all_ports_stopped()) {
>   printf("Please stop all ports first\n");
>@@ -1594,14 +1595,16 @@ cmd_config_max_pkt_len_parsed(void *parsed_result,
> 
>   rx_mode.max_rx_pkt_len = res->value;
>   if (res->value > ETHER_MAX_LEN)
>-  rx_mode.jumbo_frame = 1;
>+  rx_offloads |= DEV_RX_OFFLOAD_JUMBO_FRAME;
>   else
>-  rx_mode.jumbo_frame = 0;
>+  rx_offloads &= ~DEV_RX_OFFLOAD_JUMBO_FRAME;
>   } else {
>   printf("Unknown parameter\n");
>   return;
>   }
> 
>+  rx_mode.offloads = rx_offloads;
>+
>   init_port_config();
> 
>   cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
>@@ -1703,6 +1706,7 @@ cmd_config_rx_mode_flag_parsed(void *parsed_result,
>   __attribute__((unused)) void *data)
> {
>   struct cmd_config_rx_mode_flag *res = parsed_result;
>+  uint64_t rx_offloads = rx_mode.offloads;
> 
>   if (!all_ports_stopped()) {
>   printf("Please stop all ports first\n");
>@@ -1711,48 +1715,48 @@ cmd_config_rx_mode_flag_parsed(void
>*parsed_result,
> 
>   if (!strcmp(res->name, "crc-strip")) {
>   if (!strcmp(res->value, "on"))
>-  rx_mode.hw_strip_crc = 1;
>+  rx_offloads |= DEV_RX_OFFLOAD_CRC_STRIP;
>   else if (!strcmp(res->value, "off"))
>-  rx_mode.hw_strip_crc = 0;
>+  rx_offloads &= ~DEV_RX_OFFLOAD_CRC_STRIP;
>   else {
>   printf("Unknown parameter\n");
>   return;
>   }
>   } else if (!strcmp(res->name, "scatter")) {
>-  if (!strcmp(res->value, "on"))
>-  rx_mode.enable_scatter = 1;
>-  else if (!strcmp(res->value, "off"))
>-  rx_mode.enable_scatter = 0;
>-  else {
>+  if (!strcmp(res->value, "on")) {
>+  rx_offloads |= DEV_RX_OFFLOAD_SCATTER;
>+  } else if (!strcmp(res->value, "off")) {
>+  rx_offloads &= ~DEV_RX_OFFLOAD_SCATTER;
>+  } else {
>   printf("Unknown parameter\n");
>   return;
>   }
>   } else if (!strcmp(res->name, "rx-cksum")) {
>   if (!strcmp(res->value, "on"))
>-  rx_mode.hw_ip_checksum = 1;
>+  rx_offloads |= DEV_RX_OFFLOAD_CHECKSUM;
>   else if (!strcmp(res->value, "off"))
>-  rx_mode.hw_ip_checksum = 0;
>+  rx_offloads &= ~DEV_RX_OFFLOAD_CHECKSUM;
>   else {
>   printf("Unknown parameter\n");
>   return;
>   }
>   } else if (!strcmp(res->name, "rx-timestamp")) {
>   if (!strcmp(res->value, "on"))
>-  rx_mode.hw_timestamp = 1;
>+  rx_offloads |= DEV_RX_OFFLOAD_TIMESTAMP;
>   else if (!strcmp(res->value, "off"))
>-  rx_mode.hw_timestamp = 0;
>+  rx_offloads &= ~DEV_RX_OFFLOAD_TIMESTAMP;
>   else {
>   printf("Unknown parameter\n");
>   return;
>   }
>   } else if (!strcmp(res->name, "hw-vlan")) {
>   if (!strcmp(res->value, "on")) {
>-  rx_mode.hw_vlan_filter = 1;
>-  rx_mode.hw_vlan_strip  = 1;
>+  rx_offloads |= (DEV_RX_OFFLOAD_VLAN_FILTER |
>+  DEV_RX_OFFLOAD_VLAN_STRIP);
>  

[dpdk-dev] Compilation errors in drivers/event/opdl/

[Patil, Harish]

Hi,

I am seeing below compilation errors in drivers/event/opdl/, this is with
cloned latest DPDK (git clone http://dpdk.org/git/dpdk).

..
..
/home2/hpatil/e4/jan19-inbox-submit/dpdk/drivers/event/opdl/opdl_evdev_xsta
ts.c: In function ‘opdl_xstats_get_names’:
/home2/hpatil/e4/jan19-inbox-submit/dpdk/drivers/event/opdl/opdl_evdev_xsta
ts.c:89:2: error: ‘for’ loop initial declarations are only allowed in
C99 mode
  for (uint32_t j = 0; j < max_num_port_xstat; j++) {
  ^
/home2/hpatil/e4/jan19-inbox-submit/dpdk/drivers/event/opdl/opdl_evdev_xsta
ts.c:89:2: note: use option -std=c99 or -std=gnu99 to compile your code
/home2/hpatil/e4/jan19-inbox-submit/dpdk/drivers/event/opdl/opdl_evdev_xsta
ts.c: In function ‘opdl_xstats_get’:
/home2/hpatil/e4/jan19-inbox-submit/dpdk/drivers/event/opdl/opdl_evdev_xsta
ts.c:124:2: error: ‘for’ loop initial declarations are only allowed in
C99 mode
  for (uint32_t i = 0; i < n; i++) {
  ^
/home2/hpatil/e4/jan19-inbox-submit/dpdk/drivers/event/opdl/opdl_evdev_xsta
ts.c: In function ‘opdl_xstats_get_by_name’:
/home2/hpatil/e4/jan19-inbox-submit/dpdk/drivers/event/opdl/opdl_evdev_xsta
ts.c:145:2: error: ‘for’ loop initial declarations are only allowed in
C99 mode
  for (uint32_t i = 0; i < max_index; i++) {
..
..
  ^

Thanks,
Harish

Re: [dpdk-dev] Compilation errors in drivers/event/opdl/

[Patil, Harish]

-Original Message-
From: "Jacob,  Jerin" 
Date: Saturday, January 20, 2018 at 12:56 AM
To: Harish Patil 
Cc: "liang.j...@intel.com" ,
"peter.mccar...@intel.com" , "dev@dpdk.org"

Subject: Re: [dpdk-dev] Compilation errors in drivers/event/opdl/

>-Original Message-
>> Date: Sat, 20 Jan 2018 05:18:30 +
>> From: "Patil, Harish" 
>> To: "liang.j...@intel.com" ,
>>  "peter.mccar...@intel.com" 
>> CC: "dev@dpdk.org" 
>> Subject: [dpdk-dev] Compilation errors in drivers/event/opdl/
>> 
>> [This sender failed our fraud detection checks and may not be who they
>>appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>> 
>> Hi,
>> 
>> I am seeing below compilation errors in drivers/event/opdl/, this is
>>with
>> cloned latest DPDK (git clone http://dpdk.org/git/dpdk).
>> 
>> ..
>> ..
>> 
>>/home2/hpatil/e4/jan19-inbox-submit/dpdk/drivers/event/opdl/opdl_evdev_xs
>>ta
>> ts.c: In function ‘opdl_xstats_get_names’:
>> 
>>/home2/hpatil/e4/jan19-inbox-submit/dpdk/drivers/event/opdl/opdl_evdev_xs
>>ta
>> ts.c:89:2: error: ‘for’ loop initial declarations are only allowed
>>in
>> C99 mode
>>   for (uint32_t j = 0; j < max_num_port_xstat; j++) {
>>   ^
>> 
>>/home2/hpatil/e4/jan19-inbox-submit/dpdk/drivers/event/opdl/opdl_evdev_xs
>>ta
>> ts.c:89:2: note: use option -std=c99 or -std=gnu99 to compile your code
>> 
>>/home2/hpatil/e4/jan19-inbox-submit/dpdk/drivers/event/opdl/opdl_evdev_xs
>>ta
>> ts.c: In function ‘opdl_xstats_get’:
>> 
>>/home2/hpatil/e4/jan19-inbox-submit/dpdk/drivers/event/opdl/opdl_evdev_xs
>>ta
>> ts.c:124:2: error: ‘for’ loop initial declarations are only allowed
>>in
>> C99 mode
>>   for (uint32_t i = 0; i < n; i++) {
>>   ^
>> 
>>/home2/hpatil/e4/jan19-inbox-submit/dpdk/drivers/event/opdl/opdl_evdev_xs
>>ta
>> ts.c: In function ‘opdl_xstats_get_by_name’:
>> 
>>/home2/hpatil/e4/jan19-inbox-submit/dpdk/drivers/event/opdl/opdl_evdev_xs
>>ta
>> ts.c:145:2: error: ‘for’ loop initial declarations are only allowed
>>in
>> C99 mode
>>   for (uint32_t i = 0; i < max_index; i++) {
>
>
>Tested with gcc(7.2 and 5.3) and clang(5.0.1) versions. Found no issues.
>Which compiler you are using?
>
>
>> ..
>> ..
>>   ^
>> 
>> Thanks,
>> Harish
>> 
>> 
>> 
>> 
>> 

This is older GCC 4.8.5 that comes inbox with RH7.2
So if its working with later GCC versions then please can ignore this.
Thanks.
>

Re: [dpdk-dev] [PATCH] net/qede:fix the bug about pointer params may NULL

[Patil, Harish]

-Original Message-
From: dev  on behalf of Rongqiang XIE

Date: Thursday, August 24, 2017 at 12:12 AM
To: "Mody, Rasesh" 
Cc: "dev@dpdk.org" , Rongqiang XIE 
Subject: [dpdk-dev] [PATCH] net/qede:fix the bug about pointer params
may NULL

>In function qede_rss_reta_update(),the pointer params returned from
>call to function rte_zmalloc() may be NULL and will be dereferenced.
>So, should judge the params is NULL or not.
>
>Signed-off-by: Rongqiang XIE 
>---
> drivers/net/qede/qede_ethdev.c | 4 
> 1 file changed, 4 insertions(+)
>
>diff --git a/drivers/net/qede/qede_ethdev.c
>b/drivers/net/qede/qede_ethdev.c
>index 0e05989..4e9e89f 100644
>--- a/drivers/net/qede/qede_ethdev.c
>+++ b/drivers/net/qede/qede_ethdev.c
>@@ -2012,6 +2012,10 @@ int qede_rss_reta_update(struct rte_eth_dev
>*eth_dev,
>   memset(&vport_update_params, 0, sizeof(vport_update_params));
>   params = rte_zmalloc("qede_rss", sizeof(*params) * edev->num_hwfns,
>RTE_CACHE_LINE_SIZE);
>+  if (params == NULL) {
>+  DP_ERR(edev, "failed to allocate memory\n");
>+  return -ENOMEM;
>+  }
> 
>   for (i = 0; i < reta_size; i++) {
>   idx = i / RTE_RETA_GROUP_SIZE;
>-- 
>1.8.3.1
>
>
>Acked-by: Harish Patil 

Re: [dpdk-dev] [PATCH 02/10] net/qede: fix compilation with -Og

[Patil, Harish]

-Original Message-
From: dev  on behalf of Olivier Matz

Date: Monday, September 11, 2017 at 8:13 AM
To: "dev@dpdk.org" 
Subject: [dpdk-dev] [PATCH 02/10] net/qede: fix compilation with -Og

>The compilation with gcc-6.3.0 and EXTRA_CFLAGS=-Og gives the following
>error:
>
>  CC qede_rxtx.o
>  qede_rxtx.c: In function ‘qede_start_queues’:
>  qede_rxtx.c:797:9: error: ‘rc’ may be used uninitialized in this
>function [-Werror=maybe-uninitialized]
>return rc;
>   ^~
>
>If there is no Rx or Tx queue, rc will not be initialized. Fix it
>by initializing rc to -1.
>
>Fixes: 4c4bdadfa9e7 ("net/qede: refactoring multi-queue implementation")
>
>Signed-off-by: Olivier Matz 
>---
> drivers/net/qede/qede_rxtx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
>index 5c3613c7c..76e24abff 100644
>--- a/drivers/net/qede/qede_rxtx.c
>+++ b/drivers/net/qede/qede_rxtx.c
>@@ -780,7 +780,7 @@ int qede_start_queues(struct rte_eth_dev *eth_dev)
> {
>   struct qede_dev *qdev = QEDE_INIT_QDEV(eth_dev);
>   uint8_t id;
>-  int rc;
>+  int rc = -1;
> 
>   for_each_rss(id) {
>   rc = qede_rx_queue_start(eth_dev, id);
>-- 
>2.11.0

Acked-by: Harish Patil 

>

Re: [dpdk-dev] [PATCH v6 4/4] doc: add details on ethdev offloads API

[Patil, Harish]

-Original Message-
From: dev  on behalf of Shahaf Shuler

Date: Wednesday, October 4, 2017 at 1:18 AM
To: "konstantin.anan...@intel.com" ,
"tho...@monjalon.net" , "arybche...@solarflare.com"
, "Jacob,  Jerin"
, "ferruh.yi...@intel.com"

Cc: "dev@dpdk.org" 
Subject: [dpdk-dev] [PATCH v6 4/4] doc: add details on ethdev offloads API

>Add the programmers guide details on the new offloads API introduced
>by commits:
>
>commit 67a1a59b597f ("ethdev: introduce Rx queue offloads API")
>commit f883eb32e2d4 ("ethdev: introduce Tx queue offloads API")
>
>Signed-off-by: Shahaf Shuler 
>Reviewed-by: John McNamara 
>---
> doc/guides/prog_guide/poll_mode_drv.rst | 20 
> 1 file changed, 20 insertions(+)
>
>diff --git a/doc/guides/prog_guide/poll_mode_drv.rst
>b/doc/guides/prog_guide/poll_mode_drv.rst
>index 8922e39f4..423170997 100644
>--- a/doc/guides/prog_guide/poll_mode_drv.rst
>+++ b/doc/guides/prog_guide/poll_mode_drv.rst
>@@ -310,6 +310,26 @@ exported by each PMD. The list of flags and their
>precise meaning is
> described in the mbuf API documentation and in the in :ref:`Mbuf Library
> `, section "Meta Information".
> 
>+Per-Port and Per-Queue Offloads
>+^^^
>+
>+In the DPDK offload API, offloads are divided into per-port and
>per-queue offloads.
>+The different offloads capabilities can be queried using
>``rte_eth_dev_info_get()``.
>+Supported offloads can be either per-port or per-queue.
>+
>+Offloads are enabled using the existing ``DEV_TX_OFFLOAD_*`` or
>``DEV_RX_OFFLOAD_*`` flags.
>+Per-port offload configuration is set using ``rte_eth_dev_configure``.
>+Per-queue offload configuration is set using ``rte_eth_rx_queue_setup``
>and ``rte_eth_tx_queue_setup``.
>+To enable per-port offload, the offload should be set on both device
>configuration and queue setup.
>+In case of a mixed configuration the queue setup shall return with an
>error.
>+To enable per-queue offload, the offload can be set only on the queue
>setup.
>+Offloads which are not enabled are disabled by default.
>+
>+For an application to use the Tx offloads API it should set the
>``ETH_TXQ_FLAGS_IGNORE`` flag in the ``txq_flags`` field located in
>``rte_eth_txconf`` struct.
>+In such cases it is not required to set other flags in ``txq_flags``.
>+For an application to use the Rx offloads API it should set the
>``ignore_offload_bitfield`` bit in the ``rte_eth_rxmode`` struct.
>+In such cases it is not required to set other bitfield offloads in the
>``rxmode`` struct.
>+
> Poll Mode Driver API
> 
> 
>-- 
>2.12.0
>
Hi Shahaf,
Have a minor question here.
In the documentation it is stated that:
"To enable per-port offload, the offload should be set on both device
configuration and queue setup.”
Our NIC supports only port-level offloads. So my understanding is that to
enable per-port offload we just have to fill in
rx_offload_capa/tx_offload_capa in dev_infos_get() routine. So I didn’t
understand what is meant by ' both device configuration and queue setup’
here.
Pls let me know.
Thanks.



>

Re: [dpdk-dev] [PATCH] doc: update new ethdev offload API description

[Patil, Harish]

-Original Message-
From: Ferruh Yigit 
Date: Friday, March 16, 2018 at 8:51 AM
To: John McNamara , Marko Kovacevic

Cc: "dev@dpdk.org" , Ferruh Yigit ,
Thomas Monjalon , "shah...@mellanox.com"
, , Harish Patil 
Subject: [PATCH] doc: update new ethdev offload API description

>Don't mandate API to pass port offload configuration during queue setup,
>this is unnecessary for devices that support only port level offloads.
>
>Fixes: 81ac560dc1b4 ("doc: add details on ethdev offloads API")
>Cc: shah...@mellanox.com
>
>Signed-off-by: Ferruh Yigit 
>---
>Cc: Patil, Harish 
>
>Btw, this expectation from API should be clear from source code and API
>documentation (doxygen comments in header file) instead of
>documentation. Am I missing something or we are doing something wrong
>here?
>---
> doc/guides/prog_guide/poll_mode_drv.rst | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
>diff --git a/doc/guides/prog_guide/poll_mode_drv.rst
>b/doc/guides/prog_guide/poll_mode_drv.rst
>index e5d01874e..3247f309f 100644
>--- a/doc/guides/prog_guide/poll_mode_drv.rst
>+++ b/doc/guides/prog_guide/poll_mode_drv.rst
>@@ -303,9 +303,7 @@ Supported offloads can be either per-port or
>per-queue.
> Offloads are enabled using the existing ``DEV_TX_OFFLOAD_*`` or
>``DEV_RX_OFFLOAD_*`` flags.
> Per-port offload configuration is set using ``rte_eth_dev_configure``.
> Per-queue offload configuration is set using ``rte_eth_rx_queue_setup``
>and ``rte_eth_tx_queue_setup``.
>-To enable per-port offload, the offload should be set on both device
>configuration and queue setup.
>-In case of a mixed configuration the queue setup shall return with an
>error.
>-To enable per-queue offload, the offload can be set only on the queue
>setup.
>+Per-port offloads should be set on the port configuration. Queue
>offloads should be set on the queue configuration.
> Offloads which are not enabled are disabled by default.
> 
> For an application to use the Tx offloads API it should set the
>``ETH_TXQ_FLAGS_IGNORE`` flag in the ``txq_flags`` field located in
>``rte_eth_txconf`` struct.
>-- 
>2.13.6
>
Acked-by: Harish Patil 

>

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Patil, Harish]

-Original Message-
From: Thomas Monjalon 
Date: Friday, March 30, 2018 at 6:47 AM
To: "dev@dpdk.org" 
Cc: Ajit Khaparde , "Jacob,  Jerin"
, "Thotton, Shijith"
, "Shukla, Santosh"
, Rahul Lakkireddy
, John Daley , Wenzhuo
Lu , Konstantin Ananyev
, Beilei Xing , Qi
Zhang , Jingjing Wu , Adrien
Mazarguil , Nelio Laranjeiro
, Yongseok Koh , Shahaf
Shuler , Tomasz Duszynski , Jianbo
Liu , Alejandro Lucero
, Hemant Agrawal ,
Shreyansh Jain , Harish Patil
, "Mody, Rasesh" , Andrew
Rybchenko , Shrikrishna Khare
, Maxime Coquelin , Allain
Legacy , Bruce Richardson
, Gaetan Rivet ,
Olivier Matz 
Subject: Survey for final decision about per-port offload API

>There are some discussions about a specific part of the offload API:
>   "To enable per-port offload, the offload should be set on both
>   device configuration and queue setup."
>
>It means the application must repeat the port offload flags
>in rte_eth_conf.[rt]xmode.offloads and rte_eth_[rt]xconf.offloads,
>when calling respectively rte_eth_dev_configure() and
>rte_eth_[rt]x_queue_setup for each queue.
>
>The PMD must check if there is mismatch, i.e. a port offload not
>repeated in queue setup.
>There is a proposal to do this check at ethdev level:
>   http://dpdk.org/ml/archives/dev/2018-March/094023.html
>
>It was also proposed to relax the API and allow "forgetting" port
>offloads in queue offloads:
>   http://dpdk.org/ml/archives/dev/2018-March/092978.html
>
>It would mean the offloads applied to a queue result of OR operation:
>   rte_eth_conf.[rt]xmode.offloads | rte_eth_[rt]xconf.offloads
>
>1/ Do you agree with above API change?

Yes. But pls confirm that this would still work properly if RX supports
port-only based offloads and doesn’t support queue based offloads at all,
as advertised in dev_infos_get().

dev_info->rx_queue_offload_capa = 0 and
dev_info->rx_offload_capa = (DEV_RX_OFFLOAD_IPV4_CKSUM | ...);


>
>
>If we agree with this change, we need to update the documentation
>and remove the checks in PMDs.
>Note: no matter what is decided here, 18.05-rc1 should have all PMDs
>switched to the API which was defined in 17.11.
>Given that API is new and not yet adopted by the applications,
>the sonner it is fixed, the better.
>
>2/ Should we do this change in 18.05-rc2?
>
Yes
>
>At the same time, we want to make clear that an offload enabled at
>port level, cannot be disabled at queue level.
>
>3/ Do you agree with above statement (to be added in the doc)?
Yes
>
>
>There is the same kind of confusion in the offload capabilities:
>   rte_eth_dev_info.[rt]x_offload_capa
>   rte_eth_dev_info.[rt]x_queue_offload_capa
>The queue capabilities must be a subset of port capabilities,
>i.e. every queue capabilities must be reported as port capabilities.
>But the port capabilities should be reported at queue level
>only if it can be applied to a specific queue.
>
>4/ Do you agree with above statement (to be added in the doc)?

Yes
>
>
>Please give your opinion on questions 1, 2, 3 and 4.
>Answering by yes/no may be sufficient in most cases :)
>Thank you
>
>

Re: [dpdk-dev] Survey for final decision about per-port offload API

[Patil, Harish]

-Original Message-
From: Thomas Monjalon 
Date: Monday, April 2, 2018 at 1:10 PM
To: Harish Patil 
Cc: "dev@dpdk.org" , Ajit Khaparde
, "Jacob,  Jerin"
, "Thotton, Shijith"
, "Shukla, Santosh"
, Rahul Lakkireddy
, John Daley , Wenzhuo
Lu , Konstantin Ananyev
, Beilei Xing , Qi
Zhang , Jingjing Wu , Adrien
Mazarguil , Nelio Laranjeiro
, Yongseok Koh , Shahaf
Shuler , Tomasz Duszynski , Jianbo
Liu , Alejandro Lucero
, Hemant Agrawal ,
Shreyansh Jain , "Mody, Rasesh"
, Andrew Rybchenko ,
Shrikrishna Khare , Maxime Coquelin
, Allain Legacy ,
Bruce Richardson , Gaetan Rivet
, Olivier Matz 
Subject: Re: Survey for final decision about per-port offload API

>02/04/2018 19:39, Patil, Harish:
>> >It was also proposed to relax the API and allow "forgetting" port
>> >offloads in queue offloads:
>> >http://dpdk.org/ml/archives/dev/2018-March/092978.html
>> >
>> >It would mean the offloads applied to a queue result of OR operation:
>> >rte_eth_conf.[rt]xmode.offloads | rte_eth_[rt]xconf.offloads
>> >
>> >1/ Do you agree with above API change?
>> 
>> Yes. But pls confirm that this would still work properly if RX supports
>> port-only based offloads and doesn’t support queue based offloads at
>>all,
>> as advertised in dev_infos_get().
>> 
>> dev_info->rx_queue_offload_capa = 0 and
>> dev_info->rx_offload_capa = (DEV_RX_OFFLOAD_IPV4_CKSUM | ...);
>
>Yes, of course, no queue offload at all is possible.
>
Okay, thanks.
>

Re: [dpdk-dev] vf init issue with patch igb_uio: issue FLR during open and release of device file

[Patil, Harish]

-Original Message-
From: dev  on behalf of Ferruh Yigit

Date: Wednesday, September 13, 2017 at 10:06 AM
To: "Hu, Xuekun" , "Thotton, Shijith"
, "Yang, Qiming" ,
Gregory Etelson 
Cc: "dev@dpdk.org" , "Tan, Jianfeng" 
Subject: Re: [dpdk-dev] vf init issue with patch igb_uio: issue FLR during
open and release of device file

>On 9/13/2017 3:25 PM, Hu, Xuekun wrote:
>> I met the same issue too, only with i40e 2.1.26 PF kernel driver.
>> 
>> -Original Message-
>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
>> Sent: Wednesday, September 13, 2017 7:04 PM
>> To: Shijith Thotton ; Yang, Qiming
>>; Gregory Etelson 
>> Cc: dev@dpdk.org; Tan, Jianfeng 
>> Subject: Re: [dpdk-dev] vf init issue with patch igb_uio: issue FLR
>>during open and release of device file
>> 
>> On 9/13/2017 11:48 AM, Shijith Thotton wrote:
>>> On Wed, Sep 13, 2017 at 07:51:30AM +, Yang, Qiming wrote:
Hi, Shijith

 

VF init error will happen after apply your patch, error log as
below. If
revert your commit, all things work well. And this issue is not
only occur
in i40 VF but also ixgbe.
>
>Hi Qiming,
>
>I can reproduce the issue for the case:
>
>1- i40e 2.1.26 PF kernel driver (NOT reproduced with 1.6.27-k)
>2- DPDK app run on host, so both PF and VF are in host. Linux driver for
>PF and DPDK for VF. (When VF used in a VM, Linux PF on host and DPDK VF
>on guest, this works fine)
>
>And I confirm the function igbuio_pci_open() added with below patch is
>causing it.
>
>igbuio_pci_open() does:
>pci_reset_function(dev);
>pci_set_master(dev);
>
>Don't know yet root cause of the error, will dig more.
>

Could you help to check it soon?

 

[root@localhost app]# ./testpmd -c 7 -n 4 -- -i

EAL: Detected 10 lcore(s)

EAL: No free hugepages reported in hugepages-1048576kB

EAL: Probing VFIO support...

EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using
unreliable clock cycles !

EAL: PCI device :00:03.0 on NUMA socket -1

EAL:   Invalid NUMA socket, default to 0

EAL:   probe driver: 8086:154c net_i40e_vf

i40evf_init_vf(): init_adminq failed: -53

i40evf_dev_init(): Init vf failed

EAL: Requested device :00:03.0 cannot be used

 

commit b58eedfc7dd57eef6d12e2c654a52c834f36084a
Author: Shijith Thotton 
Date: Fri Jul 7 16:43:51 2017 +0530

igb_uio: issue FLR during open and release of device file

Set UIO info device file operations open and release. Call pci
reset
function inside open and release to clear device state at start
and end.
Copied this behaviour from vfio_pci kernel module code. With this
patch,
it is not mandatory to issue FLR by PMD's during init and close.

Bus master enable and disable are added in open and release
respectively
to take care of device DMA.

Signed-off-by: Shijith Thotton 
Reviewed-by: Jianfeng Tan 
Acked-by: Ferruh Yigit 
Acked-by: Gregory Etelson 

 

Best Regard,

Yang Qiming

 
>>>
>>> Hi Yang Qiming,
>>>
>>> We didn't face this issue while preparing patch. I think, Gregory
>>> tested it for Intel NICs. Adding more people to the loop for help.
>>>
>> 
>> I will try to reproduce the issue.
>> 
>>> Shijith

[Harish] We are seeing similar issue with the bringup of qede VF devices
due to this patch.
Could we revert this and leave it to individual PMDs to manage it?
>>

Re: [dpdk-dev] vf init issue with patch igb_uio: issue FLR during open and release of device file

[Patil, Harish]

-Original Message-
From: "Thotton, Shijith" 
Date: Sunday, September 17, 2017 at 11:49 PM
To: "Yang, Qiming" , Harish Patil

Cc: "Zhang, Helin" , Gregory Etelson
, "tho...@monjalon.net" ,
"dev@dpdk.org" , "Tan, Jianfeng" ,
"Thotton, Shijith" , "Hu, Xuekun"
, "Yigit, Ferruh" , "Li,
Xiaoyun" 
Subject: Re: [dpdk-dev] vf init issue with patch igb_uio: issue FLR during
open and release of device file

>On Mon, Sep 18, 2017 at 03:50:30AM +, Yang, Qiming wrote:
>> Sorry, Gregory and Shijith
>> 
>> I misunderstand your advice.
>> If we only remove PCI reset at igbuio_pci_open, not include
>>igbuio_pci_release, I think it is a good solution.
>> It reserve the functional of this patch and we have test on FVL
>>10G/40G/25G, all work fine.
>> 
>
>Thanks Qiming. Glad to hear that removing pci_reset_function from
>igbuio_pci_open
>fixed the issue for Intel NICs.
>
>Harish,
>
>Please let us know the behavior with QEDE. Reverting won't be necessary
>if the
>fix works for all.
>
>Thanks,
>Shijith

[Harish] Shijith,
Removing pci_reset_function() from open() seems good enough.
Thanks.

>
>> > -Original Message-
>> > From: Zhang, Helin
>> > Sent: Monday, September 18, 2017 10:39 AM
>> > To: Yang, Qiming ; Gregory Etelson
>> > ; tho...@monjalon.net
>> > Cc: dev@dpdk.org; Tan, Jianfeng ; Thotton,
>>Shijith
>> > ; Hu, Xuekun ; Yigit,
>> > Ferruh ; Patil, Harish
>>; Li,
>> > Xiaoyun 
>> > Subject: RE: [dpdk-dev] vf init issue with patch igb_uio: issue FLR
>>during open
>> > and release of device file
>> > 
>> > Hi guys
>> > 
>> > May I suggest to revert the patch first, as it blocks existing
>>functionalities.
>> > Then the original authors can add it back with a fix?
>> > 
>> > Regards,
>> > Helin
>> > 
>> > -Original Message-
>> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yang, Qiming
>> > Sent: Monday, September 18, 2017 10:21 AM
>> > To: Gregory Etelson 
>> > Cc: tho...@monjalon.net; dev@dpdk.org; Tan, Jianfeng
>> > ; Thotton, Shijith
>>; Hu,
>> > Xuekun ; Yigit, Ferruh ;
>>Patil,
>> > Harish ; Li, Xiaoyun 
>> > Subject: Re: [dpdk-dev] vf init issue with patch igb_uio: issue FLR
>>during open
>> > and release of device file
>> > 
>> > Yes, I have tried, and it works. But I think removing this function
>>also makes the
>> > patch meaningless.
>> > 
>> > Qiming
>> > From: Gregory Etelson [mailto:greg...@weka.io]
>> > Sent: Sunday, September 17, 2017 10:50 AM
>> > To: Yang, Qiming 
>> > Cc: tho...@monjalon.net; dev@dpdk.org; Tan, Jianfeng
>> > ; Thotton, Shijith
>>; Hu,
>> > Xuekun ; Yigit, Ferruh ;
>>Patil,
>> > Harish 
>> > Subject: Re: [dpdk-dev] vf init issue with patch igb_uio: issue FLR
>>during open
>> > and release of device file
>> > 
>> > 
>> > Hello Qiming,
>> > 
>> > 
>> > 
>> > Did you try to remove PCI reset at igbuio_pci_open ?
>> > 
>> > Reverting the patch entirely will get us back to VF issues
>> > 
>> > 
>> > 
>> > Regards,
>> > 
>> > Gregory
>> > 
>> > 
>> > 
>> > 
>> > 
>> > On Friday, 15 September 2017 11:04:16 IDT Yang, Qiming wrote:
>> > 
>> > > Hi, Thomas
>> > 
>> > > We meet a urgent issue because of Shijith's patch.
>> > 
>> > > When use DPDK version 17.08, DPDK VF driver and kernel PF driver,
>>i40e, ixgbe
>> > and qede(Harish said) VF all meet initial failure.
>> > 
>> > > This issue only occurred when use 17.08 igb_uio, vfio-pci and 17.05
>>igb_uio all
>> > works well.
>> > 
>> > > Considering this issue will block our vf driver develop and test
>>work, could we
>> > revert this patch first and find another appropriate way?
>> > 
>> > >
>> > 
>> > > Qiming
>> > 
>> > >
>> > 
>> > > > -Original Message-
>> > 
>> > > > From: Patil, Harish [mailto:harish.pa...@cavium.com]
>> > 
>> > > > Sent: Thursday, September 14, 2017 3:45 AM
>> > 
>> > > > To: Yigit, Ferruh
>>mailto:ferruh.yi...@intel.com>>;
>&g

Re: [dpdk-dev] [PATCH v2 2/2] igb_uio: fix interrupt enablement after FLR in VM

[Patil, Harish]

-Original Message-
From: dev  on behalf of Ferruh Yigit

Date: Friday, October 13, 2017 at 2:11 PM
To: "Thotton, Shijith" , "Wu, Jingjing"
, Harish Patil 
Cc: "Tan, Jianfeng" , "greg...@weka.io"
, "Xing, Beilei" , "dev@dpdk.org"
, "sta...@dpdk.org" 
Subject: Re: [dpdk-dev] [PATCH v2 2/2] igb_uio: fix interrupt
enablement  after FLR in VM

>On 10/13/2017 9:12 AM, Shijith Thotton wrote:
><...>
>
>> Hi Jingjing,
>> 
>> This patch perfectly meets requirements as both resets are retained
>> (open and release). Tested it with LiquidIO NIC and it works fine.
>> I can see MSI-X re-enabled on each run with new patch.
>> 
>> Gregory, Harish,
>> Please verify the patch on your setup if possible.
>
>Hi Gregory, Harish,
>
>Did you able to test this patch?
>
>Thanks,
>Ferruh

[Harish] No, I haven’t.
BTW, the igb_uio change also caused PDA (physical device assignment) mode
failure, where the entire device is PCI passed through to VM). Earlier we
reported only for SR-IOV VF passthru scenario.
Thanks.

>
>> 
>> Thanks,
>> Shijith
>> 
>

Re: [dpdk-dev] [PATCH v2 2/2] igb_uio: fix interrupt enablement after FLR in VM

[Patil, Harish]

From: Gregory Etelson mailto:greg...@weka.io>>
Date: Saturday, October 14, 2017 at 8:10 PM
To: Ferruh Yigit mailto:ferruh.yi...@intel.com>>
Cc: "Thotton, Shijith" 
mailto:shijith.thot...@cavium.com>>, "Wu, Jingjing" 
mailto:jingjing...@intel.com>>, Harish Patil 
mailto:harish.pa...@cavium.com>>, "Tan, Jianfeng" 
mailto:jianfeng@intel.com>>, "Xing, Beilei" 
mailto:beilei.x...@intel.com>>, 
"dev@dpdk.org" mailto:dev@dpdk.org>>, 
"sta...@dpdk.org" 
mailto:sta...@dpdk.org>>
Subject: Re: [PATCH v2 2/2] igb_uio: fix interrupt enablement after FLR in VM

I'll start to build setup environment this week.
Regards,
Gregory

On Sat, Oct 14, 2017 at 12:11 AM, Ferruh Yigit 
mailto:ferruh.yi...@intel.com>> wrote:
On 10/13/2017 9:12 AM, Shijith Thotton wrote:
<...>

> Hi Jingjing,
>
> This patch perfectly meets requirements as both resets are retained
> (open and release). Tested it with LiquidIO NIC and it works fine.
> I can see MSI-X re-enabled on each run with new patch.
>
> Gregory, Harish,
> Please verify the patch on your setup if possible.

Hi Gregory, Harish,

Did you able to test this patch?

Thanks,
ferruh

>
> Thanks,
> Shijith
>


Hi all,
Its not working for qede VF device.
So request to back out all igb_uio changes related to the patch:
igb_uio: issue FLR during open and release of device file

Thanks,
Harish

Re: [dpdk-dev] [PATCH v2 2/2] igb_uio: fix interrupt enablement after FLR in VM

[Patil, Harish]

-Original Message-
From: Ferruh Yigit 
Date: Monday, October 16, 2017 at 4:52 PM
To: Harish Patil , Gregory Etelson

Cc: "Thotton, Shijith" , "Wu, Jingjing"
, "Tan, Jianfeng" , "Xing,
Beilei" , "dev@dpdk.org" ,
"sta...@dpdk.org" 
Subject: Re: [PATCH v2 2/2] igb_uio: fix interrupt enablement after FLR in
VM

>On 10/16/2017 3:49 PM, Patil, Harish wrote:
>> From: Gregory Etelson mailto:greg...@weka.io>>
>> Date: Saturday, October 14, 2017 at 8:10 PM
>> To: Ferruh Yigit ><mailto:ferruh.yi...@intel.com>>
>> Cc: "Thotton, Shijith" > <mailto:shijith.thot...@cavium.com>>, "Wu, Jingjing"
>> mailto:jingjing...@intel.com>>, Harish Patil
>> mailto:harish.pa...@cavium.com>>, "Tan,
>> Jianfeng" mailto:jianfeng@intel.com>>,
>> "Xing, Beilei" mailto:beilei.x...@intel.com>>,
>> "dev@dpdk.org <mailto:dev@dpdk.org>" > <mailto:dev@dpdk.org>>, "sta...@dpdk.org <mailto:sta...@dpdk.org>"
>> mailto:sta...@dpdk.org>>
>> Subject: Re: [PATCH v2 2/2] igb_uio: fix interrupt enablement after FLR
>> in VM
>> 
>> I'll start to build setup environment this week.
>> Regards,
>> Gregory
>> 
>> On Sat, Oct 14, 2017 at 12:11 AM, Ferruh Yigit
>> mailto:ferruh.yi...@intel.com>> wrote:
>> 
>> On 10/13/2017 9:12 AM, Shijith Thotton wrote:
>> <...>
>> 
>> > Hi Jingjing,
>> >
>> > This patch perfectly meets requirements as both resets are
>>retained
>> > (open and release). Tested it with LiquidIO NIC and it works
>>fine.
>> > I can see MSI-X re-enabled on each run with new patch.
>> >
>> > Gregory, Harish,
>> > Please verify the patch on your setup if possible.
>> 
>> Hi Gregory, Harish,
>> 
>> Did you able to test this patch?
>> 
>> Thanks,
>> ferruh
>> 
>> >
>> > Thanks,
>> > Shijith
>> >
>> 
>> 
>> 
>> Hi all,
>> Its not working for qede VF device.
>> So request to back out all igb_uio changes related to the patch:
>> igb_uio: issue FLR during open and release of device file
>
>Hi Harish,
>
>Thanks for testing. We tried.
>
>For this release, agreed to revert back to original state, I will send a
>patch soon.
>
>
>But for further investigation in next release, can you please share more
>details? What is not working exactly, what is your setup, any
>kernel/DPDK log to share?
>
>Thanks,
>Ferruh

Okay, sure.
thanks.
>
>> 
>> Thanks,
>> Harish
>> 
>

Re: [dpdk-dev] [PATCH] igb_uio: revert open and release operations

[Patil, Harish]

-Original Message-
From: Thomas Monjalon 
Date: Tuesday, October 17, 2017 at 1:33 PM
To: Ferruh Yigit , Harish Patil

Cc: "dev@dpdk.org" , Jianfeng Tan ,
Jingjing Wu , "Thotton, Shijith"
, Gregory Etelson , George
Prekas , "sta...@dpdk.org" 
Subject: Re: [PATCH] igb_uio: revert open and release operations

>17/10/2017 22:14, Ferruh Yigit:
>> There were bug reports about terminated application may leave device in
>> undesired state:
>> http://dpdk.org/ml/archives/dev/2016-November/049745.html
>> http://dpdk.org/ml/archives/dev/2016-November/050932.html
>> 
>> And a proposal to fix:
>> http://dpdk.org/ml/archives/dev/2016-December/051844.html
>> 
>> Later another proposal triggered the discussion:
>> http://dpdk.org/ml/archives/dev/2017-May/066317.html
>> 
>> Finally a fix patch pushed into v17.08:
>> Commit: b58eedfc7dd5 ("igb_uio: issue FLR during open and release of
>>device file")
>> 
>> Later a regression report sent related to the pushed patch:
>> http://dpdk.org/ml/archives/dev/2017-September/075236.html
>> 
>> And a fix for regression integrated into v17.11-rc1:
>> http://dpdk.org/ml/archives/dev/2017-October/079166.html
>> Commit: 5f6ff30dc507 ("igb_uio: fix interrupt enablement after FLR in
>>VM")
>> Commit: 6b9ed026a870 ("igb_uio: fix build with kernel <= 3.17")
>> 
>> Even after the fix qede PMD reported to be broken:
>> http://dpdk.org/ml/archives/dev/2017-October/079359.html
>> 
>> So this patch reverts original fix and related commits. The related
>> igb_uio code part turns back to v17.05 base.
>[...]
>> ---
>> It would be nice to solve this issue in LTS release, but being close to
>> the release and the error report without details makes it hard to work
>> more on this issue.
>
>With this revert, we are back to the original issue.
>We must really try the proposed solution.
>Harish, please describe your issue and think how it could be fixed.
>Jingjing made it work for i40e.
>I know it is less effort to request a simple revert.
>Please let's try to fix it once for all.

Hi Ferruh/Thomas,
I’m discussing it internally, so please hold on committing this patch till
I revert back to you.

Thanks.


>

Re: [dpdk-dev] [PATCH] igb_uio: revert open and release operations

[Patil, Harish]

-Original Message-
From: Harish Patil 
Date: Tuesday, October 17, 2017 at 9:50 PM
To: Thomas Monjalon , Ferruh Yigit

Cc: "dev@dpdk.org" , Jianfeng Tan ,
Jingjing Wu , "Thotton, Shijith"
, Gregory Etelson , George
Prekas , "sta...@dpdk.org" 
Subject: Re: [PATCH] igb_uio: revert open and release operations
>
>
>-Original Message-
>From: Thomas Monjalon 
>Date: Tuesday, October 17, 2017 at 1:33 PM
>To: Ferruh Yigit , Harish Patil
>
>Cc: "dev@dpdk.org" , Jianfeng Tan ,
>Jingjing Wu , "Thotton, Shijith"
>, Gregory Etelson , George
>Prekas , "sta...@dpdk.org" 
>Subject: Re: [PATCH] igb_uio: revert open and release operations
>
>>17/10/2017 22:14, Ferruh Yigit:
>>> There were bug reports about terminated application may leave device in
>>> undesired state:
>>> http://dpdk.org/ml/archives/dev/2016-November/049745.html
>>> http://dpdk.org/ml/archives/dev/2016-November/050932.html
>>> 
>>> And a proposal to fix:
>>> http://dpdk.org/ml/archives/dev/2016-December/051844.html
>>> 
>>> Later another proposal triggered the discussion:
>>> http://dpdk.org/ml/archives/dev/2017-May/066317.html
>>> 
>>> Finally a fix patch pushed into v17.08:
>>> Commit: b58eedfc7dd5 ("igb_uio: issue FLR during open and release of
>>>device file")
>>> 
>>> Later a regression report sent related to the pushed patch:
>>> http://dpdk.org/ml/archives/dev/2017-September/075236.html
>>> 
>>> And a fix for regression integrated into v17.11-rc1:
>>> http://dpdk.org/ml/archives/dev/2017-October/079166.html
>>> Commit: 5f6ff30dc507 ("igb_uio: fix interrupt enablement after FLR in
>>>VM")
>>> Commit: 6b9ed026a870 ("igb_uio: fix build with kernel <= 3.17")
>>> 
>>> Even after the fix qede PMD reported to be broken:
>>> http://dpdk.org/ml/archives/dev/2017-October/079359.html
>>> 
>>> So this patch reverts original fix and related commits. The related
>>> igb_uio code part turns back to v17.05 base.
>>[...]
>>> ---
>>> It would be nice to solve this issue in LTS release, but being close to
>>> the release and the error report without details makes it hard to work
>>> more on this issue.
>>
>>With this revert, we are back to the original issue.
>>We must really try the proposed solution.
>>Harish, please describe your issue and think how it could be fixed.
>>Jingjing made it work for i40e.
>>I know it is less effort to request a simple revert.
>>Please let's try to fix it once for all.
>
>Hi Ferruh/Thomas,
>I’m discussing it internally, so please hold on committing this patch till
>I revert back to you.
>
>Thanks.

>[Harish]

> 1) With the introduction of:
>Commit: b58eedfc7dd5 ("igb_uio: issue FLR during open and release of
>device file”)
   We saw failures with qede PF & SR-IOV VF initialization in PCI passthru
mode.

> 
>PF PCI passthru mode initialization failure was resolved by:
>“Commit: 5f6ff30dc507 ("igb_uio: fix interrupt enablement after FLR in
>VM")

>SR-IOV VF PCI passthru mode initialization issue is that PCI FLR and
>related device cleanup is not completed by the time VF driver starts
>loading. It results in the mbox command failure sent over the HW channel
>between VF and PF.
>
>Even though pci_reset_function() waits for the stipulated amount of time
>per standards, VF FLR takes longer than that and pci_reset_function() &
>igb_uio_open() call returns before FLR completes and VF PMD driver tries
>to load before FLR completes leading to VF PMD initialization failure.
> 
>
>We can work around this problem by adding driver delay/retry logic since
>there is no deterministic way of detecting FLR completion. But this is
>going to increase the driver load time.
> 

>2) With the above patch ("igb_uio: issue FLR during open and release of
>device file), FLR is going to be issued unconditionally on all devices
>during igb_uio_open. We think it’s an over kill. FLR is required only for
>previous abnormal app termination. We already handle the abnormal app
>termination by doing necessary cleanup in the driver during load. This
>cleanup is more efficient as it is done only when required. So we feel
>that the drivers/devices needing such cleanup (the two cases listed
>below)  should do it conditionally when required rather than
>igb_uio_open() unconditionally performing FLR all the time.
> 
>e.g.,
   - cdb166963cae ("net/liquidio: add API for VF FLR”)
> 
> 
>- http://dpdk.org/ml/archives/dev/2017-May/066317.html

Thanks,
Harish
>

Re: [dpdk-dev] [PATCH] igb_uio: remove device reset in open

[Patil, Harish]

-Original Message-
From: Ferruh Yigit 
Date: Friday, October 20, 2017 at 9:57 AM
To: Jingjing Wu , "Thotton, Shijith"
, Gregory Etelson , Harish
Patil 
Cc: Thomas Monjalon , "dev@dpdk.org" ,
"sta...@dpdk.org" , Jianfeng Tan
, George Prekas , Sergio
Gonzalez Monroy 
Subject: Re: [PATCH] igb_uio: remove device reset in open

>On 10/20/2017 9:55 AM, Ferruh Yigit wrote:
>> Remove device reset during application start, the reset for application
>> exit still there.
>> 
>> Reset in open removed because of following comments:
>> 1- Device reset not completed when VF driver loaded, which cause VF PMD
>>initialization error.
>>Adding delay can solve the issue but will increase driver load time.
>> 
>> 2- Reset will be issues all devices unconditionally, not very efficient
>>way.
>> 
>> Fixes: b58eedfc7dd5 ("igb_uio: issue FLR during open and release of
>>device file")
>> Cc: sta...@dpdk.org
>> 
>> Signed-off-by: Ferruh Yigit 
>
>Hi Jingjing, Shijith, Gregory, Harish,
>
>Can you please test this on top of current master (which has already
>Jingjin's
>fix) ?
>
>Thanks,
>Ferruh


Ferruh,
Sure, will try and get back to you.
Thanks.
>
>> ---
>> Cc: Jianfeng Tan 
>> Cc: Jingjing Wu 
>> Cc: Shijith Thotton 
>> Cc: Gregory Etelson 
>> Cc: Harish Patil 
>> Cc: George Prekas 
>> Cc: Sergio Gonzalez Monroy 
>> ---
>>  lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 2 --
>>  1 file changed, 2 deletions(-)
>> 
>> diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
>>b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
>> index f7ef82554..fd320d87d 100644
>> --- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
>> +++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
>> @@ -336,8 +336,6 @@ igbuio_pci_open(struct uio_info *info, struct inode
>>*inode)
>>  struct pci_dev *dev = udev->pdev;
>>  int err;
>>  
>> -pci_reset_function(dev);
>> -
>>  /* set bus master, which was cleared by the reset function */
>>  pci_set_master(dev);
>>  
>> 
>

Re: [dpdk-dev] [PATCH] igb_uio: remove device reset in open

[Patil, Harish]

-Original Message-
From: dev  on behalf of Harish Patil

Date: Friday, October 20, 2017 at 3:18 PM
To: Ferruh Yigit , Jingjing Wu
, "Thotton, Shijith" ,
Gregory Etelson 
Cc: Thomas Monjalon , "dev@dpdk.org" ,
"sta...@dpdk.org" , Jianfeng Tan
, George Prekas , Sergio
Gonzalez Monroy 
Subject: Re: [dpdk-dev] [PATCH] igb_uio: remove device reset in open

>[This sender failed our fraud detection checks and may not be who they
>appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>
>-Original Message-
>From: Ferruh Yigit 
>Date: Friday, October 20, 2017 at 9:57 AM
>To: Jingjing Wu , "Thotton, Shijith"
>, Gregory Etelson , Harish
>Patil 
>Cc: Thomas Monjalon , "dev@dpdk.org" ,
>"sta...@dpdk.org" , Jianfeng Tan
>, George Prekas , Sergio
>Gonzalez Monroy 
>Subject: Re: [PATCH] igb_uio: remove device reset in open
>
>>On 10/20/2017 9:55 AM, Ferruh Yigit wrote:
>>> Remove device reset during application start, the reset for application
>>> exit still there.
>>>
>>> Reset in open removed because of following comments:
>>> 1- Device reset not completed when VF driver loaded, which cause VF PMD
>>>initialization error.
>>>Adding delay can solve the issue but will increase driver load time.
>>>
>>> 2- Reset will be issues all devices unconditionally, not very efficient
>>>way.
>>>
>>> Fixes: b58eedfc7dd5 ("igb_uio: issue FLR during open and release of
>>>device file")
>>> Cc: sta...@dpdk.org
>>>
>>> Signed-off-by: Ferruh Yigit 
>>
>>Hi Jingjing, Shijith, Gregory, Harish,
>>
>>Can you please test this on top of current master (which has already
>>Jingjin's
>>fix) ?
>>
>>Thanks,
>>Ferruh
>
>
>Ferruh,
>Sure, will try and get back to you.
>Thanks.

Ferruh and all,
This takes care of our SR-IOV VF issue.
Thanks.

>>
>>> ---
>>> Cc: Jianfeng Tan 
>>> Cc: Jingjing Wu 
>>> Cc: Shijith Thotton 
>>> Cc: Gregory Etelson 
>>> Cc: Harish Patil 
>>> Cc: George Prekas 
>>> Cc: Sergio Gonzalez Monroy 
>>> ---
>>>  lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 2 --
>>>  1 file changed, 2 deletions(-)
>>>
>>> diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
>>>b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
>>> index f7ef82554..fd320d87d 100644
>>> --- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
>>> +++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
>>> @@ -336,8 +336,6 @@ igbuio_pci_open(struct uio_info *info, struct inode
>>>*inode)
>>>  struct pci_dev *dev = udev->pdev;
>>>  int err;
>>>
>>> -pci_reset_function(dev);
>>> -
>>>  /* set bus master, which was cleared by the reset function */
>>>  pci_set_master(dev);
>>>
>>>
>>
>

Re: [dpdk-dev] problem with Qlogic NIC QL45611H

[Patil, Harish]

-Original Message-
From: dev  on behalf of "Wu, Xiaoban"

Date: Tuesday, October 24, 2017 at 5:36 PM
To: "us...@dpdk.org" , "dev@dpdk.org" 
Subject: [dpdk-dev] problem with Qlogic NIC QL45611H

>Dear All,
>
>
>I am trying to run some DPDK applications with the QL45611H NIC, however
>I am facing a problem I don't know how to solve, could somebody please
>help me?
>
>
>I am using ubuntu 14.04 with kernel 3.16 on a Dell server.
>
>I downloaded the driver and firmware from
>http://driverdownloads.qlogic.com/QLogicDriverDownloads_UI/SearchByProduct
>.aspx?ProductCategory=325&Product=1265&Os=5
>
>I firstly installed the driver, and then I rebooted the machine. Then I
>installed the firmware, then I rebooted machine. Then I could see the
>interface eth9 by command ifconfig. And also, the tcpdump can show the
>traffic.
>
>The firmware is updated to qed_init_values_zipped-8.20.2.0.bin
>
>
>Then I downloaded the dpdk-17.05 and modified the config/common_base file
>with 
>CONFIG_RTE_LIBRTE_QEDE_FW="/lib/firmware/qed/qed_init_values_zipped-8.20.2
>.0.bin". I then installed the DPDK by "make -j8 install
>T=x86_64-native-linuxapp-gcc"
>
>
>Then I run "sudo modprobe uio", "sudo insmod igb_uo.ko" and "sudo
>dpdk-devbind.py --bind=igb_uio eth9"
>
>
>Then I stared my dpdk application, it gave me the error message:
>
>EAL: PCI device :82:00.0 on NUMA socket 1
>EAL:   probe driver: 1077:1644 net_qede
>[qed_slowpath_start:289(82:00.0:dpdk-port-0)]ecore_hw_init failed
>[qede_common_dev_init:2245(82:00.0:dpdk-port-0)]Cannot start slowpath rc
>= -3
>EAL: Requested device :82:00.0 cannot be used
>
>Could anybody who has played with QLogic NIC please help me on how to
>correctly start DPDK application step by step? Thanks very much for your
>help.
>
>Best wishes,
>Xiaoban

[Harish] 
1) Have you enabled IOMMU? If so, please try disabling it and try.

2) If (1) does not work then enable the below debug flag:
CONFIG_RTE_LIBRTE_QEDE_DEBUG_INIT=y
CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO=y
and recompile using same make command and send the output.


Thanks.

Re: [dpdk-dev] [PATCH 1/8] net/qede: fix to disable per-VF Tx switching feature

[Patil, Harish]

-Original Message-
From: Thomas Monjalon 
Date: Tuesday, November 7, 2017 at 5:53 PM
To: "Mody, Rasesh" 
Cc: "dev@dpdk.org" , Harish Patil ,
"ferruh.yi...@intel.com" , Dept-Eng DPDK Dev

Subject: Re: [dpdk-dev] [PATCH 1/8] net/qede: fix to disable per-VF Tx
switching feature

>Hi,
>
>07/11/2017 09:34, Rasesh Mody:
>> From: Harish Patil 
>> 
>> Provide a knob to control per-VF Tx switching feature by adding a config
>> option, CONFIG_RTE_LIBRTE_QEDE_VF_TX_SWITCH. By default, it will be kept
>> in disabled state for better performance with small sized frames.
>> 
>> Fixes: 2ea6f76aff40 ("qede: add core driver")
>> Cc: sta...@dpdk.org
>> 
>> Signed-off-by: Harish Patil 
>> ---
>>  config/common_base |1 +
>>  drivers/net/qede/qede_ethdev.c |9 -
>>  2 files changed, 9 insertions(+), 1 deletion(-)
>> 
>> --- a/config/common_base
>> +++ b/config/common_base
>> +CONFIG_RTE_LIBRTE_QEDE_VF_TX_SWITCH=n
>
>We should remove all compile-time options because they cannot be used
>when DPDK is pre-packaged.
>That's why the rule is "NO NEW COMPILE TIME OPTION".
>
>After discussion with Ferruh, this patch is accepted as a hotfix.
>But this option is expected to be removed quickly.
>I've sent a patch to remove this option in 18.02:
>   http://dpdk.org/ml/archives/dev/2017-November/081488.html
>It gives you some time to supersede my patch by introducing a
>run-time driver option.
>
>Thanks

Hi Thomas,
Sure, thanks, we will address before 18.02-rc1.
Do you have any example on how to add a run-time driver option?
Does it mean to introduce some change in ethdev?
Thanks.

>

Re: [dpdk-dev] [PATCH 1/8] net/qede: fix to disable per-VF Tx switching feature

[Patil, Harish]

-Original Message-
From: Thomas Monjalon 
Date: Tuesday, November 7, 2017 at 6:44 PM
To: Harish Patil 
Cc: "ferruh.yi...@intel.com" , "dev@dpdk.org"
, Dept-Eng DPDK Dev , "Mody,
Rasesh" 
Subject: Re: [dpdk-dev] [PATCH 1/8] net/qede: fix to disable per-VF Tx
switching feature

>08/11/2017 02:34, Patil, Harish:
>> >> --- a/config/common_base
>> >> +++ b/config/common_base
>> >> +CONFIG_RTE_LIBRTE_QEDE_VF_TX_SWITCH=n
>> >
>> >We should remove all compile-time options because they cannot be used
>> >when DPDK is pre-packaged.
>> >That's why the rule is "NO NEW COMPILE TIME OPTION".
>> >
>> >After discussion with Ferruh, this patch is accepted as a hotfix.
>> >But this option is expected to be removed quickly.
>> >I've sent a patch to remove this option in 18.02:
>> >http://dpdk.org/ml/archives/dev/2017-November/081488.html
>> >It gives you some time to supersede my patch by introducing a
>> >run-time driver option.
>> >
>> >Thanks
>> 
>> Hi Thomas,
>> Sure, thanks, we will address before 18.02-rc1.
>> Do you have any example on how to add a run-time driver option?
>> Does it mean to introduce some change in ethdev?
>
>It is done by parsing devargs with rte_kvargs.
>Examples:
>   http://dpdk.org/commit/447e0d379
>   http://dpdk.org/commit/001a520e4
>   http://dpdk.org/commit/7958b1310

Thanks Thomas.
>

Re: [dpdk-dev] [PATCH 2/2] net/qede: fix default config option

[Patil, Harish]

-Original Message-
From: Ferruh Yigit 
Date: Thursday, November 9, 2017 at 3:48 PM
To: "Mody, Rasesh" , "dev@dpdk.org"
, "thomas.monja...@6wind.com" 
Cc: Harish Patil , Dept-Eng DPDK Dev

Subject: Re: [dpdk-dev] [PATCH 2/2] net/qede: fix default config option

>On 11/8/2017 10:52 PM, Rasesh Mody wrote:
>> From: Harish Patil 
>> 
>> Restore the default configuration as in previous releases and
>> add a debug msg.
>
>Is this reverting
>"f07aa795c92a ("net/qede: disable per-VF Tx switching feature")"
>
>This will be same as code before f07aa795c92a , right? If so why not just
>remove
>the config option for this release and add a dynamic runtime in next
>release?
>
>I am not clear for both f07aa795c92a and this one fixing, and why should
>they be
>included for rc3?
>
>Thanks,
>Ferruh

Hi Ferruh,
Some customers are interested in getting better performance with 64B sized
packets. For that, they would need to keep this config disabled.
But in all other cases, by default, we would like to keep Tx switching
enabled (at a reduced performance) as in previous releases.
As stated in other email with Thomas, we shall remove this compile-time
config option in next release and use runtime option instead.
But for 17.08 we need it to be enabled by default.
Thanks.

>
>> 
>> Fixes: f07aa795c92a ("net/qede: disable per-VF Tx switching feature")
>> 
>> Signed-off-by: Harish Patil 
>> Signed-off-by: Rasesh Mody 
>> ---
>>  config/common_base |2 +-
>>  drivers/net/qede/qede_ethdev.c |5 +++--
>>  2 files changed, 4 insertions(+), 3 deletions(-)
>> 
>> diff --git a/config/common_base b/config/common_base
>> index 34f04a9..e74febe 100644
>> --- a/config/common_base
>> +++ b/config/common_base
>> @@ -415,7 +415,7 @@ CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO=n
>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER=n
>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX=n
>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_QEDE_VF_TX_SWITCH=n
>> +CONFIG_RTE_LIBRTE_QEDE_VF_TX_SWITCH=y
>>  #Provides abs path/name of the firmware file.
>>  #Empty string denotes driver will use default firmware
>>  CONFIG_RTE_LIBRTE_QEDE_FW=""
>> diff --git a/drivers/net/qede/qede_ethdev.c
>>b/drivers/net/qede/qede_ethdev.c
>> index 8832145..6f5ba2a 100644
>> --- a/drivers/net/qede/qede_ethdev.c
>> +++ b/drivers/net/qede/qede_ethdev.c
>> @@ -457,6 +457,7 @@ int qede_activate_vport(struct rte_eth_dev
>>*eth_dev, bool flg)
>>  if (IS_VF(edev)) {
>>  params.update_tx_switching_flg = 1;
>>  params.tx_switching_flg = !flg;
>> +DP_INFO(edev, "VF tx-switching is disabled\n");
>>  }
>>  #endif
>>  for_each_hwfn(edev, i) {
>> @@ -469,8 +470,8 @@ int qede_activate_vport(struct rte_eth_dev
>>*eth_dev, bool flg)
>>  break;
>>  }
>>  }
>> -DP_INFO(edev, "vport %s VF tx-switch %s\n", flg ? "activated" :
>>"deactivated",
>> -params.tx_switching_flg ? "enabled" : "disabled");
>> +DP_INFO(edev, "vport is %s\n", flg ? "activated" : "deactivated");
>> +
>>  return rc;
>>  }
>>  
>> 
>

Re: [dpdk-dev] [PATCH 2/2] net/qede: fix default config option

[Patil, Harish]

-Original Message-
From: Harish Patil 
Date: Thursday, November 9, 2017 at 3:57 PM
To: Ferruh Yigit , "Mody, Rasesh"
, "dev@dpdk.org" ,
"thomas.monja...@6wind.com" 
Cc: Dept-Eng DPDK Dev 
Subject: Re: [dpdk-dev] [PATCH 2/2] net/qede: fix default config option

>-Original Message-
>From: Ferruh Yigit 
>Date: Thursday, November 9, 2017 at 3:48 PM
>To: "Mody, Rasesh" , "dev@dpdk.org"
>, "thomas.monja...@6wind.com" 
>Cc: Harish Patil , Dept-Eng DPDK Dev
>
>Subject: Re: [dpdk-dev] [PATCH 2/2] net/qede: fix default config option
>
>>On 11/8/2017 10:52 PM, Rasesh Mody wrote:
>>> From: Harish Patil 
>>> 
>>> Restore the default configuration as in previous releases and
>>> add a debug msg.
>>
>>Is this reverting
>>"f07aa795c92a ("net/qede: disable per-VF Tx switching feature")"
>>
>>This will be same as code before f07aa795c92a , right? If so why not just
>>remove
>>the config option for this release and add a dynamic runtime in next
>>release?
>>
>>I am not clear for both f07aa795c92a and this one fixing, and why should
>>they be
>>included for rc3?
>>
>>Thanks,
>>Ferruh
>
>Hi Ferruh,
>Some customers are interested in getting better performance with 64B sized
>packets. For that, they would need to keep this config disabled.
>But in all other cases, by default, we would like to keep Tx switching
>enabled (at a reduced performance) as in previous releases.
>As stated in other email with Thomas, we shall remove this compile-time
>config option in next release and use runtime option instead.
>But for 17.08 we need it to be enabled by default.
>Thanks.

Correction, I meant 17.11 release, not 17.08.
>
>>
>>> 
>>> Fixes: f07aa795c92a ("net/qede: disable per-VF Tx switching feature")
>>> 
>>> Signed-off-by: Harish Patil 
>>> Signed-off-by: Rasesh Mody 
>>> ---
>>>  config/common_base |2 +-
>>>  drivers/net/qede/qede_ethdev.c |5 +++--
>>>  2 files changed, 4 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/config/common_base b/config/common_base
>>> index 34f04a9..e74febe 100644
>>> --- a/config/common_base
>>> +++ b/config/common_base
>>> @@ -415,7 +415,7 @@ CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO=n
>>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER=n
>>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX=n
>>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_RX=n
>>> -CONFIG_RTE_LIBRTE_QEDE_VF_TX_SWITCH=n
>>> +CONFIG_RTE_LIBRTE_QEDE_VF_TX_SWITCH=y
>>>  #Provides abs path/name of the firmware file.
>>>  #Empty string denotes driver will use default firmware
>>>  CONFIG_RTE_LIBRTE_QEDE_FW=""
>>> diff --git a/drivers/net/qede/qede_ethdev.c
>>>b/drivers/net/qede/qede_ethdev.c
>>> index 8832145..6f5ba2a 100644
>>> --- a/drivers/net/qede/qede_ethdev.c
>>> +++ b/drivers/net/qede/qede_ethdev.c
>>> @@ -457,6 +457,7 @@ int qede_activate_vport(struct rte_eth_dev
>>>*eth_dev, bool flg)
>>> if (IS_VF(edev)) {
>>> params.update_tx_switching_flg = 1;
>>> params.tx_switching_flg = !flg;
>>> +   DP_INFO(edev, "VF tx-switching is disabled\n");
>>> }
>>>  #endif
>>> for_each_hwfn(edev, i) {
>>> @@ -469,8 +470,8 @@ int qede_activate_vport(struct rte_eth_dev
>>>*eth_dev, bool flg)
>>> break;
>>> }
>>> }
>>> -   DP_INFO(edev, "vport %s VF tx-switch %s\n", flg ? "activated" :
>>>"deactivated",
>>> -   params.tx_switching_flg ? "enabled" : "disabled");
>>> +   DP_INFO(edev, "vport is %s\n", flg ? "activated" : "deactivated");
>>> +
>>> return rc;
>>>  }
>>>  
>>> 
>>
>

Re: [dpdk-dev] [PATCH 2/2] net/qede: fix default config option

[Patil, Harish]

-Original Message-
From: Ferruh Yigit 
Date: Thursday, November 9, 2017 at 4:07 PM
To: Harish Patil , "Mody, Rasesh"
, "dev@dpdk.org" ,
"thomas.monja...@6wind.com" 
Cc: Dept-Eng DPDK Dev 
Subject: Re: [dpdk-dev] [PATCH 2/2] net/qede: fix default config option

>On 11/9/2017 3:00 PM, Patil, Harish wrote:
>> -Original Message-
>> From: Harish Patil 
>> Date: Thursday, November 9, 2017 at 3:57 PM
>> To: Ferruh Yigit , "Mody, Rasesh"
>> , "dev@dpdk.org" ,
>> "thomas.monja...@6wind.com" 
>> Cc: Dept-Eng DPDK Dev 
>> Subject: Re: [dpdk-dev] [PATCH 2/2] net/qede: fix default config option
>> 
>>> -Original Message-
>>> From: Ferruh Yigit 
>>> Date: Thursday, November 9, 2017 at 3:48 PM
>>> To: "Mody, Rasesh" , "dev@dpdk.org"
>>> , "thomas.monja...@6wind.com" 
>>> Cc: Harish Patil , Dept-Eng DPDK Dev
>>> 
>>> Subject: Re: [dpdk-dev] [PATCH 2/2] net/qede: fix default config option
>>>
>>>> On 11/8/2017 10:52 PM, Rasesh Mody wrote:
>>>>> From: Harish Patil 
>>>>>
>>>>> Restore the default configuration as in previous releases and
>>>>> add a debug msg.
>>>>
>>>> Is this reverting
>>>> "f07aa795c92a ("net/qede: disable per-VF Tx switching feature")"
>>>>
>>>> This will be same as code before f07aa795c92a , right? If so why not
>>>>just
>>>> remove
>>>> the config option for this release and add a dynamic runtime in next
>>>> release?
>>>>
>>>> I am not clear for both f07aa795c92a and this one fixing, and why
>>>>should
>>>> they be
>>>> included for rc3?
>>>>
>>>> Thanks,
>>>> Ferruh
>>>
>>> Hi Ferruh,
>>> Some customers are interested in getting better performance with 64B
>>>sized
>>> packets. For that, they would need to keep this config disabled.
>>> But in all other cases, by default, we would like to keep Tx switching
>>> enabled (at a reduced performance) as in previous releases.
>>> As stated in other email with Thomas, we shall remove this compile-time
>>> config option in next release and use runtime option instead.
>>> But for 17.08 we need it to be enabled by default.
>>> Thanks.
>> 
>> Correction, I meant 17.11 release, not 17.08.
>
>Other patch just sent two days ago, to introduce the config option as
>disabled
>by default, so it was changing the behavior and accepted as a fix for rc3.
>
>Now two days later, this patch enables it as a fix again, only difference
>for
>two days ago becomes adding a config option?
>

Hi Ferruh,
The patch sent two days ago with config option disabled was a mistake.
Yesterday we realized that it is not a desirable thing to keep the config
disabled since many customers would typically need Tx switching to be
enabled.
So the current patch we sent is just to change back the config option set
to enable from disable. Hence its a fix for the previous patch.
Thanks.
>>>
>>>>
>>>>>
>>>>> Fixes: f07aa795c92a ("net/qede: disable per-VF Tx switching feature")
>>>>>
>>>>> Signed-off-by: Harish Patil 
>>>>> Signed-off-by: Rasesh Mody 
>>>>> ---
>>>>>  config/common_base |2 +-
>>>>>  drivers/net/qede/qede_ethdev.c |5 +++--
>>>>>  2 files changed, 4 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/config/common_base b/config/common_base
>>>>> index 34f04a9..e74febe 100644
>>>>> --- a/config/common_base
>>>>> +++ b/config/common_base
>>>>> @@ -415,7 +415,7 @@ CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO=n
>>>>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER=n
>>>>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX=n
>>>>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_RX=n
>>>>> -CONFIG_RTE_LIBRTE_QEDE_VF_TX_SWITCH=n
>>>>> +CONFIG_RTE_LIBRTE_QEDE_VF_TX_SWITCH=y
>>>>>  #Provides abs path/name of the firmware file.
>>>>>  #Empty string denotes driver will use default firmware
>>>>>  CONFIG_RTE_LIBRTE_QEDE_FW=""
>>>>> diff --git a/drivers/net/qede/qede_ethdev.c
>>>>> b/drivers/net/qede/qede_ethdev.c
>>>>> index 8832145..6f5ba2a 100644
>>>>> --- a/drivers/net/qede/qede_ethdev.c
>>>>> +++ b/drivers/net/qede/qede_ethdev.c
>>>>> @@ -457,6 +457,7 @@ int qede_activate_vport(struct rte_eth_dev
>>>>> *eth_dev, bool flg)
>>>>>   if (IS_VF(edev)) {
>>>>>   params.update_tx_switching_flg = 1;
>>>>>   params.tx_switching_flg = !flg;
>>>>> + DP_INFO(edev, "VF tx-switching is disabled\n");
>>>>>   }
>>>>>  #endif
>>>>>   for_each_hwfn(edev, i) {
>>>>> @@ -469,8 +470,8 @@ int qede_activate_vport(struct rte_eth_dev
>>>>> *eth_dev, bool flg)
>>>>>   break;
>>>>>   }
>>>>>   }
>>>>> - DP_INFO(edev, "vport %s VF tx-switch %s\n", flg ? "activated" :
>>>>> "deactivated",
>>>>> - params.tx_switching_flg ? "enabled" : "disabled");
>>>>> + DP_INFO(edev, "vport is %s\n", flg ? "activated" : "deactivated");
>>>>> +
>>>>>   return rc;
>>>>>  }
>>>>>  
>>>>>
>>>>
>>>
>> 
>

Re: [dpdk-dev] 17.08.1 patches review and test

[Patil, Harish]

-Original Message-
From: dev  on behalf of Yuanhan Liu

Date: Monday, November 27, 2017 at 4:21 AM
To: dpdk stable 
Cc: "dev@dpdk.org" , "Xu, Qian Q" 
Subject: [dpdk-dev] 17.08.1 patches review and test

>Hi all,
>
>Here is a list of patches targeted for stable release 17.08.1. Please
>help review and test. The planned date for the final release is 7th,
>Dec. Before that, please shout if anyone has objections with these
>patches being applied.
>
>These patches are located at branch 17.08 of dpdk-stable repo:
>http://dpdk.org/browse/dpdk-stable/
>
>Thanks.
>
>--yliu
>
>---
>Aaron Conole (1):
>  net/enic: fix assignment
>
>Ajit Khaparde (28):
>  net/bnxt: fix HWRM macros and locking
>  net/bnxt: use 64-bits of address for VLAN table
>  net/bnxt: fix an issue with group id calculation
>  net/bnxt: fix calculation of number of pools
>  net/bnxt: handle multi queue mode properly
>  net/bnxt: fix Rx handling and buffer allocation logic
>  net/bnxt: fix an issue with broadcast traffic
>  net/bnxt: fix usage of VMDq flags
>  net/bnxt: set checksum offload flags correctly
>  net/bnxt: update status of Rx IP/L4 CKSUM
>  net/bnxt: fix config RSS update
>  net/bnxt: set the hash key size
>  net/bnxt: fix per queue stats display in xstats
>  net/bnxt: fix interrupt handler
>  net/bnxt: fix number of MAC addresses for VMDq
>  net/bnxt: fix the association of a MACVLAN per VNIC
>  net/bnxt: fix Tx offload capability
>  net/bnxt: fix Rx offload capability
>  net/bnxt: handle Rx multi queue creation properly
>  net/bnxt: remove redundant code parsing pool map
>  net/bnxt: fix a bit shift operation
>  net/bnxt: fix a potential null pointer dereference
>  net/bnxt: fix a potential null pointer dereference
>  net/bnxt: fix a pointer deref before null check
>  net/bnxt: fix an unused value
>  net/bnxt: check VLANs from pool map only for VMDq
>  net/bnxt: do not set hash type unnecessarily
>  net/bnxt: fix VLAN spoof configuration
>
>Akhil Goyal (2):
>  test/crypto: fix dpaa2 sec macros and definitions
>  net/dpaa2: set queues after reconfiguration
>
>Alejandro Lucero (2):
>  net/nfp: fix RSS
>  net/nfp: fix Rx interrupt when multiqueue
>
>Alok Makhariya (2):
>  crypto/dpaa2_sec: remove ICV memset on decryption side
>  crypto/dpaa2_sec: add check for segmented buffer
>
>Anatoly Burakov (1):
>  vfio: fix secondary process initialization
>
>Andrey Chilikin (1):
>  net/i40e: fix flexible payload configuration
>
>Aviad Yehezkel (4):
>  examples/ipsec-secgw: fix crypto device mapping
>  examples/ipsec-secgw: fix session creation
>  examples/ipsec-secgw: fix AAD length setting
>  app/testpmd: fix build without ixgbe and bnxt PMDs
>
>Beilei Xing (1):
>  net/i40e: fix VF device stop issue
>
>Chas Williams (1):
>  net/vmxnet3: fix memory leak when releasing queues
>
>Congwen Zhang (1):
>  net/cxgbe: fix memory leak
>
>Daniel Mrzyglod (3):
>  net/virtio: fix untrusted scalar value
>  app/testpmd: fix DDP package filesize detection
>  net/bonding: fix default aggregator mode to stable
>
>David Harton (2):
>  net/vmxnet3: fix MAC address set
>  net/i40e: fix i40evf MAC filter table
>
>Ferruh Yigit (4):
>  ethdev: fix ABI version
>  ethdev: revert use port name from device structure
>  igb_uio: remove device reset in open
>  net/qede: fix icc build
>
>Gaetan Rivet (1):
>  net/failsafe: fix errno set on command execution
>
>Gowrishankar Muthukrishnan (1):
>  net/bonding: support bifurcated driver in eal
>
>Guduri Prathyusha (2):
>  examples/l3fwd: fix NEON instructions
>  examples/l3fwd: fix aliasing in port grouping
>
>Harish Patil (2):
>  net/qede: fix supported packet types
>  net/qede: fix to re-enable LRO during device start
>
>Hemant Agrawal (3):
>  net/dpaa2: fix the Tx handling of non HW pool bufs
>  examples/l2fwd-crypto: fix uninitialized errno value
>  app/crypto-perf: fix uninitialized errno value
>
>Ian Stokes (1):
>  cryptodev: fix build with -Ofast
>
>Ivan Malov (2):
>  net/sfc: specify correct scale table size on Rx start
>  net/sfc: fix unused variable in RSS-agnostic build
>
>Jacek Piasecki (1):
>  examples/vhost_scsi: fix product id string termination
>
>Jasvinder Singh (1):
>  examples/qos_sched: fix uninitialized config
>
>Jerin Jacob (1):
>  timer: use 64-bit specific code on more platforms
>
>Jianbo Liu (1):
>  net/i40e: fix Rx packets number for NEON
>
>Jiayu Hu (1):
>  gro: fix typo in map file
>
>Jingjing Wu (4):
>  net/i40e: fix interrupt throttling setting in PF
>  net/i40e: fix memory leak if VF init fails
>  net/i40e: fix variable assignment
>  net/i40e: fix VF initialization error
>
>John Daley (3):
>  net/enic: fix multi-process operation
>  net/enic: fix packet loss after MTU change
> 

Re: [dpdk-dev] 17.08.1 patches review and test

[Patil, Harish]

-Original Message-
From: Yuanhan Liu 
Date: Thursday, November 30, 2017 at 10:28 PM
To: Harish Patil 
Cc: dpdk stable , "dev@dpdk.org" , "Xu,
Qian Q" , Dept-Eng DPDK Dev

Subject: Re: [dpdk-dev] 17.08.1 patches review and test

>On Thu, Nov 30, 2017 at 07:09:28PM +, Patil, Harish wrote:
>> Hi Yuanhan,
>> Thanks for the queuing the patches for stable release.
>> Could you please provide ETA?
>
>Is below what you are looking for?
>
>   --yliu
>
>---
>Hi all,
>
>Here is a list of patches targeted for stable release 17.08.1. Please
>==> help review and test. The planned date for the final release is 7th,
>==> Dec. Before that, please shout if anyone has objections with these
>patches being applied.

OK thanks, we will review ASAP and get back to you.

>

Re: [dpdk-dev] 17.08.1 patches review and test

[Patil, Harish]

-Original Message-
From: dev  on behalf of Yuanhan Liu

Date: Monday, November 27, 2017 at 4:21 AM
To: dpdk stable 
Cc: "dev@dpdk.org" , "Xu, Qian Q" 
Subject: [dpdk-dev] 17.08.1 patches review and test

>Hi all,
>
>Here is a list of patches targeted for stable release 17.08.1. Please
>help review and test. The planned date for the final release is 7th,
>Dec. Before that, please shout if anyone has objections with these
>patches being applied.
>
>These patches are located at branch 17.08 of dpdk-stable repo:
>http://dpdk.org/browse/dpdk-stable/
>
>Thanks.
>
>--yliu
>
>---
>Aaron Conole (1):
>  net/enic: fix assignment
>
>Ajit Khaparde (28):
>  net/bnxt: fix HWRM macros and locking
>  net/bnxt: use 64-bits of address for VLAN table
>  net/bnxt: fix an issue with group id calculation
>  net/bnxt: fix calculation of number of pools
>  net/bnxt: handle multi queue mode properly
>  net/bnxt: fix Rx handling and buffer allocation logic
>  net/bnxt: fix an issue with broadcast traffic
>  net/bnxt: fix usage of VMDq flags
>  net/bnxt: set checksum offload flags correctly
>  net/bnxt: update status of Rx IP/L4 CKSUM
>  net/bnxt: fix config RSS update
>  net/bnxt: set the hash key size
>  net/bnxt: fix per queue stats display in xstats
>  net/bnxt: fix interrupt handler
>  net/bnxt: fix number of MAC addresses for VMDq
>  net/bnxt: fix the association of a MACVLAN per VNIC
>  net/bnxt: fix Tx offload capability
>  net/bnxt: fix Rx offload capability
>  net/bnxt: handle Rx multi queue creation properly
>  net/bnxt: remove redundant code parsing pool map
>  net/bnxt: fix a bit shift operation
>  net/bnxt: fix a potential null pointer dereference
>  net/bnxt: fix a potential null pointer dereference
>  net/bnxt: fix a pointer deref before null check
>  net/bnxt: fix an unused value
>  net/bnxt: check VLANs from pool map only for VMDq
>  net/bnxt: do not set hash type unnecessarily
>  net/bnxt: fix VLAN spoof configuration
>
>Akhil Goyal (2):
>  test/crypto: fix dpaa2 sec macros and definitions
>  net/dpaa2: set queues after reconfiguration
>
>Alejandro Lucero (2):
>  net/nfp: fix RSS
>  net/nfp: fix Rx interrupt when multiqueue
>
>Alok Makhariya (2):
>  crypto/dpaa2_sec: remove ICV memset on decryption side
>  crypto/dpaa2_sec: add check for segmented buffer
>
>Anatoly Burakov (1):
>  vfio: fix secondary process initialization
>
>Andrey Chilikin (1):
>  net/i40e: fix flexible payload configuration
>
>Aviad Yehezkel (4):
>  examples/ipsec-secgw: fix crypto device mapping
>  examples/ipsec-secgw: fix session creation
>  examples/ipsec-secgw: fix AAD length setting
>  app/testpmd: fix build without ixgbe and bnxt PMDs
>
>Beilei Xing (1):
>  net/i40e: fix VF device stop issue
>
>Chas Williams (1):
>  net/vmxnet3: fix memory leak when releasing queues
>
>Congwen Zhang (1):
>  net/cxgbe: fix memory leak
>
>Daniel Mrzyglod (3):
>  net/virtio: fix untrusted scalar value
>  app/testpmd: fix DDP package filesize detection
>  net/bonding: fix default aggregator mode to stable
>
>David Harton (2):
>  net/vmxnet3: fix MAC address set
>  net/i40e: fix i40evf MAC filter table
>
>Ferruh Yigit (4):
>  ethdev: fix ABI version
>  ethdev: revert use port name from device structure
>  igb_uio: remove device reset in open
>  net/qede: fix icc build
>
>Gaetan Rivet (1):
>  net/failsafe: fix errno set on command execution
>
>Gowrishankar Muthukrishnan (1):
>  net/bonding: support bifurcated driver in eal
>
>Guduri Prathyusha (2):
>  examples/l3fwd: fix NEON instructions
>  examples/l3fwd: fix aliasing in port grouping
>
>Harish Patil (2):
>  net/qede: fix supported packet types
>  net/qede: fix to re-enable LRO during device start
>
>Hemant Agrawal (3):
>  net/dpaa2: fix the Tx handling of non HW pool bufs
>  examples/l2fwd-crypto: fix uninitialized errno value
>  app/crypto-perf: fix uninitialized errno value
>
>Ian Stokes (1):
>  cryptodev: fix build with -Ofast
>
>Ivan Malov (2):
>  net/sfc: specify correct scale table size on Rx start
>  net/sfc: fix unused variable in RSS-agnostic build
>
>Jacek Piasecki (1):
>  examples/vhost_scsi: fix product id string termination
>
>Jasvinder Singh (1):
>  examples/qos_sched: fix uninitialized config
>
>Jerin Jacob (1):
>  timer: use 64-bit specific code on more platforms
>
>Jianbo Liu (1):
>  net/i40e: fix Rx packets number for NEON
>
>Jiayu Hu (1):
>  gro: fix typo in map file
>
>Jingjing Wu (4):
>  net/i40e: fix interrupt throttling setting in PF
>  net/i40e: fix memory leak if VF init fails
>  net/i40e: fix variable assignment
>  net/i40e: fix VF initialization error
>
>John Daley (3):
>  net/enic: fix multi-process operation
>  net/enic: fix packet loss after MTU change
> 

Re: [dpdk-dev] [PATCH 2/5] examples/kni: add optional parameter to enable LRO

[Patil, Harish]

-Original Message-
From: Ferruh Yigit 
Date: Monday, December 4, 2017 at 3:25 PM
To: "Mody, Rasesh" , "dev@dpdk.org" 
Cc: Harish Patil , Dept-Eng DPDK Dev

Subject: Re: [dpdk-dev] [PATCH 2/5] examples/kni: add optional parameter
to enable LRO

>On 11/24/2017 12:35 PM, Rasesh Mody wrote:
>> From: Harish Patil 
>> 
>> Add an optional cmdline parameter to enable LRO. This is useful to test
>> LRO feature by being able to run linux utils like iperf over KNI
>>interface
>> which generates consistent packet aggregations.
>> 
>> Signed-off-by: Harish Patil 
>
>Acked-by: Ferruh Yigit 
>
>I think this patch has no dependency for rest of the patchset and can be
>separately applied.

That’s right, thanks.
>

Re: [dpdk-dev] [PATCH 2/5] examples/kni: add optional parameter to enable LRO

[Patil, Harish]

-Original Message-
From: Shahaf Shuler 
Date: Monday, December 4, 2017 at 10:05 PM
To: Ferruh Yigit , "Mody, Rasesh"
, "dev@dpdk.org" 
Cc: Harish Patil , Dept-Eng DPDK Dev

Subject: RE: [dpdk-dev] [PATCH 2/5] examples/kni: add optional parameter
to enable LRO

>Tuesday, December 5, 2017 1:25 AM, Ferruh Yigit:
>> On 11/24/2017 12:35 PM, Rasesh Mody wrote:
>> > From: Harish Patil 
>> >
>> > Add an optional cmdline parameter to enable LRO. This is useful to
>> > test LRO feature by being able to run linux utils like iperf over KNI
>> > interface which generates consistent packet aggregations.
>> >
>> > Signed-off-by: Harish Patil 
>> 
>> Acked-by: Ferruh Yigit 
>> 
>> I think this patch has no dependency for rest of the patchset and can be
>> separately applied.
>
>Snipped from the patch [1]
>
>Please use the new ethdev offloads API. there is already a series to
>convert the examples including kni[2], I think it is better to work on
>top of it. 
>
>[1]
>@@ -611,6 +618,10 @@ struct kni_interface_stats {
>   /* Initialise device and RX/TX queues */
>   RTE_LOG(INFO, APP, "Initialising port %u ...\n", (unsigned)port);
>   fflush(stdout);
>+
>+  if (enable_lro)
>+  port_conf.rxmode.enable_lro = 1;
>+
>
>[2] http://dpdk.org/dev/patchwork/patch/31558/
>
Okay, I will take a look at it.

Thanks,
Harish


>

Re: [dpdk-dev] [PATCH] net/qede: fix alloc from socket 0

[Patil, Harish]

-Original Message-
From: Pascal Mazon 
Date: Friday, February 23, 2018 at 4:53 AM
To: "dev@dpdk.org" , "Mody, Rasesh"
, Harish Patil , "Shaikh,
Shahed" 
Cc: "pascal.ma...@6wind.com" , "sta...@dpdk.org"

Subject: [PATCH] net/qede: fix alloc from socket 0

>In case osal_dma_alloc_coherent() is called from a management thread,
>core_id turn out to be LCORE_ID_ANY, and the resulting socket for alloc
>will be socket 0.
>
>This is not desirable when using a NIC from socket 1 which might very
>likely be configured to use memory from that socket only.
>In that case, allocation will fail.
>
>To address this, use master lcore instead when called from mgmt thread.
>The associated socket should have memory available.
>
>Fixes: ec94dbc57362 ("qede: add base driver")
>Cc: sta...@dpdk.org
>
>Signed-off-by: Pascal Mazon 
>---
> drivers/net/qede/base/bcm_osal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/qede/base/bcm_osal.c
>b/drivers/net/qede/base/bcm_osal.c
>index fe42f3256400..0760cdcb9523 100644
>--- a/drivers/net/qede/base/bcm_osal.c
>+++ b/drivers/net/qede/base/bcm_osal.c
>@@ -133,7 +133,7 @@ void *osal_dma_alloc_coherent(struct ecore_dev *p_dev,
>   snprintf(mz_name, sizeof(mz_name) - 1, "%lx",
>   (unsigned long)rte_get_timer_cycles());
>   if (core_id == (unsigned int)LCORE_ID_ANY)
>-  core_id = 0;
>+  core_id = rte_get_master_lcore();
>   socket_id = rte_lcore_to_socket_id(core_id);
>   mz = rte_memzone_reserve_aligned(mz_name, size,
>socket_id, 0, RTE_CACHE_LINE_SIZE);
>-- 
>2.16.1.72.g5be1f00a9
>
Hi Pascal,
Looks good.
Can you please similar change in osal_dma_alloc_coherent_aligned() also?
Thanks.

Acked-by: Harish Patil 


>

Re: [dpdk-dev] [PATCH v2] net/qede: fix alloc from socket 0

[Patil, Harish]

-Original Message-
From: Pascal Mazon 
Date: Monday, February 26, 2018 at 12:01 AM
To: "dev@dpdk.org" , "Mody, Rasesh"
, Harish Patil , "Shaikh,
Shahed" 
Cc: "pascal.ma...@6wind.com" , "sta...@dpdk.org"

Subject: [PATCH v2] net/qede: fix alloc from socket 0

>In case osal_dma_alloc_coherent() or osal_dma_alloc_coherent_aligned() are
>called from a management thread, core_id turn out to be LCORE_ID_ANY, and
>the resulting socket for alloc will be socket 0.
>
>This is not desirable when using a NIC from socket 1 which might very
>likely be configured to use memory from that socket only.
>In that case, allocation will fail.
>
>To address this, use master lcore instead when called from mgmt thread.
>The associated socket should have memory available.
>
>Fixes: ec94dbc57362 ("qede: add base driver")
>Cc: sta...@dpdk.org
>
>Signed-off-by: Pascal Mazon 
>Acked-by: Harish Patil 
>---
>
>v2:
>  - Add similar change in osal_dma_alloc_coherent_aligned()
>
> drivers/net/qede/base/bcm_osal.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/qede/base/bcm_osal.c
>b/drivers/net/qede/base/bcm_osal.c
>index fe42f3256400..91017b89aa26 100644
>--- a/drivers/net/qede/base/bcm_osal.c
>+++ b/drivers/net/qede/base/bcm_osal.c
>@@ -133,7 +133,7 @@ void *osal_dma_alloc_coherent(struct ecore_dev *p_dev,
>   snprintf(mz_name, sizeof(mz_name) - 1, "%lx",
>   (unsigned long)rte_get_timer_cycles());
>   if (core_id == (unsigned int)LCORE_ID_ANY)
>-  core_id = 0;
>+  core_id = rte_get_master_lcore();
>   socket_id = rte_lcore_to_socket_id(core_id);
>   mz = rte_memzone_reserve_aligned(mz_name, size,
>socket_id, 0, RTE_CACHE_LINE_SIZE);
>@@ -172,7 +172,7 @@ void *osal_dma_alloc_coherent_aligned(struct
>ecore_dev *p_dev,
>   snprintf(mz_name, sizeof(mz_name) - 1, "%lx",
>   (unsigned long)rte_get_timer_cycles());
>   if (core_id == (unsigned int)LCORE_ID_ANY)
>-  core_id = 0;
>+  core_id = rte_get_master_lcore();
>   socket_id = rte_lcore_to_socket_id(core_id);
>   mz = rte_memzone_reserve_aligned(mz_name, size, socket_id, 0, align);
>   if (!mz) {
>-- 
>2.16.1.72.g5be1f00a9
>
Acked-by: Harish Patil 

>

Re: [dpdk-dev] [PATCH v2 39/41] net/qede: use contiguous allocation for DMA memory

[Patil, Harish]

-Original Message-
From: Anatoly Burakov 
Date: Wednesday, March 7, 2018 at 8:57 AM
To: "dev@dpdk.org" 
Cc: "Mody, Rasesh" , Harish Patil
, "Shaikh, Shahed" ,
"keith.wi...@intel.com" , "jianfeng@intel.com"
, "andras.kov...@ericsson.com"
, "laszlo.vadk...@ericsson.com"
, "benjamin.wal...@intel.com"
, "bruce.richard...@intel.com"
, "tho...@monjalon.net" ,
"konstantin.anan...@intel.com" ,
"kuralamudhan.ramakrish...@intel.com"
, "louise.m.d...@intel.com"
, "nelio.laranje...@6wind.com"
, "ys...@mellanox.com" ,
"peppe...@japf.ch" , "Jacob,  Jerin"
, "hemant.agra...@nxp.com"
, "olivier.m...@6wind.com" 
Subject: [PATCH v2 39/41] net/qede: use contiguous allocation for DMA
memory

>Signed-off-by: Anatoly Burakov 
>---
>
>Notes:
>Doing "grep -R rte_memzone_reserve drivers/net/qede" returns the
>following:
>
>drivers/net/qede/qede_fdir.c: mz =
>rte_memzone_reserve_aligned(mz_name, QEDE_MAX_FDIR_PKT_LEN,
>drivers/net/qede/base/bcm_osal.c: mz =
>rte_memzone_reserve_aligned_contig(mz_name, size,
>drivers/net/qede/base/bcm_osal.c: mz =
>rte_memzone_reserve_aligned_contig(mz_name, size, socket_id, 0,
>
>I took a brief look at memzone in qede_fdir and it didn't look like
>memzone
>was used for DMA, so i left it alone. Corrections welcome.

That’s right.
>
> drivers/net/qede/base/bcm_osal.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/qede/base/bcm_osal.c
>b/drivers/net/qede/base/bcm_osal.c
>index fe42f32..707d553 100644
>--- a/drivers/net/qede/base/bcm_osal.c
>+++ b/drivers/net/qede/base/bcm_osal.c
>@@ -135,7 +135,7 @@ void *osal_dma_alloc_coherent(struct ecore_dev *p_dev,
>   if (core_id == (unsigned int)LCORE_ID_ANY)
>   core_id = 0;
>   socket_id = rte_lcore_to_socket_id(core_id);
>-  mz = rte_memzone_reserve_aligned(mz_name, size,
>+  mz = rte_memzone_reserve_aligned_contig(mz_name, size,
>socket_id, 0, RTE_CACHE_LINE_SIZE);
>   if (!mz) {
>   DP_ERR(p_dev, "Unable to allocate DMA memory "
>@@ -174,7 +174,8 @@ void *osal_dma_alloc_coherent_aligned(struct
>ecore_dev *p_dev,
>   if (core_id == (unsigned int)LCORE_ID_ANY)
>   core_id = 0;
>   socket_id = rte_lcore_to_socket_id(core_id);
>-  mz = rte_memzone_reserve_aligned(mz_name, size, socket_id, 0, align);
>+  mz = rte_memzone_reserve_aligned_contig(mz_name, size, socket_id, 0,
>+  align);
>   if (!mz) {
>   DP_ERR(p_dev, "Unable to allocate DMA memory "
>  "of size %zu bytes - %s\n",
>-- 
>2.7.4

Acked-by: Harish Patil 

>