[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Yuanhan Liu]

On Fri, Sep 09, 2016 at 03:33:32PM +, Dey, Souvik wrote:
> Hi Mark,
> 
> Yes I thought I did that change. Sorry once again.. making too many mistakes. 
> Changed it . Thanks. 
> The MTU here is L3 MTU.  Setting this will help in reducing the 
> fragmented/multi-segmented packets and also in case we want to reduce the MTU 
> below 1500, to support VXLAN or GRE tunnel for the packets in openstack and 
> cloud environments.  
> 
> ---
>  drivers/net/virtio/virtio_ethdev.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/net/virtio/virtio_ethdev.c 
> b/drivers/net/virtio/virtio_ethdev.c
> index 07d6449..da16ad4 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> 
> static int virtio_dev_queue_stats_mapping_set(
>   __rte_unused struct rte_eth_dev *eth_dev,
> @@ -652,6 +653,16 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
>   PMD_INIT_LOG(ERR, "Failed to disable allmulticast");
>  }
>  
> +static int
> +virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
> +{
> + struct virtio_hw *hw = dev->data->dev_private;
> + if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
> + PMD_INIT_LOG(ERR, "Mtu should be between VIRTIO_MIN_RX_BUFSIZE 
> and VIRTIO_MAX_RX_PKTLEN \n");

Unfortunately, that is still broken, in two ways:

- we should avoid long lines over 80 chars

- the range will not be correctly showed in the message, because ... (well,
  you know it).

--yliu

[dpdk-dev] [PATCH v2] kni: fix build with kernel 4.8

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Thursday, September 08, 2016 11:32 AM
> To: dev at dpdk.org
> Cc: Stephen Hemminger
> Subject: [dpdk-dev] [PATCH v2] kni: fix build with kernel 4.8
> 
> Linux kernel v4.8 removes macro DEFINE_PCI_DEVICE_TABLE
> 
> Linux: 7e9321599011 ("treewide: remove references to the now unnecessary
> DEFINE_PCI_DEVICE_TABLE")
> 
> Replaced macro with its value in kni ethtool drivers.
> 
> Signed-off-by: Ferruh Yigit 

Acked-by: Pablo de Lara 

[dpdk-dev] FM10420 (RRC) - Problems with PMD matching on virtual functions in ACL table

[Gal Sagie]

Hello All.

I have an FM10420 card with dual 100G ports, I am running a DPDK
application that binds
two virtual function ports to it.
I tried to set rules to the IES to match on the ports logical id (for the
VF's), the rules are configured well but are not working (not matching).

If i dont use DPDK this works fine.

Anyone has any idea of the problem with the PMD in this regards and how to
solve it?

Thanks
Gal.

[dpdk-dev] [PATCH v2 1/3] lib/librte_port: enable file descriptor port support

[Dumitrescu, Cristian]

> -Original Message-
> From: Richardson, Bruce
> Sent: Monday, September 5, 2016 11:12 AM
> To: Singh, Jasvinder 
> Cc: dev at dpdk.org; Dumitrescu, Cristian 
> Subject: Re: [dpdk-dev] [PATCH v2 1/3] lib/librte_port: enable file descriptor
> port support
> 
> On Sun, Sep 04, 2016 at 03:38:39PM +0100, Jasvinder Singh wrote:
> > This patch adds File Descriptor(FD) port type (e.g. TAP port) to the
> > packet framework library that allows interface with the kernel network
> > stack. The FD port APIs are defined that allow port creation, writing
> > and reading packet from the kernel interface.
> >
> > Signed-off-by: Jasvinder Singh 
> > Acked-by: Cristian Dumitrescu 
> > ---
> > v2:
> > - fix checkpatch warnings
> 
> Rather than adding a special TAP port for use by packet framework alone,
> why not
> create a TAP PMD/ethdev and then it can be used both by regular DPDK
> apps, as well
> as by packet framework too - since packet framework already has an ethdev
> port
> type that presumably works with all ethdevs?
> 
> /Bruce

Great idea, but we don't have the bandwidth to create a TAP PMD right now. Any 
volunteers?

Please also note that the non-blocking file descriptor is actually 
significantly more generic/has broader applicability than just the TAP device, 
as it can be used to interface with any file descriptor, not just a TAP file 
descriptor, e.g. any Linux kernel character device or sockets (probably a small 
number of sockets), etc. I am sure it will prove itself useful to more people 
and we'll probably find even more places to use it going forward. 
Unfortunately, AFAIK this cannot be fitted as a PMD right now due to EAL 
limitations, as this would be virtual device and the file descriptor ID would 
have to be known before the DPDK application is started and passed to the app 
through the EAL vdev parameter, right?

This being said, I propose we go ahead with this new type of port. Whenever a 
TAP PMD becomes available, I don't mind changing the IP pipeline app to use it 
if people would prefer it. Our primary motivation for adding TAP support to IP 
pipeline app was to serve as a base of performance comparison between TAP and 
KNI when the same setup is used, but I am sure there are other potential usages 
for it.

[dpdk-dev] meter: excess token bucket update in srtcm

[Dumitrescu, Cristian]

Thanks, Nikhil, will review and get back to you in the next couple of weeks. 
Regards, Cristian

From: Nikhil Jagtap [mailto:nikhil.jag...@gmail.com]
Sent: Wednesday, September 7, 2016 7:22 AM
To: Dumitrescu, Cristian 
Cc: Ramia, Kannan Babu ; dev at dpdk.org
Subject: Re: [dpdk-dev] meter: excess token bucket update in srtcm

Hi Cristian,

Thanks for the confirmation. I have submitted a patch for the same.
http://dpdk.org/ml/archives/dev/2016-September/046226.html

Regards,
Nikhil

On 6 September 2016 at 15:26, Dumitrescu, Cristian mailto:cristian.dumitrescu at intel.com>> wrote:
Hi Nikhil,

It also looks to me that you are right. Sorry, my mistake when translating the 
RFC into code.

Challenge in fixing this is how to code it using minimal number of branches ...

Thanks,
Cristian

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On 
> Behalf Of Nikhil Jagtap
> Sent: Tuesday, September 6, 2016 7:30 AM
> To: Ramia, Kannan Babu  intel.com>
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] meter: excess token bucket update in srtcm
>
> Hi Kannan,
>
> Thank you for your reply. I will submit the patch on similar lines I had
> used for my test.
>
> Regards,
> Nikhil
>
> On 6 September 2016 at 10:40, Ramia, Kannan Babu <
> kannan.babu.ramia at intel.com> wrote:
>
> > Hi Nikhil
> >
> > You could submit a patch, something like that below logic
> >
> > If( ((n_periods * m->cir_bytes_per_period) > (m->cbs-m->tc))
> > te = m->te + ((n_periods * m->cir_bytes_per_period) -
> > (m->cbs-m->tc));
> >
> > and this should be done before m->tc update.
> >
> >
> > Regards
> > Kannan Babu
> >
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] 
> > On Behalf Of Nikhil Jagtap
> > Sent: Tuesday, September 6, 2016 9:43 AM
> > To: Dumitrescu, Cristian  > intel.com>
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] meter: excess token bucket update in srtcm
> >
> > Hi,
> > Can someone please comment on this?
> >
> > Nikhil
> >
> > On 31 August 2016 at 15:32, Nikhil Jagtap  > gmail.com> wrote:
> >
> > > Hi,
> > >
> > > As per srTCM RFC 2697, we should be updating the E bucket only after
> > > the C bucket overflows.
> > > "Thereafter, the token counts Tc and Te are updated CIR times per
> > > second as follows:
> > >  o If Tc is less than CBS, Tc is incremented by one, else
> > >  o if Te is less then EBS, Te is incremented by one, else
> > >  o neither Tc nor Te is incremented."
> > >
> > > However in the current DPDK implementation of srTCM, we are updating
> > > both the buckets simultaneously at the same rate (CIR). This will
> > > result in a token accumulation rate of (2*CIR). This seems like a bug
> > > to me. Can you confirm this?
> > >
> > > Nikhil
> > >
> > >
> >

[dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management

[Jerin Jacob]

On Fri, Aug 26, 2016 at 10:10:18AM +0100, Bernard Iremonger wrote:
> Add new API functions to configure and manage VF's on a NIC.
> 
> add rte_eth_dev_vf_ping function.
> add rte_eth_dev_set_vf_vlan_anti_spoof function.
> add rte_eth_dev_set_vf_mac_anti_spoof function.
> 
> Signed-off-by: azelezniak 
> 
> add rte_eth_dev_set_vf_vlan_strip function.
> add rte_eth_dev_set_vf_vlan_insert function.
> add rte_eth_dev_set_loopback function.
> add rte_eth_dev_set_all_queues_drop function.
> add rte_eth_dev_set_vf_split_drop_en function
> add rte_eth_dev_set_vf_mac_addr function.

Do we really need to expose VF specific functions here?
It can be generic(PF/VF) function indexed only through port_id.
(example: as rte_eth_dev_set_vlan_anti_spoof(uint8_t port_id, uint8_t on))
For instance, In Thunderx PMD, We are not exposing a separate port_id
for PF. We only enumerate 0..N VFs as 0..N ethdev port_id

> increment LIBABIVER to 5.
> 
> Signed-off-by: Bernard Iremonger 
> ---
>  lib/librte_ether/rte_ethdev.c  | 159 +++
>  lib/librte_ether/rte_ethdev.h  | 223 
> +
>  lib/librte_ether/rte_ether_version.map |   9 ++
>  3 files changed, 391 insertions(+)
> 
> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> index 1388ea3..2a3d2ae 100644
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c
> @@ -2306,6 +2306,22 @@ rte_eth_dev_default_mac_addr_set(uint8_t port_id, 
> struct ether_addr *addr)
>  }
>  
>  int
> +rte_eth_dev_set_vf_mac_addr(uint8_t port_id, uint16_t vf, struct ether_addr 
> *addr)
> +{
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> +
> + if (!is_valid_assigned_ether_addr(addr))
> + return -EINVAL;
> +
> + dev = &rte_eth_devices[port_id];
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_vf_mac_addr, -ENOTSUP);
> +
> + return (*dev->dev_ops->set_vf_mac_addr)(dev, vf, addr);
> +}
> +
> +int
>  rte_eth_dev_set_vf_rxmode(uint8_t port_id,  uint16_t vf,
>   uint16_t rx_mode, uint8_t on)
>  {
> @@ -2490,6 +2506,149 @@ rte_eth_dev_set_vf_vlan_filter(uint8_t port_id, 
> uint16_t vlan_id,
>  vf_mask, vlan_on);
>  }
>  
> +int
> +rte_eth_dev_set_vf_vlan_anti_spoof(uint8_t port_id,
> +uint16_t vf, uint8_t on)
> +{
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> +
> + dev = &rte_eth_devices[port_id];
> + if (vf > 63) {

PMD may have more than 64 VFs.


> + RTE_PMD_DEBUG_TRACE("VF VLAN anti spoof:VF %d > 63\n", vf);
> + return -EINVAL;
> + }
> +
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_vf_vlan_anti_spoof, 
> -ENOTSUP);
> + (*dev->dev_ops->set_vf_vlan_anti_spoof)(dev, vf, on);
> + return 0;
> +}
> +

[dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal callback functions

[Jerin Jacob]

On Fri, Aug 26, 2016 at 10:10:16AM +0100, Bernard Iremonger wrote:
> add _rte_eth_dev_callback_process_vf function.
> add _rte_eth_dev_callback_process_generic function
> 
> Adding a callback to the user application on VF to PF mailbox message,
> allows passing information to the application controlling the PF
> when a VF mailbox event message is received, such as VF reset.
> 
> Signed-off-by: azelezniak 
> Signed-off-by: Bernard Iremonger 
> ---
>  lib/librte_ether/rte_ethdev.c  | 17 ++
>  lib/librte_ether/rte_ethdev.h  | 61 
> ++
>  lib/librte_ether/rte_ether_version.map |  7 
>  3 files changed, 85 insertions(+)
> 
> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> index f62a9ec..1388ea3 100644
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c
> @@ -2690,6 +2690,20 @@ void
>  _rte_eth_dev_callback_process(struct rte_eth_dev *dev,
>   enum rte_eth_event_type event)
>  {
> + return _rte_eth_dev_callback_process_generic(dev, event, NULL);
> +}
> +
> +void
> +_rte_eth_dev_callback_process_vf(struct rte_eth_dev *dev,
> + enum rte_eth_event_type event, void *param)
> +{
> + return _rte_eth_dev_callback_process_generic(dev, event, param);
> +}
> +
> +void
> +_rte_eth_dev_callback_process_generic(struct rte_eth_dev *dev,
> + enum rte_eth_event_type event, void *param)
> +{
>   struct rte_eth_dev_callback *cb_lst;
>   struct rte_eth_dev_callback dev_cb;
>  
> @@ -2699,6 +2713,9 @@ _rte_eth_dev_callback_process(struct rte_eth_dev *dev,
>   continue;
>   dev_cb = *cb_lst;
>   cb_lst->active = 1;
> + if (param != NULL)
> + dev_cb.cb_arg = (void *) param;
> +
>   rte_spinlock_unlock(&rte_eth_dev_cb_lock);
>   dev_cb.cb_fn(dev->data->port_id, dev_cb.event,
>   dev_cb.cb_arg);
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index b0fe033..4fb0b9c 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -3047,9 +3047,27 @@ enum rte_eth_event_type {
>   /**< queue state event (enabled/disabled) */
>   RTE_ETH_EVENT_INTR_RESET,
>   /**< reset interrupt event, sent to VF on PF reset */
> + RTE_ETH_EVENT_VF_MBOX,  /**< PF mailbox processing callback */
>   RTE_ETH_EVENT_MAX   /**< max value of this enum */
>  };
>  
> +/**
> + * Response sent back to ixgbe driver from user app after callback
> + */
> +enum rte_eth_mb_event_rsp {
> + RTE_ETH_MB_EVENT_NOOP_ACK,  /**< skip mbox request and ACK */
> + RTE_ETH_MB_EVENT_NOOP_NACK, /**< skip mbox request and NACK */
> + RTE_ETH_MB_EVENT_PROCEED,  /**< proceed with mbox request  */
> + RTE_ETH_MB_EVENT_MAX   /**< max value of this enum */
> +};

Do we really need to define the specifics of PF to VF MBOX communication
in normative ethdev specification?
Each drivers may have different PF to VF MBOX definitions so it may not be
very portable.
What is the use-case here? If its for VF configuration, I think we can
do it as separate 'sync' functions for each functionality so that
PMDs will have room hiding the specifics on MBOX definitions.

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Dey, Souvik]

Hi Mark/Liu,

  Thanks to both of you for being so patient with a series of silly 
errors. I have tried to make it better this time. Also there were some un-used 
variable in the function which I have removed. Please check the new patch with 
all your comments incorporated. Also along with the L2_HDR_LEN and L2_CRC_LEN, 
I have taken in consideration the VLAN_LEN too.



One doubt though,

"9728 is the largest L2 frame size allowed by the NIC" -- this 9728 size is 
some constrain due to DPDK as the virtio driver in the kernel can support till 
mtu size of 68 to 65535, where as in DPDK pmd we are trying with 64 to 9728.



drivers/net/virtio/virtio_ethdev.c | 19 +++

1 file changed, 19 insertions(+)



diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c

index 07d6449..da16ad4 100644

--- a/drivers/net/virtio/virtio_ethdev.c

+++ b/drivers/net/virtio/virtio_ethdev.c

@@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)

PMD_INIT_LOG(ERR, "Failed to disable allmulticast");

}



+#define VLAN_TAG_LEN   4/* 802.3ac tag (not DMA'd) */

+

+static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)

+{

+   struct rte_eth_dev_info dev_info;

+   uint32_t ether_hdr_len = ETHER_HDR_LEN + ETHER_CRC_LEN + VLAN_TAG_LEN;

+   uint32_t frame_size = mtu + ether_hdr_len;

+

+   virtio_dev_info_get(dev, &dev_info);

+

+   if (mtu < dev_info.min_rx_bufsize || frame_size > 
dev_info.max_rx_pktlen) {

+   PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",

+   dev_info.min_rx_bufsize,

+   (dev_info.max_rx_pktlen - ether_hdr_len));

+   return -EINVAL;

+   }

+   return 0;

+}

@@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {

.allmulticast_enable = virtio_dev_allmulticast_enable,

.allmulticast_disable= virtio_dev_allmulticast_disable,

+   .mtu_set = virtio_mtu_set,

.dev_infos_get   = virtio_dev_info_get,

.stats_get   = virtio_dev_stats_get,

.xstats_get  = virtio_dev_xstats_get,





--

Regards,

Souvik



-Original Message-
From: Kavanagh, Mark B [mailto:mark.b.kavan...@intel.com]
Sent: Friday, September 9, 2016 11:44 AM
To: Dey, Souvik ; Yuanhan Liu 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio



>

>Hi Mark,

>

>Yes I thought I did that change. Sorry once again.. making too many mistakes. 
>Changed it .

>Thanks.

>The MTU here is L3 MTU.  Setting this will help in reducing the

>fragmented/multi-segmented packets and also in case we want to reduce

>the MTU below 1500, to support VXLAN or GRE tunnel for the packets in 
>openstack and cloud environments.

>

>---

> drivers/net/virtio/virtio_ethdev.c | 12 

> 1 file changed, 12 insertions(+)

>

>diff --git a/drivers/net/virtio/virtio_ethdev.c

>b/drivers/net/virtio/virtio_ethdev.c

>index 07d6449..da16ad4 100644

>--- a/drivers/net/virtio/virtio_ethdev.c

>+++ b/drivers/net/virtio/virtio_ethdev.c

>

>static int virtio_dev_queue_stats_mapping_set(

>__rte_unused struct rte_eth_dev *eth_dev, @@ -652,6 +653,16 @@

>virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)

>   PMD_INIT_LOG(ERR, "Failed to disable 
> allmulticast");  }

>

>+static int

>+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {

>+  struct virtio_hw *hw = dev->data->dev_private;

>+  if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {



If MTU is the L3 MTU as you've indicated, then you need to take account of L2 
overhead before performing the comparison above.

Say the user supplies 'mtu' as 9728 - the corresponding minimum frame size is 
L2_HDR_LEN + 9728 + L2_CRC_LEN = 9746 bytes, which is larger than the NIC can 
accommodate (note that 9728 is the largest L2 frame size allowed by the NIC, 
not the largest IP packet size).



>+PMD_INIT_LOG(ERR, "Mtu should be between 
>VIRTIO_MIN_RX_BUFSIZE and

>VIRTIO_MAX_RX_PKTLEN \n");



Two things on this statement:

1) in the context of a log message, VIRTIO_XXX_RX_BUFSIZE most likely means 
very little, and as such is not helpful. I suggest going with the format that I 
included in my earlier mail, which prints the numeric value of the min and max 
rx defines

2)  MTU is an initialization, and should be printed as such in a log 
(i.e. all caps) 



Hope this helps,

Mark



>+return -EINVAL;

>+  }

>+  return 0;

>+}

>+

> /*

>  * dev_ops for virtio, bare necessities for basic operation

>  */

>@@ -664,6 +675,7 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {

>.promiscuous_disable = virtio_dev_promiscuous_disable,

>.allmulticast_

[dpdk-dev] [PATCH v7 0/9] enable lpm, acl and other missing libraries in ppc64le

[Thomas Monjalon]

> > v7 changes:
> > - removed enforcing cache alignment for table hash structs and
> >   instead check only for multiples of 64 bytes.
> > 
> 
> Acked-by: Cristian Dumitrescu 

Applied, thanks

We now have some AltiVec code in DPDK!

[dpdk-dev] [RFC] igb_uio: deprecate iomem and ioport mapping

[Tan, Jianfeng]

Hi David,

Thank you for reviewing this.

On 9/9/2016 5:06 PM, David Marchand wrote:
> Hello Jianfeng,
>
> On Thu, Sep 1, 2016 at 4:16 AM, Jianfeng Tan  
> wrote:
>> Previously in igb_uio, iomem is mapped, and both ioport and io mem
>> are recorded into uio framework, which is duplicated and makes the
>> code too complex.
>>
>> For iomem, DPDK user space code never opens or reads files under
>> /sys/pci/bus/devices/:xx:xx.x/uio/uioY/maps/. Instead,
>> /sys/pci/bus/devices/:xx:xx.x/resourceY are used to map device
>> memory.
>>
>> For ioport, non-x86 platforms cannot read from files under
>> /sys/pci/bus/devices/:xx:xx.x/uio/uioY/portio/ directly, because
>> non-x86 platforms need to map port region for access in user space,
>> see non-x86 version pci_uio_ioport_map(). x86 platforms can use the
>> the same way as uio_pci_generic.
>>
>> This patch deprecates iomem and ioport mapping in igb_uio kernel
>> module, and adjusts the iomem implementation in both igb_uio and
>> uio_pci_generic:
>>- for x86 platform, get ports info from /proc/ioports;
>>- for non-x86 platform, map and get ports info by pci_uio_ioport_map().
>>
>> Note: this will affect those applications who are using files under
>> /sys/pci/bus/devices/:xx:xx.x/uio/uioY/maps/ and
>> /sys/pci/bus/devices/:xx:xx.x/uio/uioY/portio/.
>>
>> Signed-off-by: Jianfeng Tan 
>> ---
>>   lib/librte_eal/linuxapp/eal/eal_pci.c |   4 -
>>   lib/librte_eal/linuxapp/eal/eal_pci_uio.c |  56 +-
>>   lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 119 
>> ++
>>   3 files changed, 9 insertions(+), 170 deletions(-)
> [snip]
>
>> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c 
>> b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
>> index 1786b75..28d09ed 100644
>> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
>> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> [snip]
>
>> -   /* FIXME only for primary process ? */
>> -   if (dev->intr_handle.type == RTE_INTR_HANDLE_UNKNOWN) {
>> -
>> -   snprintf(filename, sizeof(filename), "/dev/uio%u", uio_num);
>> -   dev->intr_handle.fd = open(filename, O_RDWR);
>> -   if (dev->intr_handle.fd < 0) {
>> -   RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
>> -   filename, strerror(errno));
>> -   return -1;
>> -   }
>> -   dev->intr_handle.type = RTE_INTR_HANDLE_UIO;
>> -   }
> The only potential issue I can see removing this is that if a device
> has no iomem resource, then its interrupt fd will never be
> initialised.

I'm catching it completely. IMO, dev->intr_handle.fd will be bound to be 
initialized in pci_uio_alloc_resource() <- pci_uio_map_resource() <- 
rte_eal_pci_map_device() after this patch, just like what we've done 
with uio-pci-generic. Or I'm missing something?

> I can see no problem at the moment, so let's go with this.
> If such a problem arises later, we can separate this from the resource
> mapping stuff (with a new api ?).
> The rest looks good to me.
>
> As Ferruh said, this should go through deprecation notices then go in 17.02.
>
Yes, no problem.

Thanks,
Jianfeng

[dpdk-dev] [PATCH 1/1] doc: clarify usage of testpmd mac fwd mode

[Mark Kavanagh]

Explain default testpmd behavior in mac fwd mode to remove
amiguity/confusion regarding user's ability to specify Ethernet
addresses.

Signed-off-by: Mark Kavanagh 
---
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index f87e0c2..6ab910e 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -267,6 +267,9 @@ The available information categories are:
   This is the default mode.

 * ``mac``: Changes the source and the destination Ethernet addresses of 
packets before forwarding them.
+  Default application behaviour is to set source Ethernet address to that of 
the transmitting interface, and destination
+  address to a dummy value (set during init). The user may specify a target 
destination Ethernet address via the 'eth-peer' or
+  'eth-peer-configfile' command-line options. It is not currently possible to 
specify a specific source Ethernet address.

 * ``macswap``: MAC swap forwarding mode.
   Swaps the source and the destination Ethernet addresses of packets before 
forwarding them.
-- 
1.9.3

[dpdk-dev] [PATCH v9 00/25] Introducing rte_driver/rte_device generalization

[Shreyansh Jain]

Hi Stephen,

On Thursday 08 September 2016 10:19 PM, Stephen Hemminger wrote:
[...]
>> > I think yes. There are separate lists for all device types which helps
>> > keep the EAL code free of type checks. But, functionally it doesn't make
>> > that big a different between a common or specific list.
>> > I am in favor of separate lists of each rte_xxx_device/driver type -
>> > other than a global list (which is not actually being used, for now).
> I was just concerned that doing bookkeeping on multiple lists creates more 
> possibilities
> for bugs where error unwind paths don't match.
>

That is true.
But in this particular situation (in my opinion), maintaining multiple 
lists helps because:

1. Device/Drivers lists are separate and no functionality except setup 
and tear-down operation would ever need to parse the common list - at 
least not during the application run-to-completion-cycle.

2. Keeping them separate helps make the respective scan/probe code 
cleaner. In fact, in absence of checks for device type, I think 
debugging would be easier as one would only need to focus on code 
related to attached physical/virtual device.

But again, above is just my opinion and preference - if merging the 
lists helps, it can be done. In fact, rte_driver/rte_device are already 
creating a common list - just that it is not being used right now.

I don't think there is any technical impact of this (except increasing 
type validation - but that is only in setup/tear-down path).

-- 
Shreyansh

[dpdk-dev] [PATCH v9 00/25] Introducing rte_driver/rte_device generalization

[Declan Doherty]

On 07/09/16 15:07, Shreyansh Jain wrote:
> Based on master (e22856313)
>
> Background:
> ===
>
> It includes two different patch-sets floated on ML earlier:
>  * Original patch series is from David Marchand [1], [2].
>   `- This focused mainly on PCI (PDEV) part
>   `- v7 of this was posted by me [8] in August/2016
>  * Patch series [4] from Jan Viktorin
>   `- This focused on VDEV and rte_device integration
>
> Introduction:
> =
>
> This patch series introduces a generic device model, moving away from PCI
> centric code layout. Key change is to introduce rte_driver/rte_device
> structures at the top level which are inherited by
> rte_XXX_driver/rte_XXX_device - where XXX belongs to {pci, vdev, soc (in
> future),...}.
>
> Key motivation for this series is to move away from PCI centric design of
> EAL to a more hierarchical device model - pivoted around a generic driver
> and device. Each specific driver and device can inherit the common
> properties of the generic set and build upon it through driver/device
> specific functions.
>
> Earlier, the EAL device initialization model was:
> (Refer: [3])
>
> --
>  Constructor:
>   |- PMD_DRIVER_REGISTER(rte_driver)
>  `-  insert into dev_driver_list, rte_driver object
>
>  rte_eal_init():
>   |- rte_eal_pci_init()
>   |  `- scan and fill pci_device_list from sysfs
>   |
>   |- rte_eal_dev_init()
>   |  `- For each rte_driver in dev_driver_list
>   | `- call the rte_driver->init() function
>   ||- PMDs designed to call rte_eth_driver_register(eth_driver)
>   ||- eth_driver have rte_pci_driver embedded in them
>   |`- rte_eth_driver_register installs the
>   |   rte_pci_driver->devinit/devuninit callbacks.
>   |
>   |- rte_eal_pci_probe()
>   |  |- For each device detected, dev_driver_list is parsed and matching is
>   |  |  done.
>   |  |- For each matching device, the rte_pci_driver->devinit() is called.
>   |  |- Default map is to rte_eth_dev_init() which in turn creates a
>   |  |  new ethernet device (eth_dev)
>   |  |  `- eth_drv->eth_dev_init() is called which is implemented by
>   `--|individual PMD drivers.
>
> --
>
> The structure of driver looks something like:
>
>  ++ ._.
>  | rte_driver <-| PMD |___
>  |  .init | `-`   \
>  +.---+  | \
>   `-.| What PMD actually is
>  \   |  |
>   +--v+ |
>   | eth_driver| |
>   | .eth_dev_init | |
>   +.--+ |
>`-.  |
>   \ |
>+v---+
>| rte_pci_driver |
>| .pci_devinit   |
>++
>
>   and all devices are part of a following linked lists:
> - dev_driver_list for all rte_drivers
> - pci_device_list for all devices, whether PCI or VDEV
>
>
> From the above:
>  * a PMD initializes a rte_driver, eth_driver even though actually it is a
>pci_driver
>  * initialization routines are passed from rte_driver->pci_driver->eth_driver
>even though they should ideally be rte_eal_init()->rte_pci_driver()
>  * For a single driver/device type model, this is not necessarily a
>functional issue - but more of a design language.
>  * But, when number of driver/device type increase, this would create problem
>in how driver<=>device links are represented.
>
> Proposed Architecture:
> ==
>
> A nice representation has already been created by David in [3]. Copying that
> here:
>
> +--+ +---+
> |  | |   |
> | rte_pci_device   | | rte_pci_driver|
> |  | |   |
> +-+ | +--+ | | +---+ |
> | | | |  | | | |   | |
> | rte_eth_dev +---> rte_device   +-> rte_driver| |
> | | | |  char name[] | | | |  char name[]  | |
> +-+ | |  | | | |  int init(rte_device *)   | |
> | +--+ | | |  int uninit(rte_device *) | |
> |  | | |   | |
> +--+ | +---+ |
>  |   |
>  +---+
>
> - for ethdev on top of vdev devices
>
> +--+ +---+
> |  | |   |
> | drv specific | | rte_vdev_driver   |
> |  | |  

[dpdk-dev] [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework

[Tan, Jianfeng]

Hi Pankaj,

Thanks for the massive and great work.

On 9/5/2016 6:54 PM, Pankaj Chauhan wrote:
> Introduce support for a generic framework for handling of switching between
> physical and vhost devices. The vswitch framework introduces the following
> concept:
>
> 1. vswitch_dev: Vswitch device is a logical switch which can have physical and
> virtio devices. The devices are operated/used using standard rte_eth API for
> physical devices and lib_vhost API for vhost devices, PMD API is not used
> for vhost devices.
>
> 2. vswitch_port: Any physical or virtio device that is added to vswitch. The
> port can have its own tx/rx functions for doing data transfer, which are 
> exposed
> to the framework using generic function pointers (vs_port->do_tx/do_rx). This 
> way
> the generic code can do tx/rx without understanding the type of device 
> (Physical or
> virtio). Similarly each port has its own functions to select tx/rx queues. 
> The framework
> provides default tx/rx queue selection functions to the port when port is 
> added
> (for both physical and vhost devices). But the framework allows the switch 
> implementation
> to override the queue selection functions (vs_port->get_txq/rxq) if required.
>
> 3. vswitch_ops: The ops is set of function pointers which are used to do 
> operations
> like learning, unlearning, add/delete port, lookup_and_forward. The user of 
> vswitch
> framework (vhost/main.[c,h])uses these function pointers to perform above 
> mentioned
> operations, thus it remains agnostic of the underlying implementation.
>
> Different switching logics can implement their vswitch_device and 
> vswitch_ops, and
> register with the framework. This framework makes vhost-switch application 
> scalable
> in terms of:
>
> 1. Different switching logics (one of them is vmdq, vhost/vmdq.[c,h]
> 2. Number of ports.
> 3. Policies of selecting ports for rx and tx.
>
> Signed-off-by: Pankaj Chauhan 

After this patch set, how's mapping relationship between cores and 
vswitch_dev? Old vhost example does not have the concept of switch, so 
each core is binded with some VDEVs. Now, we still keep original logic?

(a) If yes, provided that phys device could has no direct relationship 
with vdevs in other switching logics, we may need to bind those physical 
devices to cores too? In that case, switch_worker() will receiving pkts 
from all devices (phys or virtual) and dispatch, which looks like:

switch_worker() {
 FOR each port binding to this core {
  rx(port, pkts[], count);
  vs_lookup_n_fwd( information_needed );
 }
}

(b) If no, we may bind each core with n switches? If so, switch_worker() 
also need to be reworked to keep receiving pkts from all ports of the 
switch, and dispatch.

switch_worker() {
 FOR each switch binding to this core {
  FOR each port of switch {
  rx(port, pkts[], count);
  vs_lookup_n_fwd( information_needed );
 }
 }
}

In all, (1) we'd better not use vdev to find phys dev in switch_worker 
any more; (2) we'd better not differentiate phys device and virtual 
device in generic framework (it's just an attribute of vswitch_port.

What do you think?

Thanks,
Jianfeng

[dpdk-dev] [PATCH v2 2/2] app/test: add test cases for MD5 HMAC for Intel QAT driver

[Deepak Kumar Jain]

From: Arkadiusz Kusztal 

Added MD5 HMAC hash algorithm to test file for Intel QuickAssist
Technology Driver

Signed-off-by: Arek Kusztal 
Acked-by: Fiona Trahe 
---
 app/test/test_cryptodev.c   | 185 
 app/test/test_cryptodev_hmac_test_vectors.h | 121 ++
 2 files changed, 306 insertions(+)
 create mode 100644 app/test/test_cryptodev_hmac_test_vectors.h

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 647787d..8553759 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -49,6 +49,7 @@
 #include "test_cryptodev_snow3g_test_vectors.h"
 #include "test_cryptodev_snow3g_hash_test_vectors.h"
 #include "test_cryptodev_gcm_test_vectors.h"
+#include "test_cryptodev_hmac_test_vectors.h"

 static enum rte_cryptodev_type gbl_cryptodev_type;

@@ -3431,6 +3432,179 @@ test_stats(void)
return TEST_SUCCESS;
 }

+static int MD5_HMAC_create_session(struct crypto_testsuite_params *ts_params,
+  struct crypto_unittest_params *ut_params,
+  enum rte_crypto_auth_operation op,
+  const struct HMAC_MD5_vector *test_case)
+{
+   uint8_t key[64];
+
+   memcpy(key, test_case->key.data, test_case->key.len);
+
+   ut_params->auth_xform.type = RTE_CRYPTO_SYM_XFORM_AUTH;
+   ut_params->auth_xform.next = NULL;
+   ut_params->auth_xform.auth.op = op;
+
+   ut_params->auth_xform.auth.algo = RTE_CRYPTO_AUTH_MD5_HMAC;
+
+   ut_params->auth_xform.auth.digest_length = MD5_DIGEST_LEN;
+   ut_params->auth_xform.auth.add_auth_data_length = 0;
+   ut_params->auth_xform.auth.key.length = test_case->key.len;
+   ut_params->auth_xform.auth.key.data = key;
+
+   ut_params->sess = rte_cryptodev_sym_session_create(
+   ts_params->valid_devs[0], &ut_params->auth_xform);
+
+   if (ut_params->sess == NULL)
+   return TEST_FAILED;
+
+   ut_params->ibuf = rte_pktmbuf_alloc(ts_params->mbuf_pool);
+
+   memset(rte_pktmbuf_mtod(ut_params->ibuf, uint8_t *), 0,
+   rte_pktmbuf_tailroom(ut_params->ibuf));
+
+   return 0;
+}
+
+static int MD5_HMAC_create_op(struct crypto_unittest_params *ut_params,
+ const struct HMAC_MD5_vector *test_case,
+ uint8_t **plaintext)
+{
+   uint16_t plaintext_pad_len;
+
+   struct rte_crypto_sym_op *sym_op = ut_params->op->sym;
+
+   plaintext_pad_len = RTE_ALIGN_CEIL(test_case->plaintext.len,
+   16);
+
+   *plaintext = (uint8_t *)rte_pktmbuf_append(ut_params->ibuf,
+   plaintext_pad_len);
+   memcpy(*plaintext, test_case->plaintext.data,
+   test_case->plaintext.len);
+
+   sym_op->auth.digest.data = (uint8_t *)rte_pktmbuf_append(
+   ut_params->ibuf, MD5_DIGEST_LEN);
+   TEST_ASSERT_NOT_NULL(sym_op->auth.digest.data,
+   "no room to append digest");
+   sym_op->auth.digest.phys_addr = rte_pktmbuf_mtophys_offset(
+   ut_params->ibuf, plaintext_pad_len);
+   sym_op->auth.digest.length = MD5_DIGEST_LEN;
+
+   if (ut_params->auth_xform.auth.op == RTE_CRYPTO_AUTH_OP_VERIFY) {
+   rte_memcpy(sym_op->auth.digest.data, test_case->auth_tag.data,
+  test_case->auth_tag.len);
+   }
+
+   sym_op->auth.data.offset = 0;
+   sym_op->auth.data.length = test_case->plaintext.len;
+
+   rte_crypto_op_attach_sym_session(ut_params->op, ut_params->sess);
+   ut_params->op->sym->m_src = ut_params->ibuf;
+
+   return 0;
+}
+
+static int
+test_MD5_HMAC_generate(const struct HMAC_MD5_vector *test_case)
+{
+   uint16_t plaintext_pad_len;
+   uint8_t *plaintext, *auth_tag;
+
+   struct crypto_testsuite_params *ts_params = &testsuite_params;
+   struct crypto_unittest_params *ut_params = &unittest_params;
+
+   if (MD5_HMAC_create_session(ts_params, ut_params,
+   RTE_CRYPTO_AUTH_OP_GENERATE, test_case))
+   return TEST_FAILED;
+
+   /* Generate Crypto op data structure */
+   ut_params->op = rte_crypto_op_alloc(ts_params->op_mpool,
+   RTE_CRYPTO_OP_TYPE_SYMMETRIC);
+   TEST_ASSERT_NOT_NULL(ut_params->op,
+   "Failed to allocate symmetric crypto operation struct");
+
+   plaintext_pad_len = RTE_ALIGN_CEIL(test_case->plaintext.len,
+   16);
+
+   if (MD5_HMAC_create_op(ut_params, test_case, &plaintext))
+   return TEST_FAILED;
+
+   TEST_ASSERT_NOT_NULL(process_crypto_request(ts_params->valid_devs[0],
+   ut_params->op), "failed to process sym crypto op");
+
+   TEST_ASSERT_EQUAL(ut_params->op->status, RTE_CRYPTO_OP_STATUS_SUCCESS,
+   "crypto op processing failed");
+
+   if

[dpdk-dev] [PATCH v2 1/2] crypto/qat: add MD5 HMAC capability to Intel QAT driver

[Deepak Kumar Jain]

From: Arkadiusz Kusztal 

Added posibility to compute MD5 HMAC digest with Intel QuickAssist
Technology Driver

Signed-off-by: Arek Kusztal 
Signed-off-by: Deepak Kumar Jain 
Acked-by: Fiona Trahe 
---
 doc/guides/cryptodevs/qat.rst|  1 +
 doc/guides/rel_notes/release_16_11.rst   |  5 
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 34 
 drivers/crypto/qat/qat_crypto.c  | 28 +--
 4 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index cae1958..485abb4 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -57,6 +57,7 @@ Hash algorithms:
 * ``RTE_CRYPTO_AUTH_SHA512_HMAC``
 * ``RTE_CRYPTO_AUTH_AES_XCBC_MAC``
 * ``RTE_CRYPTO_AUTH_SNOW3G_UIA2``
+* ``RTE_CRYPTO_AUTH_MD5_HMAC``


 Limitations
diff --git a/doc/guides/rel_notes/release_16_11.rst 
b/doc/guides/rel_notes/release_16_11.rst
index 66916af..4f7d784 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -36,6 +36,11 @@ New Features

  This section is a comment. Make sure to start the actual text at the 
margin.

+* **Updated the QAT PMD.**
+  The QAT PMD was updated with changes including the following:
+
+  * Added support for MD5_HMAC algorithm.
+

 Resolved Issues
 ---
diff --git a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c 
b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
index c658f6e..521a9c4 100644
--- a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
+++ b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
@@ -58,6 +58,7 @@

 #include/* Needed to calculate pre-compute values */
 #include/* Needed to calculate pre-compute values */
+#include/* Needed to calculate pre-compute values */


 /*
@@ -86,6 +87,9 @@ static int qat_hash_get_state1_size(enum icp_qat_hw_auth_algo 
qat_hash_alg)
case ICP_QAT_HW_AUTH_ALGO_SNOW_3G_UIA2:
return QAT_HW_ROUND_UP(ICP_QAT_HW_SNOW_3G_UIA2_STATE1_SZ,
QAT_HW_DEFAULT_ALIGNMENT);
+   case ICP_QAT_HW_AUTH_ALGO_MD5:
+   return QAT_HW_ROUND_UP(ICP_QAT_HW_MD5_STATE1_SZ,
+   QAT_HW_DEFAULT_ALIGNMENT);
case ICP_QAT_HW_AUTH_ALGO_DELIMITER:
/* return maximum state1 size in this case */
return QAT_HW_ROUND_UP(ICP_QAT_HW_SHA512_STATE1_SZ,
@@ -107,6 +111,8 @@ static int qat_hash_get_digest_size(enum 
icp_qat_hw_auth_algo qat_hash_alg)
return ICP_QAT_HW_SHA256_STATE1_SZ;
case ICP_QAT_HW_AUTH_ALGO_SHA512:
return ICP_QAT_HW_SHA512_STATE1_SZ;
+   case ICP_QAT_HW_AUTH_ALGO_MD5:
+   return ICP_QAT_HW_MD5_STATE1_SZ;
case ICP_QAT_HW_AUTH_ALGO_DELIMITER:
/* return maximum digest size in this case */
return ICP_QAT_HW_SHA512_STATE1_SZ;
@@ -129,6 +135,8 @@ static int qat_hash_get_block_size(enum 
icp_qat_hw_auth_algo qat_hash_alg)
return SHA512_CBLOCK;
case ICP_QAT_HW_AUTH_ALGO_GALOIS_128:
return 16;
+   case ICP_QAT_HW_AUTH_ALGO_MD5:
+   return MD5_CBLOCK;
case ICP_QAT_HW_AUTH_ALGO_DELIMITER:
/* return maximum block size in this case */
return SHA512_CBLOCK;
@@ -172,6 +180,19 @@ static int partial_hash_sha512(uint8_t *data_in, uint8_t 
*data_out)
return 0;
 }

+static int partial_hash_md5(uint8_t *data_in, uint8_t *data_out)
+{
+
+   MD5_CTX ctx;
+
+   if (!MD5_Init(&ctx))
+   return -EFAULT;
+   MD5_Transform(&ctx, data_in);
+   rte_memcpy(data_out, &ctx, MD5_DIGEST_LENGTH);
+
+   return 0;
+}
+
 static int partial_hash_compute(enum icp_qat_hw_auth_algo hash_alg,
uint8_t *data_in,
uint8_t *data_out)
@@ -213,6 +234,10 @@ static int partial_hash_compute(enum icp_qat_hw_auth_algo 
hash_alg,
*hash_state_out_be64 =
rte_bswap64(*(((uint64_t *)digest)+i));
break;
+   case ICP_QAT_HW_AUTH_ALGO_MD5:
+   if (partial_hash_md5(data_in, data_out))
+   return -EFAULT;
+   break;
default:
PMD_DRV_LOG(ERR, "invalid hash alg %u", hash_alg);
return -EFAULT;
@@ -620,6 +645,15 @@ int qat_alg_aead_session_create_content_desc_auth(struct 
qat_session *cdesc,
auth_param->hash_state_sz =
RTE_ALIGN_CEIL(add_auth_data_length, 16) >> 3;
break;
+   case ICP_QAT_HW_AUTH_ALGO_MD5:
+   if (qat_alg_do_precomputes(ICP_QAT_HW_AUTH_ALGO_MD5,
+   authkey, authkeylen, cdesc->cd_cur_ptr,
+   &state1_size)) {
+   PMD_DRV_LOG(ERR, "(MD5)precompute failed");
+  

[dpdk-dev] [PATCH v2 0/2] Add HMAC_MD5 to Intel QuickAssist Technology driver

[Deepak Kumar Jain]

This patchset add capability to use HMAC_MD5 hash algorithm to Intel 
QuickAssist Technology driver and test cases to cryptodev test files.

This patchset depends on the following patches/patchsets:

"crypto/qat: make the session struct variable in size"
(http://dpdk.org/dev/patchwork/patch/15125/)

Arkadiusz Kusztal (2):
  crypto/qat: add MD5 HMAC capability to Intel QAT driver
  app/test: add test cases for MD5 HMAC for Intel QAT driver

Changes from v1:
* Added new feature information in release_16_11.rst file.

 app/test/test_cryptodev.c| 185 +++
 app/test/test_cryptodev_hmac_test_vectors.h  | 121 +++
 doc/guides/cryptodevs/qat.rst|   1 +
 doc/guides/rel_notes/release_16_11.rst   |   5 +
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c |  34 +
 drivers/crypto/qat/qat_crypto.c  |  28 +++-
 6 files changed, 372 insertions(+), 2 deletions(-)
 create mode 100644 app/test/test_cryptodev_hmac_test_vectors.h

-- 
2.5.5

[dpdk-dev] [PATCH v2] kni: Bug fix in module_init and module_exit

[Thomas Monjalon]

2016-09-06 09:02, Ferruh Yigit:
> On 9/2/2016 11:23 AM, Vincent Guo wrote:
> > Fix pernet calls when HAVE_SIMPLIFIED_PERNET_OPERATIONS is not set.
> > 
> > Fixes: e6734d21b4e1 ("kni: fix build with kernel 2.6.32")
> > 
> > Signed-off-by: Vincent Guo 
> 
> Only patch subject should start with lowercase, Thomas would you mind
> fixing this while applying?
> 
> Acked-by Ferruh Yigit 

Applied, thanks

[dpdk-dev] [dpdk-stable] [PATCH] testpmd: fix crash when mempool allocation fails

[Yuanhan Liu]

On Fri, Sep 09, 2016 at 10:16:25AM +0200, Olivier Matz wrote:
> Avoid access to mempool pointer if it is NULL.
> 
> Fixes: b19a0c75a0d4 ("app/testpmd: remove anonymous mempool code")
> Coverity issue: 127553
> 
> Signed-off-by: Olivier Matz 
> ---
>  app/test-pmd/testpmd.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index 1428974..e0f8285 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -444,10 +444,13 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned 
> nb_mbuf,
>   mb_size, (unsigned) mb_mempool_cache,
>   sizeof(struct rte_pktmbuf_pool_private),
>   socket_id, 0);
> + if (rte_mp == NULL)
> + goto err;
>  
>   if (rte_mempool_populate_anon(rte_mp) == 0) {
>   rte_mempool_free(rte_mp);
>   rte_mp = NULL;
> + goto err;
>   }
>   rte_pktmbuf_pool_init(rte_mp, NULL);
>   rte_mempool_obj_iter(rte_mp, rte_pktmbuf_init, NULL);
> @@ -458,6 +461,7 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned nb_mbuf,
>   }
>   }
>  
> + err:

A minor nit: there is a heading white space char.

--yliu

>   if (rte_mp == NULL) {
>   rte_exit(EXIT_FAILURE,
>   "Creation of mbuf pool for socket %u failed: %s\n",
> -- 
> 2.8.1

[dpdk-dev] [PATCH v2] net/vhost: add pmd xstats

[Zhiyong Yang]

This feature adds vhost pmd extended statistics from per queue perspective
for the application such as OVS etc.

The statistics counters are based on RFC 2819 and RFC 2863 as follows:

rx/tx_good_packets
rx/tx_total_bytes
rx/tx_dropped_pkts
rx/tx_broadcast_packets
rx/tx_multicast_packets
rx/tx_ucast_packets
rx/tx_undersize_errors
rx/tx_size_64_packets
rx/tx_size_65_to_127_packets;
rx/tx_size_128_to_255_packets;
rx/tx_size_256_to_511_packets;
rx/tx_size_512_to_1023_packets;
rx/tx_size_1024_to_1522_packets;
rx/tx_1523_to_max_packets;
rx/tx_errors
rx_fragmented_errors
rx_jabber_errors
rx_unknown_protos_packets;

No API is changed or added.
rte_eth_xstats_get_names() to retrieve what kinds of vhost xstats are
supported,
rte_eth_xstats_get() to retrieve vhost extended statistics,
rte_eth_xstats_reset() to reset vhost extended statistics. 

The usage of vhost pmd xstats is the same as virtio pmd xstats.
for example, when test-pmd application is running in interactive mode
vhost pmd xstats will support the two following commands:

show port xstats all | port_id will show vhost xstats
clear port xstats all | port_id will reset vhost xstats

net/virtio pmd xstats(the function virtio_update_packet_stats) is used
as reference when implementing the feature. 

Signed-off-by: Zhiyong Yang 
---

Changes in v2:
1. remove the compiling switch.
2. fix two code bugs.

 drivers/net/vhost/rte_eth_vhost.c | 282 +-
 1 file changed, 281 insertions(+), 1 deletion(-)

diff --git a/drivers/net/vhost/rte_eth_vhost.c 
b/drivers/net/vhost/rte_eth_vhost.c
index 7539cd4..8f805f3 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -72,6 +72,10 @@ static struct ether_addr base_eth_addr = {
}
 };

+struct vhost_xstats {
+   uint64_t stat[16];
+};
+
 struct vhost_queue {
int vid;
rte_atomic32_t allow_queuing;
@@ -85,7 +89,8 @@ struct vhost_queue {
uint64_t missed_pkts;
uint64_t rx_bytes;
uint64_t tx_bytes;
-};
+   struct vhost_xstats xstats;
+   };

 struct pmd_internal {
char *dev_name;
@@ -127,6 +132,274 @@ struct rte_vhost_vring_state {

 static struct rte_vhost_vring_state *vring_states[RTE_MAX_ETHPORTS];

+enum rte_vhostqueue_rxtx {
+   RTE_VHOSTQUEUE_RX = 0,
+   RTE_VHOSTQUEUE_TX = 1
+};
+
+#define RTE_ETH_VHOST_XSTATS_NAME_SIZE 64
+
+struct rte_vhost_xstats_name_off {
+   char name[RTE_ETH_VHOST_XSTATS_NAME_SIZE];
+   uint64_t offset;
+};
+
+/* [rt]_qX_ is prepended to the name string here */
+static const struct rte_vhost_xstats_name_off rte_vhost_rxq_stat_strings[] = {
+   {"good_packets",
+   offsetof(struct vhost_queue, rx_pkts)},
+   {"total_bytes",
+   offsetof(struct vhost_queue, rx_bytes)},
+   {"dropped_pkts",
+   offsetof(struct vhost_queue, missed_pkts)},
+   {"broadcast_packets",
+   offsetof(struct vhost_queue, xstats.stat[8])},
+   {"multicast_packets",
+   offsetof(struct vhost_queue, xstats.stat[9])},
+   {"ucast_packets",
+   offsetof(struct vhost_queue, xstats.stat[10])},
+   {"undersize_errors",
+   offsetof(struct vhost_queue, xstats.stat[0])},
+   {"size_64_packets",
+   offsetof(struct vhost_queue, xstats.stat[1])},
+   {"size_65_to_127_packets",
+   offsetof(struct vhost_queue, xstats.stat[2])},
+   {"size_128_to_255_packets",
+   offsetof(struct vhost_queue, xstats.stat[3])},
+   {"size_256_to_511_packets",
+   offsetof(struct vhost_queue, xstats.stat[4])},
+   {"size_512_to_1023_packets",
+   offsetof(struct vhost_queue, xstats.stat[5])},
+   {"size_1024_to_1522_packets",
+   offsetof(struct vhost_queue, xstats.stat[6])},
+   {"size_1523_to_max_packets",
+   offsetof(struct vhost_queue, xstats.stat[7])},
+   {"errors",
+   offsetof(struct vhost_queue, xstats.stat[11])},
+   {"fragmented_errors",
+   offsetof(struct vhost_queue, xstats.stat[12])},
+   {"jabber_errors",
+   offsetof(struct vhost_queue, xstats.stat[13])},
+   {"unknown_protos_packets",
+   offsetof(struct vhost_queue, xstats.stat[14])},
+};
+
+/* [tx]_qX_ is prepended to the name string here */
+static const struct rte_vhost_xstats_name_off rte_vhost_txq_stat_strings[] = {
+   {"good_packets",
+   offsetof(struct vhost_queue, tx_pkts)},
+   {"total_bytes",
+   offsetof(struct vhost_queue, tx_bytes)},
+   {"dropped_pkts",
+   offsetof(struct vhost_queue, missed_pkts)},
+   {"broadcast_packets",
+   offsetof(struct vhost_queue, xstats.stat[8])},
+   {"multicast_packets",

[dpdk-dev] [PATCH v9 01/25] eal: define macro container_of

[Shreyansh Jain]

Hi Adrien,

On Friday 09 September 2016 02:25 PM, Adrien Mazarguil wrote:
> This warning is a known issue in the Verbs header that will be addressed
> eventually. It occurs even without Shreyansh's patch (more likely when
> CONFIG_RTE_LIBRTE_MLX4_DEBUG and/or CONFIG_RTE_LIBRTE_MLX5_DEBUG are
> enabled).
>
> Your container_of() macro is fine, no need to spend time on this.
>
> --

Thank you very much for clarifying this.

-- 
Shreyansh

[dpdk-dev] [PATCH v2] kni: support RHEL 6.8

[Thomas Monjalon]

2016-08-31 15:49, Ferruh Yigit:
> Add support for RHEL6.8 which uses an old version of kernel with some
> new features backported.
> 
> Signed-off-by: Ferruh Yigit 

Applied, thanks

[dpdk-dev] [PATCH] kni: fix crash for KNI interface remove

[Thomas Monjalon]

2016-08-31 14:06, Ferruh Yigit:
> Removing KNI interface that has no PCI driver for ethtool support cause
> kernel crash.
> 
> Fixes: 109febfe58f9 ("net/igb: move PCI device IDs from EAL")
> Fixes: 221fba3b987c ("net/ixgbe: move PCI device IDs from EAL")
> 
> Signed-off-by: Ferruh Yigit 

Applied, thanks

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Kavanagh, Mark B]

>
>Hi Mark,
>
>Yes I thought I did that change. Sorry once again.. making too many mistakes. 
>Changed it .
>Thanks.
>The MTU here is L3 MTU.  Setting this will help in reducing the 
>fragmented/multi-segmented
>packets and also in case we want to reduce the MTU below 1500, to support 
>VXLAN or GRE tunnel
>for the packets in openstack and cloud environments.
>
>---
> drivers/net/virtio/virtio_ethdev.c | 12 
> 1 file changed, 12 insertions(+)
>
>diff --git a/drivers/net/virtio/virtio_ethdev.c 
>b/drivers/net/virtio/virtio_ethdev.c
>index 07d6449..da16ad4 100644
>--- a/drivers/net/virtio/virtio_ethdev.c
>+++ b/drivers/net/virtio/virtio_ethdev.c
>
>static int virtio_dev_queue_stats_mapping_set(
>   __rte_unused struct rte_eth_dev *eth_dev,
>@@ -652,6 +653,16 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
>   PMD_INIT_LOG(ERR, "Failed to disable allmulticast");
> }
>
>+static int
>+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
>+{
>+  struct virtio_hw *hw = dev->data->dev_private;
>+  if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {

If MTU is the L3 MTU as you've indicated, then you need to take account of L2 
overhead before performing the comparison above.
Say the user supplies 'mtu' as 9728 - the corresponding minimum frame size is 
L2_HDR_LEN + 9728 + L2_CRC_LEN = 9746 bytes, which is larger than the NIC can 
accommodate (note that 9728 is the largest L2 frame size allowed by the NIC, 
not the largest IP packet size).

>+  PMD_INIT_LOG(ERR, "Mtu should be between VIRTIO_MIN_RX_BUFSIZE 
>and
>VIRTIO_MAX_RX_PKTLEN \n");

Two things on this statement:
1) in the context of a log message, VIRTIO_XXX_RX_BUFSIZE most likely means 
very little, and as such is not helpful. I suggest going with the format that I 
included in my earlier mail, which prints the numeric value of the min and max 
rx defines
2)  MTU is an initialization, and should be printed as such in a log 
(i.e. all caps) 

Hope this helps,
Mark

>+  return -EINVAL;
>+  }
>+  return 0;
>+}
>+
> /*
>  * dev_ops for virtio, bare necessities for basic operation
>  */
>@@ -664,6 +675,7 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
>   .promiscuous_disable = virtio_dev_promiscuous_disable,
>   .allmulticast_enable = virtio_dev_allmulticast_enable,
>   .allmulticast_disable= virtio_dev_allmulticast_disable,
>+  .mtu_set = virtio_mtu_set,
>
>   .dev_infos_get   = virtio_dev_info_get,
>   .stats_get   = virtio_dev_stats_get,
>--
>
>--
>Regards,
>Souvik
>-Original Message-
>From: Kavanagh, Mark B [mailto:mark.b.kavanagh at intel.com]
>Sent: Friday, September 9, 2016 11:05 AM
>To: Dey, Souvik ; Yuanhan Liu linux.intel.com>
>Cc: dev at dpdk.org; stephen at networkplumber.org
>Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio
>
>>
>>Hi Liu,
>>
>>Yes agreed your comment. I will definitely remove the declaration as it
>>is not really required.
>> So the latest patch will look like this . Yes I did rush a bit to
>>submit the patch last will correct my suite. So sending the patch in a
>>reply if we have more comments we can take a look and they re-submit the 
>>final reviewed
>patch. Thanks for the help though.
>>
>>---
>> drivers/net/virtio/virtio_ethdev.c | 12 
>> 1 file changed, 12 insertions(+)
>>
>>diff --git a/drivers/net/virtio/virtio_ethdev.c
>>b/drivers/net/virtio/virtio_ethdev.c
>>index 07d6449..da16ad4 100644
>>--- a/drivers/net/virtio/virtio_ethdev.c
>>+++ b/drivers/net/virtio/virtio_ethdev.c
>>
>>+static int
>>+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
>>+ struct virtio_hw *hw = dev->data->dev_private;
>>+ if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
>>+ PMD_INIT_LOG(ERR, "Mtu should be between 64 and 9728\n");
>
>Hi Souvik,
>
>Why hardcode the values in the PMD_INIT_LOG?
>
>Why not  do the following: PMD_INIT_LOG(ERR, "MTU should be between %d and %d",
>VIRTIO_MIN_RX_BUFSIZE,
>   VIRTIO_MAX_RX_PKTLEN);
>
>That way, if the values that the macros evaluate to change, the log will update
>correspondingly.
>
>Also, does 'MTU' in this context relate to the L2 or L3 MTU?
>
>>+ return -EINVAL;
>>+ }
>>+ return 0;
>>+}
>>+
>> /*
>>  * dev_ops for virtio, bare necessities for basic operation
>>  */
>>@@ -664,6 +675,7 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
>>  .promiscuous_disable = virtio_dev_promiscuous_disable,
>>  .allmulticast_enable = virtio_dev_allmulticast_enable,
>>  .allmulticast_disable= virtio_dev_allmulticast_disable,
>>+ .mtu_set = virtio_mtu_set,
>>
>>  .dev_infos_get   = virtio_dev_info_get,
>>  .stats_get   = virtio_dev_stats_get,
>>--
>>
>>--
>>Regards,
>>Souvik
>>
>>-

[dpdk-dev] [PATCH] scripts: reverse order of checked commits

[David Marchand]

On Fri, Sep 9, 2016 at 1:11 PM, Thomas Monjalon
 wrote:
> The list of git commits to check was in the reversed order.
> Also add a comment in the help of checkpatches.sh about list input.
>
> Signed-off-by: Thomas Monjalon 

Thanks Thomas.
Tested-by: David Marchand 


-- 
David Marchand

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Dey, Souvik]

Hi Mark,

Yes I thought I did that change. Sorry once again.. making too many mistakes. 
Changed it . Thanks. 
The MTU here is L3 MTU.  Setting this will help in reducing the 
fragmented/multi-segmented packets and also in case we want to reduce the MTU 
below 1500, to support VXLAN or GRE tunnel for the packets in openstack and 
cloud environments.  

---
 drivers/net/virtio/virtio_ethdev.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 07d6449..da16ad4 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c

static int virtio_dev_queue_stats_mapping_set(
__rte_unused struct rte_eth_dev *eth_dev,
@@ -652,6 +653,16 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
PMD_INIT_LOG(ERR, "Failed to disable allmulticast");
 }

+static int
+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
+   PMD_INIT_LOG(ERR, "Mtu should be between VIRTIO_MIN_RX_BUFSIZE 
and VIRTIO_MAX_RX_PKTLEN \n");
+   return -EINVAL;
+   }
+   return 0;
+}
+
 /*
  * dev_ops for virtio, bare necessities for basic operation
  */
@@ -664,6 +675,7 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
.promiscuous_disable = virtio_dev_promiscuous_disable,
.allmulticast_enable = virtio_dev_allmulticast_enable,
.allmulticast_disable= virtio_dev_allmulticast_disable,
+   .mtu_set = virtio_mtu_set,

.dev_infos_get   = virtio_dev_info_get,
.stats_get   = virtio_dev_stats_get,
--

--
Regards,
Souvik
-Original Message-
From: Kavanagh, Mark B [mailto:mark.b.kavan...@intel.com] 
Sent: Friday, September 9, 2016 11:05 AM
To: Dey, Souvik ; Yuanhan Liu 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio

>
>Hi Liu,
>
>Yes agreed your comment. I will definitely remove the declaration as it 
>is not really required.
> So the latest patch will look like this . Yes I did rush a bit to 
>submit the patch last will correct my suite. So sending the patch in a 
>reply if we have more comments we can take a look and they re-submit the final 
>reviewed patch. Thanks for the help though.
>
>---
> drivers/net/virtio/virtio_ethdev.c | 12 
> 1 file changed, 12 insertions(+)
>
>diff --git a/drivers/net/virtio/virtio_ethdev.c 
>b/drivers/net/virtio/virtio_ethdev.c
>index 07d6449..da16ad4 100644
>--- a/drivers/net/virtio/virtio_ethdev.c
>+++ b/drivers/net/virtio/virtio_ethdev.c
>
>+static int
>+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
>+  struct virtio_hw *hw = dev->data->dev_private;
>+  if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
>+  PMD_INIT_LOG(ERR, "Mtu should be between 64 and 9728\n");

Hi Souvik,

Why hardcode the values in the PMD_INIT_LOG?

Why not  do the following: PMD_INIT_LOG(ERR, "MTU should be between %d and %d", 
 VIRTIO_MIN_RX_BUFSIZE,
VIRTIO_MAX_RX_PKTLEN);

That way, if the values that the macros evaluate to change, the log will update 
correspondingly.

Also, does 'MTU' in this context relate to the L2 or L3 MTU?

>+  return -EINVAL;
>+  }
>+  return 0;
>+}
>+
> /*
>  * dev_ops for virtio, bare necessities for basic operation
>  */
>@@ -664,6 +675,7 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
>   .promiscuous_disable = virtio_dev_promiscuous_disable,
>   .allmulticast_enable = virtio_dev_allmulticast_enable,
>   .allmulticast_disable= virtio_dev_allmulticast_disable,
>+  .mtu_set = virtio_mtu_set,
>
>   .dev_infos_get   = virtio_dev_info_get,
>   .stats_get   = virtio_dev_stats_get,
>--
>
>--
>Regards,
>Souvik
>
>-Original Message-
>From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
>Sent: Friday, September 9, 2016 3:00 AM
>To: Dey, Souvik 
>Cc: dev at dpdk.org; stephen at networkplumber.org
>Subject: Re: [PATCH v4]net/virtio: add mtu set in virtio
>
>On Wed, Sep 07, 2016 at 04:21:30AM +, Dey, Souvik wrote:
>> Hi Liu,
>>  Submitted the version 4 of the patch as you suggested ,
>
>Your patch is looking much better. But not really, you ignored few of my 
>comments.
>
>> and have removed the Reviewed by line.
>> I have still kept the function definition as to follow the same suit 
>> as we have done for
>other eth_dev_ops.
>
>That's because most of the method implementions are after the 
>reference, thus the declaration is needed.
>
>For your case, I see no good reason to do that. BTW, if you disagree 
>with my comment, you shoud made a reply, instead of rushing to sending a 

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Kavanagh, Mark B]

>
>Hi Liu,
>
>Yes agreed your comment. I will definitely remove the declaration as it is not 
>really
>required.
> So the latest patch will look like this . Yes I did rush a bit to submit the 
> patch last will
>correct my suite. So sending the patch in a reply if we have more comments we 
>can take a look
>and they re-submit the final reviewed patch. Thanks for the help though.
>
>---
> drivers/net/virtio/virtio_ethdev.c | 12 
> 1 file changed, 12 insertions(+)
>
>diff --git a/drivers/net/virtio/virtio_ethdev.c 
>b/drivers/net/virtio/virtio_ethdev.c
>index 07d6449..da16ad4 100644
>--- a/drivers/net/virtio/virtio_ethdev.c
>+++ b/drivers/net/virtio/virtio_ethdev.c
>
>+static int
>+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
>+{
>+  struct virtio_hw *hw = dev->data->dev_private;
>+  if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
>+  PMD_INIT_LOG(ERR, "Mtu should be between 64 and 9728\n");

Hi Souvik,

Why hardcode the values in the PMD_INIT_LOG?

Why not  do the following: PMD_INIT_LOG(ERR, "MTU should be between %d and %d", 
 VIRTIO_MIN_RX_BUFSIZE,
VIRTIO_MAX_RX_PKTLEN);

That way, if the values that the macros evaluate to change, the log will update 
correspondingly.

Also, does 'MTU' in this context relate to the L2 or L3 MTU?

>+  return -EINVAL;
>+  }
>+  return 0;
>+}
>+
> /*
>  * dev_ops for virtio, bare necessities for basic operation
>  */
>@@ -664,6 +675,7 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
>   .promiscuous_disable = virtio_dev_promiscuous_disable,
>   .allmulticast_enable = virtio_dev_allmulticast_enable,
>   .allmulticast_disable= virtio_dev_allmulticast_disable,
>+  .mtu_set = virtio_mtu_set,
>
>   .dev_infos_get   = virtio_dev_info_get,
>   .stats_get   = virtio_dev_stats_get,
>--
>
>--
>Regards,
>Souvik
>
>-Original Message-
>From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
>Sent: Friday, September 9, 2016 3:00 AM
>To: Dey, Souvik 
>Cc: dev at dpdk.org; stephen at networkplumber.org
>Subject: Re: [PATCH v4]net/virtio: add mtu set in virtio
>
>On Wed, Sep 07, 2016 at 04:21:30AM +, Dey, Souvik wrote:
>> Hi Liu,
>>  Submitted the version 4 of the patch as you suggested ,
>
>Your patch is looking much better. But not really, you ignored few of my 
>comments.
>
>> and have removed the Reviewed by line.
>> I have still kept the function definition as to follow the same suit as we 
>> have done for
>other eth_dev_ops.
>
>That's because most of the method implementions are after the reference, thus 
>the declaration
>is needed.
>
>For your case, I see no good reason to do that. BTW, if you disagree with my 
>comment, you
>shoud made a reply, instead of rushing to sending a new version.
>
>> --
>> Regards,
>> Souvik
>>
>> -Original Message-
>> From: Dey, Souvik
>> Sent: Wednesday, September 7, 2016 12:19 AM
>> To: dev at dpdk.org; stephen at networkplumber.org;
>> yuanhan.liu at linux.intel.com
>> Cc: Dey, Souvik 
>> Subject: [PATCH v4]net/virtio: add mtu set in virtio
>>
>>
>> Virtio interfaces should also support setting of mtu, as in case of cloud it 
>> is expected to
>have the consistent mtu across the infrastructure that the dhcp server sends 
>and not
>hardcoded to 1500(default).
>>
>> Changes in v4: Incorporated review comments.
>> Changes in v3: Corrected few style errors as reported by sys-stv.
>> Changes in v2: Incorporated review comments.
>
>DPDK prefers to put the change log to ...
>>
>> Signed-off-by: Souvik Dey 
>>
>> ---
>
>... here.
>
>So that they will be showed in mailing list (for review), but they will be 
>gone after apply.
>In another word, we don't like to see those change log in git history, but 
>we'd like to see
>them while review.
>
>>  drivers/net/virtio/virtio_ethdev.c | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/net/virtio/virtio_ethdev.c
>> b/drivers/net/virtio/virtio_ethdev.c
>> index 07d6449..da16ad4 100644
>> --- a/drivers/net/virtio/virtio_ethdev.c
>> +++ b/drivers/net/virtio/virtio_ethdev.c
>> @@ -92,6 +92,7 @@ static void virtio_mac_addr_add(struct rte_eth_dev *dev,  
>> static void
>virtio_mac_addr_remove(struct rte_eth_dev *dev, uint32_t index);  static void
>virtio_mac_addr_set(struct rte_eth_dev *dev,
>>  struct ether_addr *mac_addr);
>> +static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
>>
>>  static int virtio_dev_queue_stats_mapping_set(
>>  __rte_unused struct rte_eth_dev *eth_dev, @@ -652,6 +653,16 @@
>virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
>>  PMD_INIT_LOG(ERR, "Failed to disable allmulticast");  }
>>
>> +static int
>> +virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
>> +struct virtio_hw *hw = dev->data->dev_private;

[dpdk-dev] [RFC PATCH v2 0/5] add API's for VF management

[Thomas Monjalon]

2016-09-09 08:49, Pattan, Reshma:
> Hi Thomas and Ferruh,
> 
> Can you take a look and  provide comments on ixgbe driver and ethdev changes.

We could try.
But honestly we have a lot of work to do for DPDK, except reviews.
So I would appreciate to see more reviewers on ethdev stuff.

Volunteers are more than welcome!

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Yuanhan Liu]

On Wed, Sep 07, 2016 at 04:21:30AM +, Dey, Souvik wrote:
> Hi Liu,
>   Submitted the version 4 of the patch as you suggested ,

Your patch is looking much better. But not really, you ignored few of
my comments.

> and have removed the Reviewed by line.
> I have still kept the function definition as to follow the same suit as we 
> have done for other eth_dev_ops.

That's because most of the method implementions are after the reference,
thus the declaration is needed.

For your case, I see no good reason to do that. BTW, if you disagree
with my comment, you shoud made a reply, instead of rushing to sending
a new version.

> --
> Regards,
> Souvik
> 
> -Original Message-
> From: Dey, Souvik 
> Sent: Wednesday, September 7, 2016 12:19 AM
> To: dev at dpdk.org; stephen at networkplumber.org; yuanhan.liu at 
> linux.intel.com
> Cc: Dey, Souvik 
> Subject: [PATCH v4]net/virtio: add mtu set in virtio
> 
> 
> Virtio interfaces should also support setting of mtu, as in case of cloud it 
> is expected to have the consistent mtu across the infrastructure that the 
> dhcp server sends and not hardcoded to 1500(default).
> 
> Changes in v4: Incorporated review comments.
> Changes in v3: Corrected few style errors as reported by sys-stv.
> Changes in v2: Incorporated review comments.

DPDK prefers to put the change log to ...
> 
> Signed-off-by: Souvik Dey 
> 
> ---

... here.

So that they will be showed in mailing list (for review), but they will
be gone after apply. In another word, we don't like to see those change
log in git history, but we'd like to see them while review.

>  drivers/net/virtio/virtio_ethdev.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/net/virtio/virtio_ethdev.c 
> b/drivers/net/virtio/virtio_ethdev.c
> index 07d6449..da16ad4 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -92,6 +92,7 @@ static void virtio_mac_addr_add(struct rte_eth_dev *dev,  
> static void virtio_mac_addr_remove(struct rte_eth_dev *dev, uint32_t index);  
> static void virtio_mac_addr_set(struct rte_eth_dev *dev,
>   struct ether_addr *mac_addr);
> +static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
>  
>  static int virtio_dev_queue_stats_mapping_set(
>   __rte_unused struct rte_eth_dev *eth_dev, @@ -652,6 +653,16 @@ 
> virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
>   PMD_INIT_LOG(ERR, "Failed to disable allmulticast");  }
>  
> +static int
> +virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
> + struct virtio_hw *hw = dev->data->dev_private;
> + if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
> + PMD_INIT_LOG(ERR, "Mtu should be between 64 and 9728\n");

I still saw those numbers.

--yliu

[dpdk-dev] [PATCH] kni: unregister an unregisterd net_device could cause a kernel crash

[Thomas Monjalon]

2016-09-08 18:15, Ferruh Yigit:
> On 9/8/2016 5:44 PM, Stephen Hemminger wrote:
> 
> ...
> 
> > But then again the whole KNI driver fails completely when
> > running kernel style check.
> > 
> 
> Yes, it generates lots of warnings.
> I can fix them (excluding ethtool/*), that wouldn't take much time but
> how syntax only patches welcomed? Another concern is it trashes git blame.

You ask a question and give the answer ;)
I think it depends just on the balance of the pros/cons - to be evaluated.

[dpdk-dev] [PATCH] kni: unregister an unregisterd net_device could cause a kernel crash

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Friday, September 9, 2016 1:40 PM
> To: Yigit, Ferruh 
> Cc: Stephen Hemminger ; zhouyangchao
> ; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] kni: unregister an unregisterd net_device
> could cause a kernel crash
> 
> 2016-09-08 18:15, Ferruh Yigit:
> > On 9/8/2016 5:44 PM, Stephen Hemminger wrote:
> >
> > ...
> >
> > > But then again the whole KNI driver fails completely when running
> > > kernel style check.
> > >
> >
> > Yes, it generates lots of warnings.
> > I can fix them (excluding ethtool/*), that wouldn't take much time but
> > how syntax only patches welcomed? Another concern is it trashes git
> blame.
> 
> You ask a question and give the answer ;) I think it depends just on the
> balance of the pros/cons - to be evaluated.

Hi,

I think in general we would prefer to avoid any large scale code beautification 
since, as pointed out, it breaks the option to git blame.

However, in the case of the KNI code the main author in git is "Intel" so git 
blame doesn't tell you a lot. Also, Ferruh is the maintainer, has made most of 
the recent changes, and is actively maintaining/improving it. So I think if the 
syntax fix came from him it would be okay. At least it would allow us to apply 
the checkpatch checks.


John

[dpdk-dev] [PATCH 2/3] net/virtio_user: fix wrong sequence of messages

[Yuanhan Liu]

On Fri, Sep 09, 2016 at 02:24:20PM +0800, Tan, Jianfeng wrote:
> 
> 
> On 9/9/2016 2:03 PM, Yuanhan Liu wrote:
> >>GET_PROTOCOL_FEATURES
> >>is not supported yet. I see those features in PROTOCOL_FEATURES is for live
> >>migration (right?).
> >Not exactly. PROTOCOL_FEATURES was firstly introduced while MQ was
> >enabled. Thus it's no wonder MQ is the first protocol feature vhost
> >user supports:
> >
> > [yliu at yliu-dev ~/dpdk]$ gg PROTOCOL_F_ lib/librte_vhost/
> > lib/librte_vhost/vhost_user.h:46:#define VHOST_USER_PROTOCOL_F_MQ 0
> > lib/librte_vhost/vhost_user.h:47:#define 
> > VHOST_USER_PROTOCOL_F_LOG_SHMFD 1
> > lib/librte_vhost/vhost_user.h:48:#define VHOST_USER_PROTOCOL_F_RARP 2
> >
> > --yliu
> 
> OK, I got it. The maximum of queue pair number is now a parameter of
> virtio_user, but we need to depend on PROTOCOL_FEATURES (further,
> VHOST_USER_GET_QUEUE_NUM) to maximum queue pair number that vhost can
> support.
> 
> Just wonder why not QEMU depends on (1ULL << VIRTIO_NET_F_MQ) inside
> features to do that?

VIRTIO_NET_F_MQ belongs to virtio spec, while VHOST_USER_PROTOCOL_F_MQ
belongs to vhost-user spec.

--yliu

[dpdk-dev] [PATCH 2/3] net/virtio_user: fix wrong sequence of messages

[Tan, Jianfeng]

On 9/9/2016 2:03 PM, Yuanhan Liu wrote:
>> GET_PROTOCOL_FEATURES
>> is not supported yet. I see those features in PROTOCOL_FEATURES is for live
>> migration (right?).
> Not exactly. PROTOCOL_FEATURES was firstly introduced while MQ was
> enabled. Thus it's no wonder MQ is the first protocol feature vhost
> user supports:
>
>  [yliu at yliu-dev ~/dpdk]$ gg PROTOCOL_F_ lib/librte_vhost/
>  lib/librte_vhost/vhost_user.h:46:#define VHOST_USER_PROTOCOL_F_MQ 0
>  lib/librte_vhost/vhost_user.h:47:#define VHOST_USER_PROTOCOL_F_LOG_SHMFD 
> 1
>  lib/librte_vhost/vhost_user.h:48:#define VHOST_USER_PROTOCOL_F_RARP 2
>
>   --yliu

OK, I got it. The maximum of queue pair number is now a parameter of 
virtio_user, but we need to depend on PROTOCOL_FEATURES (further, 
VHOST_USER_GET_QUEUE_NUM) to maximum queue pair number that vhost can 
support.

Just wonder why not QEMU depends on (1ULL << VIRTIO_NET_F_MQ) inside 
features to do that?

Thanks,
Jianfeng

>
>> Assuming that, anyone using container/process now
>> enables live migration so far? I don't think so.
>>
>> Thanks,
>> Jianfeng
>>
>>
>>> --yliu

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Dey, Souvik]

Hi Liu,

Yes agreed your comment. I will definitely remove the declaration as it is not 
really required. 
 So the latest patch will look like this . Yes I did rush a bit to submit the 
patch last will correct my suite. So sending the patch in a reply if we have 
more comments we can take a look and they re-submit the final reviewed patch. 
Thanks for the help though. 

---
 drivers/net/virtio/virtio_ethdev.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 07d6449..da16ad4 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c

+static int
+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
+   PMD_INIT_LOG(ERR, "Mtu should be between 64 and 9728\n");
+   return -EINVAL;
+   }
+   return 0;
+}
+
 /*
  * dev_ops for virtio, bare necessities for basic operation
  */
@@ -664,6 +675,7 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
.promiscuous_disable = virtio_dev_promiscuous_disable,
.allmulticast_enable = virtio_dev_allmulticast_enable,
.allmulticast_disable= virtio_dev_allmulticast_disable,
+   .mtu_set = virtio_mtu_set,

.dev_infos_get   = virtio_dev_info_get,
.stats_get   = virtio_dev_stats_get,
--

--
Regards,
Souvik

-Original Message-
From: Yuanhan Liu [mailto:yuanhan@linux.intel.com] 
Sent: Friday, September 9, 2016 3:00 AM
To: Dey, Souvik 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: Re: [PATCH v4]net/virtio: add mtu set in virtio

On Wed, Sep 07, 2016 at 04:21:30AM +, Dey, Souvik wrote:
> Hi Liu,
>   Submitted the version 4 of the patch as you suggested ,

Your patch is looking much better. But not really, you ignored few of my 
comments.

> and have removed the Reviewed by line.
> I have still kept the function definition as to follow the same suit as we 
> have done for other eth_dev_ops.

That's because most of the method implementions are after the reference, thus 
the declaration is needed.

For your case, I see no good reason to do that. BTW, if you disagree with my 
comment, you shoud made a reply, instead of rushing to sending a new version.

> --
> Regards,
> Souvik
> 
> -Original Message-
> From: Dey, Souvik
> Sent: Wednesday, September 7, 2016 12:19 AM
> To: dev at dpdk.org; stephen at networkplumber.org; 
> yuanhan.liu at linux.intel.com
> Cc: Dey, Souvik 
> Subject: [PATCH v4]net/virtio: add mtu set in virtio
> 
> 
> Virtio interfaces should also support setting of mtu, as in case of cloud it 
> is expected to have the consistent mtu across the infrastructure that the 
> dhcp server sends and not hardcoded to 1500(default).
> 
> Changes in v4: Incorporated review comments.
> Changes in v3: Corrected few style errors as reported by sys-stv.
> Changes in v2: Incorporated review comments.

DPDK prefers to put the change log to ...
> 
> Signed-off-by: Souvik Dey 
> 
> ---

... here.

So that they will be showed in mailing list (for review), but they will be gone 
after apply. In another word, we don't like to see those change log in git 
history, but we'd like to see them while review.

>  drivers/net/virtio/virtio_ethdev.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/net/virtio/virtio_ethdev.c 
> b/drivers/net/virtio/virtio_ethdev.c
> index 07d6449..da16ad4 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -92,6 +92,7 @@ static void virtio_mac_addr_add(struct rte_eth_dev *dev,  
> static void virtio_mac_addr_remove(struct rte_eth_dev *dev, uint32_t index);  
> static void virtio_mac_addr_set(struct rte_eth_dev *dev,
>   struct ether_addr *mac_addr);
> +static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
>  
>  static int virtio_dev_queue_stats_mapping_set(
>   __rte_unused struct rte_eth_dev *eth_dev, @@ -652,6 +653,16 @@ 
> virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
>   PMD_INIT_LOG(ERR, "Failed to disable allmulticast");  }
>  
> +static int
> +virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
> + struct virtio_hw *hw = dev->data->dev_private;
> + if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
> + PMD_INIT_LOG(ERR, "Mtu should be between 64 and 9728\n");

I still saw those numbers.

--yliu

[dpdk-dev] [PATCH v3 15/15] eal/crypto: Support rte_soc_driver/device for cryptodev

[Shreyansh Jain]

- rte_cryptodev_driver/rte_cryptodev_dev embeds rte_soc_driver/device for
  linking SoC PMDs to crypto devices.
- Add probe and remove functions linked

Signed-off-by: Hemant Agrawal 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_cryptodev/rte_cryptodev.c   | 122 -
 lib/librte_cryptodev/rte_cryptodev.h   |   3 +
 lib/librte_cryptodev/rte_cryptodev_pmd.h   |  18 +++-
 lib/librte_cryptodev/rte_cryptodev_version.map |   3 +
 4 files changed, 141 insertions(+), 5 deletions(-)

diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index 2e17169..43e8685 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -423,7 +423,8 @@ rte_cryptodev_pci_probe(struct rte_pci_driver *pci_drv,

int retval;

-   cryptodrv = (struct rte_cryptodev_driver *)pci_drv;
+   cryptodrv = container_of(pci_drv, struct rte_cryptodev_driver,
+pci_drv);
if (cryptodrv == NULL)
return -ENODEV;

@@ -490,7 +491,8 @@ rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev)
if (cryptodev == NULL)
return -ENODEV;

-   cryptodrv = (const struct rte_cryptodev_driver *)pci_dev->driver;
+   cryptodrv = container_of(pci_dev->driver, struct rte_cryptodev_driver,
+pci_drv);
if (cryptodrv == NULL)
return -ENODEV;

@@ -514,6 +516,111 @@ rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev)
return 0;
 }

+
+int
+rte_cryptodev_soc_probe(struct rte_soc_driver *soc_drv,
+ struct rte_soc_device *soc_dev)
+{
+   struct rte_cryptodev_driver *cryptodrv;
+   struct rte_cryptodev *cryptodev;
+
+   char cryptodev_name[RTE_CRYPTODEV_NAME_MAX_LEN];
+
+   int retval;
+
+   cryptodrv = container_of(soc_drv, struct rte_cryptodev_driver,
+soc_drv);
+
+   rte_eal_soc_device_name(&soc_dev->addr, cryptodev_name,
+   sizeof(cryptodev_name));
+
+   cryptodev = rte_cryptodev_pmd_allocate(cryptodev_name,
+  rte_socket_id());
+   if (cryptodev == NULL)
+   return -ENOMEM;
+
+
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+   cryptodev->data->dev_private =
+   rte_zmalloc_socket(
+   "cryptodev private structure",
+   cryptodrv->dev_private_size,
+   RTE_CACHE_LINE_SIZE,
+   rte_socket_id());
+
+   if (cryptodev->data->dev_private == NULL)
+   rte_panic("Cannot allocate memzone for private "
+   "device data");
+   }
+
+   cryptodev->soc_dev = soc_dev;
+   cryptodev->driver = cryptodrv;
+
+   /* init user callbacks */
+   TAILQ_INIT(&(cryptodev->link_intr_cbs));
+
+   /* Invoke PMD device initialization function */
+   retval = (*cryptodrv->cryptodev_init)(cryptodrv, cryptodev);
+   if (retval == 0)
+   return 0;
+
+   CDEV_LOG_ERR("driver %s: cryptodev_init(%s) failed\n",
+   soc_drv->driver.name,
+   soc_dev->addr.name);
+
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+   rte_free(cryptodev->data->dev_private);
+
+   cryptodev->attached = RTE_CRYPTODEV_DETACHED;
+   cryptodev_globals.nb_devs--;
+
+   return -ENXIO;
+}
+
+int
+rte_cryptodev_soc_remove(struct rte_soc_device *soc_dev)
+{
+   const struct rte_cryptodev_driver *cryptodrv;
+   struct rte_cryptodev *cryptodev;
+   char cryptodev_name[RTE_CRYPTODEV_NAME_MAX_LEN];
+   int ret;
+
+   if (soc_dev == NULL)
+   return -EINVAL;
+
+   rte_eal_soc_device_name(&soc_dev->addr, cryptodev_name,
+   sizeof(cryptodev_name));
+
+   cryptodev = rte_cryptodev_pmd_get_named_dev(cryptodev_name);
+   if (cryptodev == NULL)
+   return -ENODEV;
+
+   cryptodrv = container_of(soc_dev->driver,
+   struct rte_cryptodev_driver, soc_drv);
+   if (cryptodrv == NULL)
+   return -ENODEV;
+
+   /* Invoke PMD device uninit function */
+   if (*cryptodrv->cryptodev_uninit) {
+   ret = (*cryptodrv->cryptodev_uninit)(cryptodrv, cryptodev);
+   if (ret)
+   return ret;
+   }
+
+   /* free crypto device */
+   rte_cryptodev_pmd_release_device(cryptodev);
+
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+   rte_free(cryptodev->data->dev_private);
+
+   cryptodev->pci_dev = NULL;
+   cryptodev->soc_dev = NULL;
+   cryptodev->driver = NULL;
+   cryptodev->data = NULL;
+
+   return 0;
+}
+
 uint16_

[dpdk-dev] [PATCH v3 14/15] ether: Support rte_soc_driver/device for etherdev

[Shreyansh Jain]

- eth_driver/rte_eth_dev embeds rte_soc_driver/device for relating SoC
  PMDs to ethernet devices.
- Add probe and remove functions linked to eth_dev_init/uninit

Signed-off-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
Signed-off-by: Hemant Agrawal 
---
 lib/librte_ether/rte_ethdev.c | 129 ++
 lib/librte_ether/rte_ethdev.h |  31 ++
 2 files changed, 160 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 4fa65ca..b57d7b2 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -326,6 +326,101 @@ rte_eth_dev_pci_remove(struct rte_pci_device *pci_dev)
 }

 int
+rte_eth_dev_soc_probe(struct rte_soc_driver *soc_drv,
+ struct rte_soc_device *soc_dev)
+{
+   struct eth_driver*eth_drv;
+   struct rte_eth_dev *eth_dev;
+   char ethdev_name[RTE_ETH_NAME_MAX_LEN];
+
+   int diag;
+
+   eth_drv = container_of(soc_drv, struct eth_driver, soc_drv);
+
+   rte_eal_soc_device_name(&soc_dev->addr, ethdev_name,
+   sizeof(ethdev_name));
+
+   eth_dev = rte_eth_dev_allocate(ethdev_name);
+   if (eth_dev == NULL)
+   return -ENOMEM;
+
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+   eth_dev->data->dev_private = rte_zmalloc(
+ "ethdev private structure",
+ eth_drv->dev_private_size,
+ RTE_CACHE_LINE_SIZE);
+   if (eth_dev->data->dev_private == NULL)
+   rte_panic("Cannot allocate memzone for private port "
+ "data\n");
+   }
+   eth_dev->soc_dev = soc_dev;
+   eth_dev->driver = eth_drv;
+   eth_dev->data->rx_mbuf_alloc_failed = 0;
+
+   /* init user callbacks */
+   TAILQ_INIT(&(eth_dev->link_intr_cbs));
+
+   /*
+* Set the default MTU.
+*/
+   eth_dev->data->mtu = ETHER_MTU;
+
+   /* Invoke PMD device initialization function */
+   diag = (*eth_drv->eth_dev_init)(eth_dev);
+   if (diag == 0)
+   return 0;
+
+   RTE_PMD_DEBUG_TRACE("driver %s: eth_dev_init(%s) failed\n",
+   soc_drv->driver.name,
+   soc_dev->addr.name);
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+   rte_free(eth_dev->data->dev_private);
+   rte_eth_dev_release_port(eth_dev);
+   return diag;
+}
+
+int
+rte_eth_dev_soc_remove(struct rte_soc_device *soc_dev)
+{
+   const struct eth_driver *eth_drv;
+   struct rte_eth_dev *eth_dev;
+   char ethdev_name[RTE_ETH_NAME_MAX_LEN];
+   int ret;
+
+   if (soc_dev == NULL)
+   return -EINVAL;
+
+   rte_eal_soc_device_name(&soc_dev->addr, ethdev_name,
+   sizeof(ethdev_name));
+
+   eth_dev = rte_eth_dev_allocated(ethdev_name);
+   if (eth_dev == NULL)
+   return -ENODEV;
+
+   eth_drv = container_of(soc_dev->driver, struct eth_driver, soc_drv);
+
+   /* Invoke PMD device uninit function */
+   if (*eth_drv->eth_dev_uninit) {
+   ret = (*eth_drv->eth_dev_uninit)(eth_dev);
+   if (ret)
+   return ret;
+   }
+
+   /* free ether device */
+   rte_eth_dev_release_port(eth_dev);
+
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+   rte_free(eth_dev->data->dev_private);
+
+   eth_dev->soc_dev = NULL;
+   eth_dev->driver = NULL;
+   eth_dev->data = NULL;
+
+   return 0;
+}
+
+
+int
 rte_eth_dev_is_valid_port(uint8_t port_id)
 {
if (port_id >= RTE_MAX_ETHPORTS ||
@@ -1555,6 +1650,7 @@ rte_eth_dev_info_get(uint8_t port_id, struct 
rte_eth_dev_info *dev_info)
RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
(*dev->dev_ops->dev_infos_get)(dev, dev_info);
dev_info->pci_dev = dev->pci_dev;
+   dev_info->soc_dev = dev->soc_dev;
dev_info->driver_name = dev->data->drv_name;
dev_info->nb_rx_queues = dev->data->nb_rx_queues;
dev_info->nb_tx_queues = dev->data->nb_tx_queues;
@@ -2530,8 +2626,13 @@ static inline
 struct rte_intr_handle *eth_dev_get_intr_handle(struct rte_eth_dev *dev)
 {
if (dev->pci_dev) {
+   RTE_VERIFY(dev->soc_dev == NULL);
return &dev->pci_dev->intr_handle;
}
+   if (dev->soc_dev) {
+   RTE_VERIFY(dev->pci_dev == NULL);
+   return &dev->soc_dev->intr_handle;
+   }

RTE_VERIFY(0);
return NULL;
@@ -2572,9 +2673,15 @@ static inline
 const char *eth_dev_get_driver_name(const struct rte_eth_dev *dev)
 {
if (dev->pci_dev) {
+   RTE_VERIFY(dev->soc_dev == NULL);
return dev->driver->pci_drv.driver.name;
}

+   if (dev->soc_dev) {
+   RTE_VERIFY(dev->pci_dev == NULL);
+   return dev->driver->soc_dr

[dpdk-dev] [PATCH v3 13/15] ether: extract function eth_dev_get_driver_name

[Shreyansh Jain]

Signed-off-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
Signed-off-by: Hemant Agrawal 
---
 lib/librte_ether/rte_ethdev.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 104ea4a..4fa65ca 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -2568,6 +2568,17 @@ rte_eth_dev_rx_intr_ctl(uint8_t port_id, int epfd, int 
op, void *data)
return 0;
 }

+static inline
+const char *eth_dev_get_driver_name(const struct rte_eth_dev *dev)
+{
+   if (dev->pci_dev) {
+   return dev->driver->pci_drv.driver.name;
+   }
+
+   RTE_VERIFY(0);
+   return NULL;
+}
+
 const struct rte_memzone *
 rte_eth_dma_zone_reserve(const struct rte_eth_dev *dev, const char *ring_name,
 uint16_t queue_id, size_t size, unsigned align,
@@ -2575,9 +2586,11 @@ rte_eth_dma_zone_reserve(const struct rte_eth_dev *dev, 
const char *ring_name,
 {
char z_name[RTE_MEMZONE_NAMESIZE];
const struct rte_memzone *mz;
+   const char *drv_name;

+   drv_name = eth_dev_get_driver_name(dev);
snprintf(z_name, sizeof(z_name), "%s_%s_%d_%d",
-dev->driver->pci_drv.driver.name, ring_name,
+drv_name, ring_name,
 dev->data->port_id, queue_id);

mz = rte_memzone_lookup(z_name);
-- 
2.7.4

[dpdk-dev] [PATCH v3 12/15] ether: extract function eth_dev_get_intr_handle

[Shreyansh Jain]

We abstract access to the intr_handle here as we want to get
it either from the pci_dev or soc_dev.

Signed-off-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
Signed-off-by: Hemant Agrawal 
---
 lib/librte_ether/rte_ethdev.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index e9f5467..104ea4a 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -2526,6 +2526,17 @@ _rte_eth_dev_callback_process(struct rte_eth_dev *dev,
rte_spinlock_unlock(&rte_eth_dev_cb_lock);
 }

+static inline
+struct rte_intr_handle *eth_dev_get_intr_handle(struct rte_eth_dev *dev)
+{
+   if (dev->pci_dev) {
+   return &dev->pci_dev->intr_handle;
+   }
+
+   RTE_VERIFY(0);
+   return NULL;
+}
+
 int
 rte_eth_dev_rx_intr_ctl(uint8_t port_id, int epfd, int op, void *data)
 {
@@ -2538,7 +2549,7 @@ rte_eth_dev_rx_intr_ctl(uint8_t port_id, int epfd, int 
op, void *data)
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);

dev = &rte_eth_devices[port_id];
-   intr_handle = &dev->pci_dev->intr_handle;
+   intr_handle = eth_dev_get_intr_handle(dev);
if (!intr_handle->intr_vec) {
RTE_PMD_DEBUG_TRACE("RX Intr vector unset\n");
return -EPERM;
@@ -2598,7 +2609,7 @@ rte_eth_dev_rx_intr_ctl_q(uint8_t port_id, uint16_t 
queue_id,
return -EINVAL;
}

-   intr_handle = &dev->pci_dev->intr_handle;
+   intr_handle = eth_dev_get_intr_handle(dev);
if (!intr_handle->intr_vec) {
RTE_PMD_DEBUG_TRACE("RX Intr vector unset\n");
return -EPERM;
-- 
2.7.4

[dpdk-dev] [PATCH v3 11/15] ether: verify we copy info from a PCI device

[Shreyansh Jain]

Now that different types of ethdev exist, check for presence of PCI dev
while copying out the info.
Similar would be done for SoC.

Signed-off-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
Signed-off-by: Hemant Agrawal 
---
 lib/librte_ether/rte_ethdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index b10d985..e9f5467 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -3200,6 +3200,8 @@ rte_eth_copy_pci_info(struct rte_eth_dev *eth_dev, struct 
rte_pci_device *pci_de
return;
}

+   RTE_VERIFY(eth_dev->pci_dev != NULL);
+
eth_dev->data->dev_flags = 0;
if (pci_dev->driver->drv_flags & RTE_PCI_DRV_INTR_LSC)
eth_dev->data->dev_flags |= RTE_ETH_DEV_INTR_LSC;
-- 
2.7.4

[dpdk-dev] [PATCH v3 10/15] ether: utilize container_of for pci_drv

[Shreyansh Jain]

It is not necessary to place the rte_pci_driver at the beginning
of the rte_eth_dev struct anymore as we use the container_of macro
to get the parent pointer.

Signed-off-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
Signed-off-by: Hemant Agrawal 
---
 lib/librte_ether/rte_ethdev.c | 4 ++--
 lib/librte_ether/rte_ethdev.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index d54ec9e..b10d985 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -242,7 +242,7 @@ rte_eth_dev_pci_probe(struct rte_pci_driver *pci_drv,

int diag;

-   eth_drv = (struct eth_driver *)pci_drv;
+   eth_drv = container_of(pci_drv, struct eth_driver, pci_drv);

rte_eal_pci_device_name(&pci_dev->addr, ethdev_name,
sizeof(ethdev_name));
@@ -303,7 +303,7 @@ rte_eth_dev_pci_remove(struct rte_pci_device *pci_dev)
if (eth_dev == NULL)
return -ENODEV;

-   eth_drv = (const struct eth_driver *)pci_dev->driver;
+   eth_drv = container_of(pci_dev->driver, struct eth_driver, pci_drv);

/* Invoke PMD device uninit function */
if (*eth_drv->eth_dev_uninit) {
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 2a697ec..8320dc4 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1842,7 +1842,7 @@ typedef int (*eth_dev_uninit_t)(struct rte_eth_dev 
*eth_dev);
  * Each Ethernet driver acts as a PCI driver and is represented by a generic
  * *eth_driver* structure that holds:
  *
- * - An *rte_pci_driver* structure (which must be the first field).
+ * - An *rte_pci_driver* structure.
  *
  * - The *eth_dev_init* function invoked for each matching PCI device.
  *
-- 
2.7.4

[dpdk-dev] [PATCH v3 09/15] eal/soc: add intr_handle

[Shreyansh Jain]

Signed-off-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
Signed-off-by: Hemant Agrawal 
---
 lib/librte_eal/common/include/rte_soc.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/librte_eal/common/include/rte_soc.h 
b/lib/librte_eal/common/include/rte_soc.h
index 93d3a2f..aa4c678 100644
--- a/lib/librte_eal/common/include/rte_soc.h
+++ b/lib/librte_eal/common/include/rte_soc.h
@@ -53,6 +53,7 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 

 extern struct soc_driver_list soc_driver_list;
 /**< Global list of SoC Drivers */
@@ -81,6 +82,7 @@ struct rte_soc_device {
struct rte_device device;   /**< Inherit code device */
struct rte_soc_addr addr;   /**< SoC device Location */
struct rte_soc_id *id;  /**< SoC device ID list */
+   struct rte_intr_handle intr_handle; /**< Interrupt handle */
struct rte_soc_driver *driver;  /**< Associated driver */
 };

-- 
2.7.4

[dpdk-dev] [PATCH v3 08/15] eal/soc: add drv_flags

[Shreyansh Jain]

The flags are copied from the PCI ones. They should be refactorized into a
general set of flags in the future.

Signed-off-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
Signed-off-by: Hemant Agrawal 
---
 lib/librte_eal/common/include/rte_soc.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lib/librte_eal/common/include/rte_soc.h 
b/lib/librte_eal/common/include/rte_soc.h
index 0bbef7d..93d3a2f 100644
--- a/lib/librte_eal/common/include/rte_soc.h
+++ b/lib/librte_eal/common/include/rte_soc.h
@@ -117,8 +117,18 @@ struct rte_soc_driver {
soc_scan_t *scan_fn;   /**< Callback for scanning SoC bus*/
soc_match_t *match_fn; /**< Callback to match dev<->drv */
const struct rte_soc_id *id_table; /**< ID table, NULL terminated */
+   uint32_t drv_flags;/**< Control handling of device */
 };

+/** Device needs to map its resources by EAL */
+#define RTE_SOC_DRV_NEED_MAPPING 0x0001
+/** Device needs to be unbound even if no module is provieded */
+#define RTE_SOC_DRV_FORCE_UNBIND 0x0004
+/** Device driver supports link state interrupt */
+#define RTE_SOC_DRV_INTR_LSC0x0008
+/** Device driver supports detaching capability */
+#define RTE_SOC_DRV_DETACHABLE  0x0010
+
 /**
  * Utility function to write a SoC device name, this device name can later be
  * used to retrieve the corresponding rte_soc_addr using above functions.
-- 
2.7.4

[dpdk-dev] [PATCH v3 07/15] eal/soc: extend and utilize devargs

[Shreyansh Jain]

It is assumed that SoC Devices provided on command line are prefixed with
"soc:". This patch adds parse and attach support for such devices.

Signed-off-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
Signed-off-by: Hemant Agrawal 
---
 lib/librte_eal/common/eal_common_dev.c  | 27 ++
 lib/librte_eal/common/eal_common_devargs.c  | 17 +
 lib/librte_eal/common/eal_common_soc.c  | 55 ++---
 lib/librte_eal/common/include/rte_devargs.h |  8 +
 lib/librte_eal/common/include/rte_soc.h | 24 +
 5 files changed, 119 insertions(+), 12 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_dev.c 
b/lib/librte_eal/common/eal_common_dev.c
index d1f0ad8..fbc4443 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -106,17 +106,23 @@ rte_eal_dev_init(void)

 int rte_eal_dev_attach(const char *name, const char *devargs)
 {
-   struct rte_pci_addr addr;
+   struct rte_soc_addr soc_addr;
+   struct rte_pci_addr pci_addr;

if (name == NULL || devargs == NULL) {
RTE_LOG(ERR, EAL, "Invalid device or arguments provided\n");
return -EINVAL;
}

-   if (eal_parse_pci_DomBDF(name, &addr) == 0) {
-   if (rte_eal_pci_probe_one(&addr) < 0)
+   memset(&soc_addr, 0, sizeof(soc_addr));
+   if (rte_eal_parse_soc_spec(name, &soc_addr) == 0) {
+   if (rte_eal_soc_probe_one(&soc_addr) < 0) {
+   free(soc_addr.name);
+   goto err;
+   }
+   } else if (eal_parse_pci_DomBDF(name, &pci_addr) == 0) {
+   if (rte_eal_pci_probe_one(&pci_addr) < 0)
goto err;
-
} else {
if (rte_eal_vdev_init(name, devargs))
goto err;
@@ -131,15 +137,22 @@ err:

 int rte_eal_dev_detach(const char *name)
 {
-   struct rte_pci_addr addr;
+   struct rte_soc_addr soc_addr;
+   struct rte_pci_addr pci_addr;

if (name == NULL) {
RTE_LOG(ERR, EAL, "Invalid device provided.\n");
return -EINVAL;
}

-   if (eal_parse_pci_DomBDF(name, &addr) == 0) {
-   if (rte_eal_pci_detach(&addr) < 0)
+   memset(&soc_addr, 0, sizeof(soc_addr));
+   if (rte_eal_parse_soc_spec(name, &soc_addr) == 0) {
+   if (rte_eal_soc_detach(&soc_addr) < 0) {
+   free(soc_addr.name);
+   goto err;
+   }
+   } else if (eal_parse_pci_DomBDF(name, &pci_addr) == 0) {
+   if (rte_eal_pci_detach(&pci_addr) < 0)
goto err;
} else {
if (rte_eal_vdev_uninit(name))
diff --git a/lib/librte_eal/common/eal_common_devargs.c 
b/lib/librte_eal/common/eal_common_devargs.c
index e403717..e1dae1a 100644
--- a/lib/librte_eal/common/eal_common_devargs.c
+++ b/lib/librte_eal/common/eal_common_devargs.c
@@ -41,6 +41,7 @@
 #include 

 #include 
+#include 
 #include 
 #include "eal_private.h"

@@ -105,6 +106,14 @@ rte_eal_devargs_add(enum rte_devtype devtype, const char 
*devargs_str)
goto fail;

break;
+
+   case RTE_DEVTYPE_WHITELISTED_SOC:
+   case RTE_DEVTYPE_BLACKLISTED_SOC:
+   /* try to parse soc device with prefix "soc:" */
+   if (rte_eal_parse_soc_spec(buf, &devargs->soc.addr) != 0)
+   goto fail;
+   break;
+
case RTE_DEVTYPE_VIRTUAL:
/* save driver name */
ret = snprintf(devargs->virt.drv_name,
@@ -166,6 +175,14 @@ rte_eal_devargs_dump(FILE *f)
   devargs->pci.addr.devid,
   devargs->pci.addr.function,
   devargs->args);
+   else if (devargs->type == RTE_DEVTYPE_WHITELISTED_SOC)
+   fprintf(f, "  SoC whitelist %s %s\n",
+  devargs->soc.addr.name,
+  devargs->soc.addr.fdt_path);
+   else if (devargs->type == RTE_DEVTYPE_BLACKLISTED_SOC)
+   fprintf(f, "  SoC blacklist %s %s\n",
+  devargs->soc.addr.name,
+  devargs->soc.addr.fdt_path);
else if (devargs->type == RTE_DEVTYPE_VIRTUAL)
fprintf(f, "  VIRTUAL %s %s\n",
   devargs->virt.drv_name,
diff --git a/lib/librte_eal/common/eal_common_soc.c 
b/lib/librte_eal/common/eal_common_soc.c
index bb87a67..e9d413a 100644
--- a/lib/librte_eal/common/eal_common_soc.c
+++ b/lib/librte_eal/common/eal_common_soc.c
@@ -37,6 +37,8 @@

 #include 
 #include 
+#include 
+#include 
 #include 

 #include "eal_private.h"
@@ -71,6 +73,21 @@ rte_eal_soc_match(struct rte_soc_driver *drv, struct 
rte_soc_device *dev)
 }


+static struct rte_devargs *soc_devargs_lookup(struct r

[dpdk-dev] [PATCH v3 06/15] eal/soc: implement probing of drivers

[Shreyansh Jain]

Each SoC PMD registers a set of callback for scanning its own bus/infra and
matching devices to drivers when probe is called.
This patch introduces the infra for calls to SoC scan on rte_eal_soc_init()
and match on rte_eal_soc_probe().

Patch also adds test case for scan and probe.

Signed-off-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
Signed-off-by: Hemant Agrawal 
---
 app/test/test_soc.c | 138 ++-
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |   4 +
 lib/librte_eal/common/eal_common_soc.c  | 215 
 lib/librte_eal/common/include/rte_soc.h |  51 ++
 lib/librte_eal/linuxapp/eal/eal.c   |   5 +
 lib/librte_eal/linuxapp/eal/eal_soc.c   |  16 ++
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |   4 +
 7 files changed, 432 insertions(+), 1 deletion(-)

diff --git a/app/test/test_soc.c b/app/test/test_soc.c
index ac03e64..d2b9462 100644
--- a/app/test/test_soc.c
+++ b/app/test/test_soc.c
@@ -87,14 +87,45 @@ static int test_compare_addr(void)
  */
 struct test_wrapper {
struct rte_soc_driver soc_drv;
+   struct rte_soc_device soc_dev;
 };

+static int empty_pmd0_devinit(struct rte_soc_driver *drv,
+ struct rte_soc_device *dev);
+static int empty_pmd0_devuninit(struct rte_soc_device *dev);
+static void test_soc_scan_dev0_cb(void);
+static int test_soc_match_dev0_cb(struct rte_soc_driver *drv,
+ struct rte_soc_device *dev);
+static void test_soc_scan_dev1_cb(void);
+static int test_soc_match_dev1_cb(struct rte_soc_driver *drv,
+ struct rte_soc_device *dev);
+
+static int
+empty_pmd0_devinit(struct rte_soc_driver *drv __rte_unused,
+  struct rte_soc_device *dev __rte_unused)
+{
+   return 0;
+}
+
+static int
+empty_pmd0_devuninit(struct rte_soc_device *dev)
+{
+   /* Release the memory associated with dev->addr.name */
+   free(dev->addr.name);
+
+   return 0;
+}
+
 struct test_wrapper empty_pmd0 = {
.soc_drv = {
.driver = {
.name = "empty_pmd0"
},
-   },
+   .devinit = empty_pmd0_devinit,
+   .devuninit = empty_pmd0_devuninit,
+   .scan_fn = test_soc_scan_dev0_cb,
+   .match_fn = test_soc_match_dev0_cb,
+   }
 };

 struct test_wrapper empty_pmd1 = {
@@ -102,9 +133,54 @@ struct test_wrapper empty_pmd1 = {
.driver = {
.name = "empty_pmd1"
},
+   .scan_fn = test_soc_scan_dev1_cb,
+   .match_fn = test_soc_match_dev1_cb,
},
 };

+static void
+test_soc_scan_dev0_cb(void)
+{
+   /* SoC's scan would scan devices on its bus and add to
+* soc_device_list
+*/
+   empty_pmd0.soc_dev.addr.name = strdup("empty_pmd0_dev");
+
+   TAILQ_INSERT_TAIL(&soc_device_list, &empty_pmd0.soc_dev, next);
+}
+
+static int
+test_soc_match_dev0_cb(struct rte_soc_driver *drv __rte_unused,
+  struct rte_soc_device *dev)
+{
+   if (!dev->addr.name || strcmp(dev->addr.name, "empty_pmd0_dev"))
+   return 0;
+
+   return 1;
+}
+
+
+static void
+test_soc_scan_dev1_cb(void)
+{
+   /* SoC's scan would scan devices on its bus and add to
+* soc_device_list
+*/
+   empty_pmd0.soc_dev.addr.name = strdup("empty_pmd1_dev");
+
+   TAILQ_INSERT_TAIL(&soc_device_list, &empty_pmd1.soc_dev, next);
+}
+
+static int
+test_soc_match_dev1_cb(struct rte_soc_driver *drv __rte_unused,
+  struct rte_soc_device *dev)
+{
+   if (!dev->addr.name || strcmp(dev->addr.name, "empty_pmd1_dev"))
+   return 0;
+
+   return 1;
+}
+
 static int
 count_registered_socdrvs(void)
 {
@@ -148,13 +224,54 @@ test_register_unregister(void)
return 0;
 }

+/* Test Probe (scan and match) functionality */
+static int
+test_soc_init_and_probe(void)
+{
+   struct rte_soc_driver *drv;
+
+   /* Registering dummy drivers */
+   rte_eal_soc_register(&empty_pmd0.soc_drv);
+   rte_eal_soc_register(&empty_pmd1.soc_drv);
+   /* Assuming that test_register_unregister is working, not verifying
+* that drivers are indeed registered
+   */
+
+   /* rte_eal_soc_init is called by rte_eal_init, which in turn calls the
+* scan_fn of each driver.
+*/
+   TAILQ_FOREACH(drv, &soc_driver_list, next) {
+   if (drv && drv->scan_fn)
+   drv->scan_fn();
+   }
+
+   /* rte_eal_init() would perform other inits here */
+
+   /* Probe would link the SoC devices<=>drivers */
+   rte_eal_soc_probe();
+
+   /* Unregistering dummy drivers */
+   rte_eal_soc_unregister(&empty_pmd0.soc_drv);
+   rte_eal_soc_unregister(&empty_pmd1.soc_drv);
+
+   free(empty_pmd0.soc_dev.addr.name);
+
+   printf("%s has been successful\n"

[dpdk-dev] [PATCH v3 05/15] eal/soc: init SoC infra from EAL

[Shreyansh Jain]

Signed-off-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
Signed-off-by: Hemant Agrawal 
---
 lib/librte_eal/bsdapp/eal/Makefile|  1 +
 lib/librte_eal/bsdapp/eal/eal.c   |  4 +++
 lib/librte_eal/bsdapp/eal/eal_soc.c   | 46 
 lib/librte_eal/common/eal_private.h   | 10 +++
 lib/librte_eal/linuxapp/eal/Makefile  |  1 +
 lib/librte_eal/linuxapp/eal/eal.c |  3 ++
 lib/librte_eal/linuxapp/eal/eal_soc.c | 56 +++
 7 files changed, 121 insertions(+)
 create mode 100644 lib/librte_eal/bsdapp/eal/eal_soc.c
 create mode 100644 lib/librte_eal/linuxapp/eal/eal_soc.c

diff --git a/lib/librte_eal/bsdapp/eal/Makefile 
b/lib/librte_eal/bsdapp/eal/Makefile
index 5a3fc1d..cf4bf78 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -57,6 +57,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_hugepage_info.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_thread.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_log.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_pci.c
+SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_soc.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_debug.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_lcore.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_timer.c
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index a0c8f8c..7d8c3e8 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -64,6 +64,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -567,6 +568,9 @@ rte_eal_init(int argc, char **argv)
if (rte_eal_pci_init() < 0)
rte_panic("Cannot init PCI\n");

+   if (rte_eal_soc_init() < 0)
+   rte_panic("Cannot init SoC\n");
+
eal_check_mem_on_local_socket();

if (eal_plugins_init() < 0)
diff --git a/lib/librte_eal/bsdapp/eal/eal_soc.c 
b/lib/librte_eal/bsdapp/eal/eal_soc.c
new file mode 100644
index 000..cb297ff
--- /dev/null
+++ b/lib/librte_eal/bsdapp/eal/eal_soc.c
@@ -0,0 +1,46 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2016 RehiveTech. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of RehiveTech nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Init the SoC EAL subsystem */
+int
+rte_eal_soc_init(void)
+{
+   return 0;
+}
diff --git a/lib/librte_eal/common/eal_private.h 
b/lib/librte_eal/common/eal_private.h
index df6582d..ba8407d 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -130,6 +130,16 @@ int rte_eal_pci_init(void);
 struct rte_soc_driver;
 struct rte_soc_device;

+/**
+ * Init the SoC infra.
+ *
+ * This function is private to EAL.
+ *
+ * @return
+ *   0 on success, negative on error
+ */
+int rte_eal_soc_init(void);
+
 struct rte_pci_driver;
 struct rte_pci_device;

diff --git a/lib/librte_eal/linuxapp/eal/Makefile 
b/lib/librte_eal/linuxapp/eal/Makefile
index a520477..59e30fa 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -65,6 +65,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_vfio_mp_sync.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_pci.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_pci_uio.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_pci_vfio.c
+SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_soc.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_debug.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX

[dpdk-dev] [PATCH v3 04/15] eal: introduce --no-soc option

[Shreyansh Jain]

This option has the same meaning for the SoC infra as the --no-pci
for the PCI infra.

Signed-off-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
Signed-off-by: Hemant Agrawal 
---
 lib/librte_eal/common/eal_common_options.c | 5 +
 lib/librte_eal/common/eal_internal_cfg.h   | 1 +
 lib/librte_eal/common/eal_options.h| 2 ++
 3 files changed, 8 insertions(+)

diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
index 1a1bab3..d97cf0a 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -85,6 +85,7 @@ eal_long_options[] = {
{OPT_NO_HPET,   0, NULL, OPT_NO_HPET_NUM  },
{OPT_NO_HUGE,   0, NULL, OPT_NO_HUGE_NUM  },
{OPT_NO_PCI,0, NULL, OPT_NO_PCI_NUM   },
+   {OPT_NO_SOC,0, NULL, OPT_NO_SOC_NUM   },
{OPT_NO_SHCONF, 0, NULL, OPT_NO_SHCONF_NUM},
{OPT_PCI_BLACKLIST, 1, NULL, OPT_PCI_BLACKLIST_NUM},
{OPT_PCI_WHITELIST, 1, NULL, OPT_PCI_WHITELIST_NUM},
@@ -855,6 +856,10 @@ eal_parse_common_option(int opt, const char *optarg,
conf->no_pci = 1;
break;

+   case OPT_NO_SOC_NUM:
+   conf->no_soc = 1;
+   break;
+
case OPT_NO_HPET_NUM:
conf->no_hpet = 1;
break;
diff --git a/lib/librte_eal/common/eal_internal_cfg.h 
b/lib/librte_eal/common/eal_internal_cfg.h
index 5f1367e..3a98e94 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -67,6 +67,7 @@ struct internal_config {
unsigned hugepage_unlink; /**< true to unlink backing files */
volatile unsigned xen_dom0_support; /**< support app running on Xen 
Dom0*/
volatile unsigned no_pci; /**< true to disable PCI */
+   volatile unsigned no_soc; /**< true to disable SoC */
volatile unsigned no_hpet;/**< true to disable HPET */
volatile unsigned vmware_tsc_map; /**< true to use VMware TSC mapping

* instead of native TSC */
diff --git a/lib/librte_eal/common/eal_options.h 
b/lib/librte_eal/common/eal_options.h
index a881c62..ba1e704 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -69,6 +69,8 @@ enum {
OPT_NO_HUGE_NUM,
 #define OPT_NO_PCI"no-pci"
OPT_NO_PCI_NUM,
+#define OPT_NO_SOC"no-soc"
+   OPT_NO_SOC_NUM,
 #define OPT_NO_SHCONF "no-shconf"
OPT_NO_SHCONF_NUM,
 #define OPT_SOCKET_MEM"socket-mem"
-- 
2.7.4

[dpdk-dev] [PATCH v3 03/15] eal/soc: Implement SoC device list and dump

[Shreyansh Jain]

SoC devices would be linked in a separate list (from PCI). This is used for
probe function.
A helper for dumping the device list is added.

Signed-off-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
Signed-off-by: Hemant Agrawal 
---
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |  2 ++
 lib/librte_eal/common/eal_common_soc.c  | 34 +
 lib/librte_eal/common/include/rte_soc.h |  9 +++
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |  2 ++
 4 files changed, 47 insertions(+)

diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map 
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index cda8009..de38848 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -169,7 +169,9 @@ DPDK_16.11 {
rte_eal_dev_attach;
rte_eal_dev_detach;
soc_driver_list;
+   soc_device_list
rte_eal_soc_register;
rte_eal_soc_unregister;
+   rte_eal_soc_dump;

 } DPDK_16.07;
diff --git a/lib/librte_eal/common/eal_common_soc.c 
b/lib/librte_eal/common/eal_common_soc.c
index 56135ed..5dcddc5 100644
--- a/lib/librte_eal/common/eal_common_soc.c
+++ b/lib/librte_eal/common/eal_common_soc.c
@@ -31,6 +31,8 @@
  *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */

+#include 
+#include 
 #include 

 #include 
@@ -40,6 +42,38 @@
 /* Global SoC driver list */
 struct soc_driver_list soc_driver_list =
TAILQ_HEAD_INITIALIZER(soc_driver_list);
+struct soc_device_list soc_device_list =
+   TAILQ_HEAD_INITIALIZER(soc_device_list);
+
+/* dump one device */
+static int
+soc_dump_one_device(FILE *f, struct rte_soc_device *dev)
+{
+   int i;
+
+   fprintf(f, "%s", dev->addr.name);
+   fprintf(f, " - fdt_path: %s\n",
+   dev->addr.fdt_path ? dev->addr.fdt_path : "(none)");
+
+   for (i = 0; dev->id && dev->id[i].compatible; ++i)
+   fprintf(f, "   %s\n", dev->id[i].compatible);
+
+   return 0;
+}
+
+/* dump devices on the bus to an output stream */
+void
+rte_eal_soc_dump(FILE *f)
+{
+   struct rte_soc_device *dev = NULL;
+
+   if (!f)
+   return;
+
+   TAILQ_FOREACH(dev, &soc_device_list, next) {
+   soc_dump_one_device(f, dev);
+   }
+}

 /* register a driver */
 void
diff --git a/lib/librte_eal/common/include/rte_soc.h 
b/lib/librte_eal/common/include/rte_soc.h
index 16c5a1b..c6f98eb 100644
--- a/lib/librte_eal/common/include/rte_soc.h
+++ b/lib/librte_eal/common/include/rte_soc.h
@@ -56,8 +56,12 @@ extern "C" {

 extern struct soc_driver_list soc_driver_list;
 /**< Global list of SoC Drivers */
+extern struct soc_device_list soc_device_list;
+/**< Global list of SoC Devices */

 TAILQ_HEAD(soc_driver_list, rte_soc_driver); /**< SoC drivers in D-linked Q. */
+TAILQ_HEAD(soc_device_list, rte_soc_device); /**< SoC devices in D-linked Q. */
+

 struct rte_soc_id {
const char *compatible; /**< OF compatible specification */
@@ -142,6 +146,11 @@ rte_eal_compare_soc_addr(const struct rte_soc_addr *a0,
 }

 /**
+ * Dump discovered SoC devices.
+ */
+void rte_eal_soc_dump(FILE *f);
+
+/**
  * Register a SoC driver.
  */
 void rte_eal_soc_register(struct rte_soc_driver *driver);
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map 
b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index 66c1258..b9d1932 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -175,7 +175,9 @@ DPDK_16.11 {
rte_eal_vdrv_register;
rte_eal_vdrv_unregister;
soc_driver_list;
+   soc_device_list;
rte_eal_soc_register;
rte_eal_soc_unregister;
+   rte_eal_soc_dump;

 } DPDK_16.07;
-- 
2.7.4

[dpdk-dev] [PATCH v3 02/15] eal/soc: add rte_eal_soc_register/unregister logic

[Shreyansh Jain]

Registeration of a SoC driver through a helper DRIVER_REGISTER_SOC
(on the lines of DRIVER_REGISTER_PCI). soc_driver_list stores all the
registered drivers.

Test case has been introduced to verify the registration and
deregistration.

Signed-off-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
Signed-off-by: Hemant Agrawal 
---
 app/test/test_soc.c | 111 
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |   4 +
 lib/librte_eal/common/eal_common_soc.c  |  56 
 lib/librte_eal/common/include/rte_soc.h |  26 ++
 lib/librte_eal/linuxapp/eal/Makefile|   1 +
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |   3 +
 6 files changed, 201 insertions(+)
 create mode 100644 lib/librte_eal/common/eal_common_soc.c

diff --git a/app/test/test_soc.c b/app/test/test_soc.c
index 916a863..ac03e64 100644
--- a/app/test/test_soc.c
+++ b/app/test/test_soc.c
@@ -75,6 +75,108 @@ static int test_compare_addr(void)
free(a2.name);
free(a1.name);
free(a0.name);
+
+   return 0;
+}
+
+/**
+ * Empty PMD driver based on the SoC infra.
+ *
+ * The rte_soc_device is usually wrapped in some higher-level struct
+ * (eth_driver). We simulate such a wrapper with an anonymous struct here.
+ */
+struct test_wrapper {
+   struct rte_soc_driver soc_drv;
+};
+
+struct test_wrapper empty_pmd0 = {
+   .soc_drv = {
+   .driver = {
+   .name = "empty_pmd0"
+   },
+   },
+};
+
+struct test_wrapper empty_pmd1 = {
+   .soc_drv = {
+   .driver = {
+   .name = "empty_pmd1"
+   },
+   },
+};
+
+static int
+count_registered_socdrvs(void)
+{
+   int i;
+   struct rte_soc_driver *drv;
+
+   i = 0;
+   TAILQ_FOREACH(drv, &soc_driver_list, next)
+   i += 1;
+
+   return i;
+}
+
+static int
+test_register_unregister(void)
+{
+   struct rte_soc_driver *drv;
+   int count;
+
+   rte_eal_soc_register(&empty_pmd0.soc_drv);
+
+   TEST_ASSERT(!TAILQ_EMPTY(&soc_driver_list),
+   "No PMD is present but the empty_pmd0 should be there");
+   drv = TAILQ_FIRST(&soc_driver_list);
+   TEST_ASSERT(!strcmp(drv->driver.name, "empty_pmd0"),
+   "The registered PMD is not empty_pmd0 but '%s'",
+   drv->driver.name);
+
+   rte_eal_soc_register(&empty_pmd1.soc_drv);
+
+   count = count_registered_socdrvs();
+   TEST_ASSERT_EQUAL(count, 2, "Expected 2 PMDs but detected %d", count);
+
+   rte_eal_soc_unregister(&empty_pmd0.soc_drv);
+   count = count_registered_socdrvs();
+   TEST_ASSERT_EQUAL(count, 1, "Expected 1 PMDs but detected %d", count);
+
+   rte_eal_soc_unregister(&empty_pmd1.soc_drv);
+
+   printf("%s has been successful\n", __func__);
+   return 0;
+}
+
+/* save real devices and drivers until the tests finishes */
+struct soc_driver_list real_soc_driver_list =
+   TAILQ_HEAD_INITIALIZER(real_soc_driver_list);
+
+static int test_soc_setup(void)
+{
+   struct rte_soc_driver *drv;
+
+   /* no real drivers for the test */
+   while (!TAILQ_EMPTY(&soc_driver_list)) {
+   drv = TAILQ_FIRST(&soc_driver_list);
+   rte_eal_soc_unregister(drv);
+   TAILQ_INSERT_TAIL(&real_soc_driver_list, drv, next);
+   }
+
+   return 0;
+}
+
+static int test_soc_cleanup(void)
+{
+   struct rte_soc_driver *drv;
+
+   /* bring back real drivers after the test */
+   while (!TAILQ_EMPTY(&real_soc_driver_list)) {
+   drv = TAILQ_FIRST(&real_soc_driver_list);
+   TAILQ_REMOVE(&real_soc_driver_list, drv, next);
+   rte_eal_soc_register(drv);
+   }
+
return 0;
 }

@@ -84,6 +186,15 @@ test_soc(void)
if (test_compare_addr())
return -1;

+   if (test_soc_setup())
+   return -1;
+
+   if (test_register_unregister())
+   return -1;
+
+   if (test_soc_cleanup())
+   return -1;
+
return 0;
 }

diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map 
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 7b3d409..cda8009 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -168,4 +168,8 @@ DPDK_16.11 {

rte_eal_dev_attach;
rte_eal_dev_detach;
+   soc_driver_list;
+   rte_eal_soc_register;
+   rte_eal_soc_unregister;
+
 } DPDK_16.07;
diff --git a/lib/librte_eal/common/eal_common_soc.c 
b/lib/librte_eal/common/eal_common_soc.c
new file mode 100644
index 000..56135ed
--- /dev/null
+++ b/lib/librte_eal/common/eal_common_soc.c
@@ -0,0 +1,56 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2016 RehiveTech. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provi

[dpdk-dev] [PATCH v3 01/15] eal/soc: introduce very essential SoC infra definitions

[Shreyansh Jain]

Define initial structures and functions for the SoC infrastructure.
This patch supports only a very minimal functions for now.
More features will be added in the following commits.

Includes rte_device/rte_driver inheritance of
rte_soc_device/rte_soc_driver.

Signed-off-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
Signed-off-by: Hemant Agrawal 
---
 app/test/Makefile   |   1 +
 app/test/test_soc.c |  90 +
 lib/librte_eal/common/Makefile  |   2 +-
 lib/librte_eal/common/eal_private.h |   4 +
 lib/librte_eal/common/include/rte_soc.h | 138 
 5 files changed, 234 insertions(+), 1 deletion(-)
 create mode 100644 app/test/test_soc.c
 create mode 100644 lib/librte_eal/common/include/rte_soc.h

diff --git a/app/test/Makefile b/app/test/Makefile
index 611d77a..64b261d 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -77,6 +77,7 @@ APP = test
 #
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) := commands.c
 SRCS-y += test.c
+SRCS-y += test_soc.c
 SRCS-y += resource.c
 SRCS-y += test_resource.c
 test_resource.res: test_resource.c
diff --git a/app/test/test_soc.c b/app/test/test_soc.c
new file mode 100644
index 000..916a863
--- /dev/null
+++ b/app/test/test_soc.c
@@ -0,0 +1,90 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2016 RehiveTech. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of RehiveTech nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "test.h"
+
+static char *safe_strdup(const char *s)
+{
+   char *c = strdup(s);
+
+   if (c == NULL)
+   rte_panic("failed to strdup '%s'\n", s);
+
+   return c;
+}
+
+static int test_compare_addr(void)
+{
+   struct rte_soc_addr a0;
+   struct rte_soc_addr a1;
+   struct rte_soc_addr a2;
+
+   a0.name = safe_strdup("ethernet0");
+   a0.fdt_path = NULL;
+
+   a1.name = safe_strdup("ethernet0");
+   a1.fdt_path = NULL;
+
+   a2.name = safe_strdup("ethernet1");
+   a2.fdt_path = NULL;
+
+   TEST_ASSERT(!rte_eal_compare_soc_addr(&a0, &a1),
+   "Failed to compare two soc addresses that equal");
+   TEST_ASSERT(rte_eal_compare_soc_addr(&a0, &a2),
+   "Failed to compare two soc addresses that differs");
+
+   free(a2.name);
+   free(a1.name);
+   free(a0.name);
+   return 0;
+}
+
+static int
+test_soc(void)
+{
+   if (test_compare_addr())
+   return -1;
+
+   return 0;
+}
+
+REGISTER_TEST_COMMAND(soc_autotest, test_soc);
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index dfd64aa..b414008 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -33,7 +33,7 @@ include $(RTE_SDK)/mk/rte.vars.mk

 INC := rte_branch_prediction.h rte_common.h
 INC += rte_debug.h rte_eal.h rte_errno.h rte_launch.h rte_lcore.h
-INC += rte_log.h rte_memory.h rte_memzone.h rte_pci.h
+INC += rte_log.h rte_memory.h rte_memzone.h rte_soc.h rte_pci.h
 INC += rte_per_lcore.h rte_random.h
 INC += rte_tailq.h rte_interrupts.h rte_alarm.h
 INC += rte_string_fns.h rte_version.h
diff --git a/lib/librte_eal/common/eal_private.h 
b/lib/librte_eal/common/eal_private.h
index 431d6c2..df6582d 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -36,6 +36,7 @@

 #include 
 #include 
+#incl

[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL

[Shreyansh Jain]

Introduction:
=

This patch set is direct derivative of Jan's original series [1],[2].

 - As this deviates substantially from original series, if need be I can 
   post it as a separate patch rather than v2. Please suggest.
 - Also, there are comments on original v1 ([4]) which are _not_
   incorporated in this series as they refer to section no more in new
   version.
 - This v3 version is based on the rte_driver/device patchset v9 [10].
   That series introduced device structures (rte_driver/rte_device)
   generalizing devices into PCI, VDEV, XXX. For the purpose of this
   patchset, XXX=>SOC.

Aim:


As of now EAL is primarly focused on PCI initialization/probing.

 rte_eal_init()
  |- rte_eal_pci_init(): Find PCI devices from sysfs
  |- ...
  |- rte_eal_memzone_init()
  |- ...
  `- rte_eal_pci_probe(): Driver<=>Device initialization

This patchset introduces SoC framework which would enable SoC drivers and
drivers to be plugged into EAL, very similar to how PCI drivers/devices are
done today.

This is a stripped down version of PCI framework which allows the SoC PMDs
to implement their own routines for detecting devices and linking devices to
drivers.

1) Changes to EAL 
 rte_eal_init()
  |- rte_eal_pci_init(): Find PCI devices from sysfs
  |- rte_eal_soc_init(): Calls PMDs->scan_fn
  |- ...
  |- rte_eal_memzone_init()
  |- ...
  |- rte_eal_pci_probe(): Driver<=>Device initialization, PMD->devinit()
  `- rte_eal_soc_probe(): Calls PMDs->match_fn and PMDs->devinit();

2) New device/driver structures:
  - rte_soc_driver (inheriting rte_driver)
  - rte_soc_device (inheriting rte_device)
  - rte_eth_dev and eth_driver embedded rte_soc_device and rte_soc_driver,
respectively.

3) The SoC PMDs need to:
 - define rte_soc_driver with necessary scan and match callbacks
 - Register themselves using DRIVER_REGISTER_SOC()
 - Implement respective bus scanning in the scan callbacks to add necessary
   devices to SoC device list
 - Implement necessary eth_dev_init/uninint for ethernet instances

4) Design considerations that are same as PCI:
 - SoC initialization is being done through rte_eal_init(), just after PCI 
   initialization is done.
 - As in case of PCI, probe is done after rte_eal_pci_probe() to link the 
   devices detected with the drivers registered.
 - Device attach/detach functions are available and have been designed on 
   the lines of PCI framework.
 - PMDs register using DRIVER_REGISTER_SOC, very similar to 
   DRIVER_REGISTER_PCI for PCI devices.
 - Linked list of SoC driver and devices exists independent of the other 
   driver/device list, but inheriting rte_driver/rte_driver, these are also 
   part of a global list.

5) Design considerations that are different from PCI:
 - Each driver implements its own scan and match function. PCI uses the BDF 
   format to read the device from sysfs, but this _may_not_ be a case for a 
   SoC ethernet device.
   = This is an important change from initial proposal by Jan in [2]. Unlike 
   his attempt to use /sys/bus/platform, this patch relies on the PMD to
   detect the devices. This is because SoC may require specific or
   additional info for device detection. Further, SoC may have embedded
   devices/MACs which require initialization which cannot be covered through
   sysfs parsing.
   = PCI based PMDs rely on EAL's capability to detect devices. This 
   proposal puts the onus on PMD to detect devices, add to soc_device_list 
   and wait for Probe. Matching, of device<=>driver is again PMD's callback.

Patchset Overview:
==
 - Patches 0001~0003 introduce the base infrastructure and test case
 - Patch 0004 is for command line support for no-soc, on lines of no-pci
 - Patch 0005 enables EAL to handle SoC type devices
 - Patch 0006 adds support for scan and probe callbacks and updates the test
   framework with relevant test case.
 - Patch 0007~0009 enable device argument, driver specific flags and
   interrupt handling related basic infra. Subsequent patches build up on
   them.
 - Patch 0010~0013 makes changes to PCI as well as ethdev code to remove 
   assumption that eth_driver is a PCI driver.
 - Patch 0014 adds necessary ethdev probe/remove functions for PMDs to use
 - Patch 0015 adds support for SoC driver/devices, along with probe/remove
   functions for Cryptodev devices.

Future/Pending Changes:
===
- Device whitelisting/blacklist still relies on command line '-b' and '-c'
  which are internally implemented using OPT_PCI_BLACKLIST/OPT_PCI_WHITELIST.
  This needs to be changed to a generic form - OPT_DEV_*LIST - probably.
- No cryptodriver currently uses SoC framework - probably a example driver
  can be created to demonstrate usage.

 [1] http://dpdk.org/ml/archives/dev/2016-January/030915.html
 [2] http://www.dpdk.org/ml/archives/dev/2016-May/038486.html
 [3] http://dpdk.org/ml/archives/dev/2016-August/045707.html
 [4] http://dpdk.org/ml/archives/dev/2016-May/038948.html
 [5] http://dpdk.o

[dpdk-dev] [PATCH 2/3] net/virtio_user: fix wrong sequence of messages

[Yuanhan Liu]

On Fri, Sep 09, 2016 at 01:50:16PM +0800, Tan, Jianfeng wrote:
> On 9/9/2016 12:19 PM, Yuanhan Liu wrote:
> 
> >>
> >>
> >> Never mind, above fix on the vhost side will not take effect on 
> >> existing
> >> vpp-vhost implementations.
> >>
> >> Actually, I was talking about the DPDK vhost implementation :)
> >>
> >>
> >>This patch is talking about vpp's native vhost implementation, not 
> >>dpdk-vhost,
> >>and not the way vpp uses dpdk-vhost.
> >Yes, I know. What I meant is there was a "workaround" in DPDK vhost
> >implementation, and since you bring this issue on the table again,
> >it's a chance to think about how can we fix it.
> >
> >A rough idea come to my mind is we could check all the per-vring message
> >at the begining of vhost_user_msg_handler() and allocate related vq when
> >necessary (when it's the first vring message we got).
> >
> >Yeah, I know it's a bit ugly, but it at least gets rid of that 
> >"not-that-true"
> >assumption.
> 
> Sounds workable. So we'd define those vq-specific msgs, like:
> VHOST_USER_SET_VRING_NUM,
> VHOST_USER_SET_VRING_ADDR,
> VHOST_USER_SET_VRING_BASE,
> VHOST_USER_GET_VRING_BASE(?),
> VHOST_USER_SET_VRING_KICK,
> VHOST_USER_SET_VRING_CALL,
> VHOST_USER_SET_VRING_ENABLE,

Yes.

> >> Still not working. VPP needs SET_VRING_CALL to create vq firstly.
> >>
> >> Didn't get it. In the proposal, SET_FEATURES is sent before every other
> >> messages, thus it should not cause the issue you described in this 
> >> patch.
> >>
> >>
> >>OK. Let me try to explain. We take three vhost implementations into
> >>consideration: dpdk-2.2-vhost, dpdk-master-vhost, vpp-native-vhost.
> >>
> >>If set_feature before set_vring_call, dpdk-2.2-vhost will fail: inside
> >>set_feature handler, assigning header length to VQs which will be created in
> >>set_vring_call handler.
> >Oh, right. That was an in-correct implementation.
> >
> >>So we need to keep set_vring_call firstly.
> >>Then set_feature needs to be sent
> >>before any other msgs, this is what vpp-native-vhost requires. In all, the
> >>sequence is like this:
> >>1. set_vring_call,
> >>2. set_feature,
> >>3. other msgs
> >>
> >>
> >> Besides, haven't we already sent SET_VRING_CALL before other messages
> >> (well, execept the SET_FEATURES and SET_MEM_TABLE message)?
> >>
> >>
> >>Yes, set_vring_call is already in the first place, but we need to plugin
> >>set_feature between set_vring_call and other msgs. Previously, 
> >>set_vring_call
> >>and other msgs are together.
> >Okay. Another thing I noticed is that virtio-user lacks some feature
> >negotiations, like GET_FEATURES and GET_PROTOCOL_FEATURES. I think you
> >might need add them back somewhen?
> 
> GET_FEATURES has been done in virtio_user_dev_init().

Oh, sorry, I missed that.

> GET_PROTOCOL_FEATURES
> is not supported yet. I see those features in PROTOCOL_FEATURES is for live
> migration (right?).

Not exactly. PROTOCOL_FEATURES was firstly introduced while MQ was
enabled. Thus it's no wonder MQ is the first protocol feature vhost
user supports:

[yliu at yliu-dev ~/dpdk]$ gg PROTOCOL_F_ lib/librte_vhost/
lib/librte_vhost/vhost_user.h:46:#define VHOST_USER_PROTOCOL_F_MQ 0
lib/librte_vhost/vhost_user.h:47:#define VHOST_USER_PROTOCOL_F_LOG_SHMFD 1
lib/librte_vhost/vhost_user.h:48:#define VHOST_USER_PROTOCOL_F_RARP 2

--yliu

> Assuming that, anyone using container/process now
> enables live migration so far? I don't think so.
> 
> Thanks,
> Jianfeng
> 
> 
> >
> > --yliu

[dpdk-dev] [PATCH 2/3] net/virtio_user: fix wrong sequence of messages

[Tan, Jianfeng]

On 9/9/2016 12:19 PM, Yuanhan Liu wrote:

>>
>>
>>  Never mind, above fix on the vhost side will not take effect on 
>> existing
>>  vpp-vhost implementations.
>>
>>  Actually, I was talking about the DPDK vhost implementation :)
>>
>>
>> This patch is talking about vpp's native vhost implementation, not 
>> dpdk-vhost,
>> and not the way vpp uses dpdk-vhost.
> Yes, I know. What I meant is there was a "workaround" in DPDK vhost
> implementation, and since you bring this issue on the table again,
> it's a chance to think about how can we fix it.
>
> A rough idea come to my mind is we could check all the per-vring message
> at the begining of vhost_user_msg_handler() and allocate related vq when
> necessary (when it's the first vring message we got).
>
> Yeah, I know it's a bit ugly, but it at least gets rid of that "not-that-true"
> assumption.

Sounds workable. So we'd define those vq-specific msgs, like:
VHOST_USER_SET_VRING_NUM,
VHOST_USER_SET_VRING_ADDR,
VHOST_USER_SET_VRING_BASE,
VHOST_USER_GET_VRING_BASE(?),
VHOST_USER_SET_VRING_KICK,
VHOST_USER_SET_VRING_CALL,
VHOST_USER_SET_VRING_ENABLE,


>
>>  Still not working. VPP needs SET_VRING_CALL to create vq firstly.
>>
>>  Didn't get it. In the proposal, SET_FEATURES is sent before every other
>>  messages, thus it should not cause the issue you described in this 
>> patch.
>>
>>
>> OK. Let me try to explain. We take three vhost implementations into
>> consideration: dpdk-2.2-vhost, dpdk-master-vhost, vpp-native-vhost.
>>
>> If set_feature before set_vring_call, dpdk-2.2-vhost will fail: inside
>> set_feature handler, assigning header length to VQs which will be created in
>> set_vring_call handler.
> Oh, right. That was an in-correct implementation.
>
>> So we need to keep set_vring_call firstly.
>> Then set_feature needs to be sent
>> before any other msgs, this is what vpp-native-vhost requires. In all, the
>> sequence is like this:
>> 1. set_vring_call,
>> 2. set_feature,
>> 3. other msgs
>>
>>
>>  Besides, haven't we already sent SET_VRING_CALL before other messages
>>  (well, execept the SET_FEATURES and SET_MEM_TABLE message)?
>>
>>
>> Yes, set_vring_call is already in the first place, but we need to plugin
>> set_feature between set_vring_call and other msgs. Previously, set_vring_call
>> and other msgs are together.
> Okay. Another thing I noticed is that virtio-user lacks some feature
> negotiations, like GET_FEATURES and GET_PROTOCOL_FEATURES. I think you
> might need add them back somewhen?

GET_FEATURES has been done in virtio_user_dev_init(). 
GET_PROTOCOL_FEATURES is not supported yet. I see those features in 
PROTOCOL_FEATURES is for live migration (right?). Assuming that, anyone 
using container/process now enables live migration so far? I don't think so.

Thanks,
Jianfeng


>
>   --yliu

[dpdk-dev] [PATCH] scripts: reverse order of checked commits

[Thomas Monjalon]

The list of git commits to check was in the reversed order.
Also add a comment in the help of checkpatches.sh about list input.

Signed-off-by: Thomas Monjalon 
---
 scripts/check-git-log.sh | 10 +-
 scripts/checkpatches.sh  |  7 +--
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/scripts/check-git-log.sh b/scripts/check-git-log.sh
index 6137098..1e05cf2 100755
--- a/scripts/check-git-log.sh
+++ b/scripts/check-git-log.sh
@@ -49,11 +49,11 @@ fi

 range=${1:-origin/master..}

-commits=$(git log --format='%h' $range)
-headlines=$(git log --format='%s' $range)
-bodylines=$(git log --format='%b' $range)
-fixes=$(git log --format='%h %s' $range | grep -i ': *fix' | cut -d' ' -f1)
-tags=$(git log --format='%b' $range | grep -i -e 'by *:' -e 'fix.*:')
+commits=$(git log --format='%h' --reverse $range)
+headlines=$(git log --format='%s' --reverse $range)
+bodylines=$(git log --format='%b' --reverse $range)
+fixes=$(git log --format='%h %s' --reverse $range | grep -i ': *fix' | cut -d' 
' -f1)
+tags=$(git log --format='%b' --reverse $range | grep -i -e 'by *:' -e 'fix.*:')
 bytag='\(Reported\|Suggested\|Signed-off\|Acked\|Reviewed\|Tested\)-by:'

 # check headline format (spacing, no punctuation, no code)
diff --git a/scripts/checkpatches.sh b/scripts/checkpatches.sh
index 4addde4..622a5b6 100755
--- a/scripts/checkpatches.sh
+++ b/scripts/checkpatches.sh
@@ -52,6 +52,9 @@ print_usage () {

Run Linux kernel checkpatch.pl with DPDK options.
The environment variable DPDK_CHECKPATCH_PATH must be set.
+
+   The patches to check can be from files specified on the command line,
+   or latest git commits limited with -n option (default limit: 
origin/master).
END_OF_HELP
 }

@@ -96,9 +99,9 @@ check () { #   

 if [ -z "$1" ] ; then
if [ $number -eq 0 ] ; then
-   commits=$(git rev-list origin/master..)
+   commits=$(git rev-list --reverse origin/master..)
else
-   commits=$(git rev-list --max-count=$number HEAD)
+   commits=$(git rev-list --reverse --max-count=$number HEAD)
fi
for commit in $commits ; do
subject=$(git log --format='%s' -1 $commit)
-- 
2.7.0

[dpdk-dev] [PATCH v3] ntnic: add PMD driver

[Finn Christensen]

This is the Napatech NTNIC Poll Mode Driver (PMD) for DPDK.

This patch adds support for Napatech NICs to DPDK. This is the
initial implementation.

Signed-off-by: Finn Christensen 
---
v3:
  * Removed the need for binary libraries on build
v2:
  * Added information how to build the PMD without NIC
Board Support Package
  * Fixed some formatting issues
---
 MAINTAINERS |5 +
 config/common_base  |6 +
 doc/guides/nics/features/ntnic.ini  |   14 +
 doc/guides/nics/index.rst   |1 +
 doc/guides/nics/ntnic.rst   |  145 
 drivers/net/Makefile|1 +
 drivers/net/ntnic/Makefile  |   66 ++
 drivers/net/ntnic/rte_eth_ntnic.c   | 1150 +++
 drivers/net/ntnic/rte_pmd_ntnic_version.map |4 +
 mk/rte.app.mk   |3 +
 10 files changed, 1395 insertions(+)
 create mode 100644 doc/guides/nics/features/ntnic.ini
 create mode 100644 doc/guides/nics/ntnic.rst
 create mode 100644 drivers/net/ntnic/Makefile
 create mode 100644 drivers/net/ntnic/rte_eth_ntnic.c
 create mode 100644 drivers/net/ntnic/rte_pmd_ntnic_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index bc9aa02..d3e5f56 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -356,6 +356,11 @@ M: Sony Chacko 
 F: drivers/net/qede/
 F: doc/guides/nics/qede.rst

+Napatech ntnic
+M: Finn Christensen 
+F: drivers/net/ntnic/
+F: doc/guides/nics/ntnic.rst
+
 RedHat virtio
 M: Huawei Xie 
 M: Yuanhan Liu 
diff --git a/config/common_base b/config/common_base
index 7830535..4a3b2b8 100644
--- a/config/common_base
+++ b/config/common_base
@@ -309,6 +309,12 @@ CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
 CONFIG_RTE_LIBRTE_PMD_PCAP=n

 #
+# Compile software PMD backed by NTNIC files
+#
+CONFIG_RTE_LIBRTE_PMD_NTNIC=n
+
+
+#
 # Compile link bonding PMD library
 #
 CONFIG_RTE_LIBRTE_PMD_BOND=y
diff --git a/doc/guides/nics/features/ntnic.ini 
b/doc/guides/nics/features/ntnic.ini
new file mode 100644
index 000..4237e6e
--- /dev/null
+++ b/doc/guides/nics/features/ntnic.ini
@@ -0,0 +1,14 @@
+;
+; Supported features of the 'ntnic' network poll mode driver.
+;
+; Refer to default.ini for the full list of available PMD features.
+;
+[Features]
+Link status  = Y
+Queue start/stop = Y
+Promiscuous mode = Y
+Jumbo frame  = Y
+Basic stats  = Y
+Multiprocess aware   = Y
+x86-64   = Y
+Usage doc= Y
diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 92d56a5..5c4205c 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -52,6 +52,7 @@ Network Interface Controller Drivers
 qede
 szedata2
 thunderx
+ntnic
 virtio
 vhost
 vmxnet3
diff --git a/doc/guides/nics/ntnic.rst b/doc/guides/nics/ntnic.rst
new file mode 100644
index 000..f9398db
--- /dev/null
+++ b/doc/guides/nics/ntnic.rst
@@ -0,0 +1,145 @@
+..  BSD LICENSE
+Copyright (c) 2016 Napatech A/S
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Napatech nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+NTNIC Poll Mode Driver
+==
+
+The NTNIC poll mode driver library (**librte_pmd_ntnic**) implements support
+for **Napatech NIC** 40/50 Gbps adapters.
+This PMD is implemented as a pure software virtual device and must be created
+by using the EAL --vdev=parameter (parameters are explained i detail later).
+It runs on top of the Napatech NFV NIC Board Support Package that m

[dpdk-dev] [PATCH v3 3/4] bonding: take queue spinlock in rx/tx burst functions

[Ferruh Yigit]

Hi Bernard,

This is an old patch, sorry for commenting after this long.

On 6/12/2016 6:11 PM, Bernard Iremonger wrote:
> Use rte_spinlock_trylock() in the rx/tx burst functions to
> take the queue spinlock.
> 
> Signed-off-by: Bernard Iremonger 
> Acked-by: Konstantin Ananyev 
> ---

...

>  static uint16_t
> @@ -143,8 +154,10 @@ bond_ethdev_rx_burst_8023ad(void *queue, struct rte_mbuf 
> **bufs,
> uint8_t i, j, k;
> 
> rte_eth_macaddr_get(internals->port_id, &bond_mac);
> -   /* Copy slave list to protect against slave up/down changes during tx
> -* bursting */

This piece,

...

> for (i = 0; i < num_of_slaves; i++) {
> -   struct port *port = &mode_8023ad_ports[slaves[i]];
> +   struct port *port;
> +
> +   port = &mode_8023ad_ports[internals->active_slaves[i]];

And this piece seems needs to be moved into next patch in the patchset.

...

And if you will send new version of the patchset, there are a few
warnings from check-git-log.sh:

Wrong headline prefix:
bonding: remove memcpy from burst functions
bonding: take queue spinlock in rx/tx burst functions
bonding: grab queue spinlocks in slave add and remove
bonding: add spinlock to rx and tx queues
Wrong headline lowercase:
bonding: take queue spinlock in rx/tx burst functions
bonding: add spinlock to rx and tx queues

Thanks,
ferruh

[dpdk-dev] [PATCH 2/3] net/virtio_user: fix wrong sequence of messages

[Yuanhan Liu]

On Fri, Sep 09, 2016 at 11:59:18AM +0800, Tan, Jianfeng wrote:
> It's actually a good catch. After a light thought, I think in 
> DPDK vhost, we
> may need to create those virtqueues once unix socket gets 
> connected, just
> like in vhost-net, virtqueues are created on char file open. 
> Right?
> 
> There is a difference: for vhost-net and tap mode, IIRC, it knows 
> how
> many queues before doing setup.
> 
> No, from linux/drivers/vhost/net.c:vhost_net_open(), we can see that
> virtqueues are allocated according to VHOST_NET_VQ_MAX.
> 
> Well, if you took a closer look, you will find VHOST_NET_VQ_MAX is
> defined to 2. That means it allocates a queue-pair only.
> 
> And FYI, the MQ support for vhost-net is actually done in the tap
> driver, but not in vhost-net driver. That results to the MQ
> implementation is a bit different between vhost-net and vhost-user.
> 
> Put simply, in vhost-net, one queue-pair has a backend fd associated
> with it. Vhost requests for different queue-pair are sent by different
> fd. That also means the vhost-net doesn't even need be aware of the
> MQ stuff.
> 
> However, for vhost-user implementation, all queue-pairs share one
> socket fd. All requests all also sent over the single socket fd,
> thus the backend (DPDK vhost) has to figure out how many queue
> pairs are actually enabled: and we detect it by reading the
> vring index of SET_VRING_CALL message; it's not quite right though.
> 
> 
> Aha, right, nice analysis.

Just some rough memory in my mind ;-)
> 
> 
> 
> How about reconsidering previous suggestion to allocate vq once 
> connection
> is established?
> 
> That's too much, because DPDK claims to support up to 0x8000
> queue-pairs. Don't even to say that the vhost_virtqueue struct
> was way too big before: it even holds an array of buf_vec with
> size 256.
> 
> 
> Another mistake of my memory, I was remember it wrongly as only 8 VQs are
> supported.
> One thing not related, provided that VHOST_MAX_QUEUE_PAIRS equals to 0x8000,
> struct vhost_virtqueue? *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2] spends 4MB for
> each virtio device, which could be a refined.

Yes, we could allocate a small array first, and then re-allocate if
necessary.

> 
> 
> 
> Never mind, above fix on the vhost side will not take effect on 
> existing
> vpp-vhost implementations.
> 
> Actually, I was talking about the DPDK vhost implementation :)
> 
> 
> This patch is talking about vpp's native vhost implementation, not dpdk-vhost,
> and not the way vpp uses dpdk-vhost.

Yes, I know. What I meant is there was a "workaround" in DPDK vhost
implementation, and since you bring this issue on the table again,
it's a chance to think about how can we fix it.

A rough idea come to my mind is we could check all the per-vring message
at the begining of vhost_user_msg_handler() and allocate related vq when
necessary (when it's the first vring message we got).

Yeah, I know it's a bit ugly, but it at least gets rid of that "not-that-true"
assumption.

> 
> Still not working. VPP needs SET_VRING_CALL to create vq firstly.
> 
> Didn't get it. In the proposal, SET_FEATURES is sent before every other
> messages, thus it should not cause the issue you described in this patch.
> 
> 
> OK. Let me try to explain. We take three vhost implementations into
> consideration: dpdk-2.2-vhost, dpdk-master-vhost, vpp-native-vhost.
> 
> If set_feature before set_vring_call, dpdk-2.2-vhost will fail: inside
> set_feature handler, assigning header length to VQs which will be created in
> set_vring_call handler.

Oh, right. That was an in-correct implementation.

> So we need to keep set_vring_call firstly.
> Then set_feature needs to be sent
> before any other msgs, this is what vpp-native-vhost requires. In all, the
> sequence is like this:
> 1. set_vring_call,
> 2. set_feature,
> 3. other msgs
> 
> 
> Besides, haven't we already sent SET_VRING_CALL before other messages
> (well, execept the SET_FEATURES and SET_MEM_TABLE message)?
> 
> 
> Yes, set_vring_call is already in the first place, but we need to plugin
> set_feature between set_vring_call and other msgs. Previously, set_vring_call
> and other msgs are together.

Okay. Another thing I noticed is that virtio-user lacks some feature
negotiations, like GET_FEATURES and GET_PROTOCOL_FEATURES. I think you
might need add them back somewhen?

--yliu

[dpdk-dev] [PATCH 2/3] net/virtio_user: fix wrong sequence of messages

[Tan, Jianfeng]

On 9/8/2016 8:18 PM, Yuanhan Liu wrote:
> On Thu, Sep 08, 2016 at 04:53:22PM +0800, Tan, Jianfeng wrote:
>>
>> On 9/6/2016 4:20 PM, Yuanhan Liu wrote:
>>> On Tue, Sep 06, 2016 at 03:54:30PM +0800, Tan, Jianfeng wrote:
 Hi Yuanhan,


 On 9/6/2016 2:42 PM, Yuanhan Liu wrote:
> On Fri, Aug 05, 2016 at 11:36:42AM +, Jianfeng Tan wrote:
>> When virtio_user is used with VPP's native vhost user, it cannot
>> send/receive any packets.
>>
>> The root cause is that vpp-vhost-user translates the message
>> VHOST_USER_SET_FEATURES as puting this device into init state,
>> aka, zero all related structures. However, previous code
>> puts this message at last in the whole initialization process,
>> which leads to all previous information are zeroed.
>>
>> To fix this issue, we rearrange the sequence of those messages.
>>- step 0, send VHOST_USER_SET_VRING_CALL so that vhost allocates
>>  virtqueue structures;
> Yes, it is. However, it's not that right to do that (you see there is
> a FIXME in vhost_user_set_vring_call()).
 I suppose you are specifying vhost_set_vring_call().
>>> Oh, I was talking about the new code: I have renamed it to
>>> vhost_user_set_vring_call :)
>>>
> That means it need be fixed: we should not rely on fact that it's the
> first per-vring message we will get in the current QEMU implementation
> as the truth.
>
> That also means, naming a function like virtio_user_create_queue() based
> on above behaviour is wrong.
 It's actually a good catch. After a light thought, I think in DPDK vhost, 
 we
 may need to create those virtqueues once unix socket gets connected, just
 like in vhost-net, virtqueues are created on char file open. Right?
>>> There is a difference: for vhost-net and tap mode, IIRC, it knows how
>>> many queues before doing setup.
>> No, from linux/drivers/vhost/net.c:vhost_net_open(), we can see that
>> virtqueues are allocated according to VHOST_NET_VQ_MAX.
> Well, if you took a closer look, you will find VHOST_NET_VQ_MAX is
> defined to 2. That means it allocates a queue-pair only.
>
> And FYI, the MQ support for vhost-net is actually done in the tap
> driver, but not in vhost-net driver. That results to the MQ
> implementation is a bit different between vhost-net and vhost-user.
>
> Put simply, in vhost-net, one queue-pair has a backend fd associated
> with it. Vhost requests for different queue-pair are sent by different
> fd. That also means the vhost-net doesn't even need be aware of the
> MQ stuff.
>
> However, for vhost-user implementation, all queue-pairs share one
> socket fd. All requests all also sent over the single socket fd,
> thus the backend (DPDK vhost) has to figure out how many queue
> pairs are actually enabled: and we detect it by reading the
> vring index of SET_VRING_CALL message; it's not quite right though.

Aha, right, nice analysis.

>
>> How about reconsidering previous suggestion to allocate vq once connection
>> is established?
> That's too much, because DPDK claims to support up to 0x8000
> queue-pairs. Don't even to say that the vhost_virtqueue struct
> was way too big before: it even holds an array of buf_vec with
> size 256.

Another mistake of my memory, I was remember it wrongly as only 8 VQs 
are supported.
One thing not related, provided that VHOST_MAX_QUEUE_PAIRS equals to 
0x8000, struct vhost_virtqueue  *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2] 
spends 4MB for each virtio device, which could be a refined.

>
>> Never mind, above fix on the vhost side will not take effect on existing
>> vpp-vhost implementations.
> Actually, I was talking about the DPDK vhost implementation :)

This patch is talking about vpp's native vhost implementation, not 
dpdk-vhost, and not the way vpp uses dpdk-vhost.

>
>> We still need to fix it in the virtio side.
> Yes, we could fix it in our side, even though VPP is broken.

OK, let's back to this patch.

>
>>>   While for vhost-user, it doesn't. That
>>> means, we have to allocate and setup virtqueues reactively: just like
>>> what we have done in vhost_set_vring_call(). What doesn't look perfect
>>> is it assume SET_VRING_CALL is the first per-vring message we will get.
>> Yes, depending on the assumption that SET_VRING_CALL is the first per-vring
>> message, looks like a bad implementation. As Stephen has suggested, it's
>> more like a bug in vpp. If we treat it like that way, we will fix nothing
>> here.
>>
>>
>>- step 1, send VHOST_USER_SET_FEATURES to confirm the features;
>>- step 2, send VHOST_USER_SET_MEM_TABLE to share mem regions;
>>- step 3, send VHOST_USER_SET_VRING_NUM, VHOST_USER_SET_VRING_BASE,
>>  VHOST_USER_SET_VRING_ADDR, VHOST_USER_SET_VRING_KICK for each
>>  queue;
>>- ...
>>
>> Fixes: 37a7eb2ae816 ("net/virtio-user: add device emulation layer")
>>
>> Reported-by: Zhihong Wang 
>> Signed-off-by: Jianfe

[dpdk-dev] [PATCH v3] testpmd: fix crash when mempool allocation fails

[Olivier Matz]

Avoid access to mempool pointer if it is NULL.

Fixes: b19a0c75a0d4 ("app/testpmd: remove anonymous mempool code")
Coverity issue: 127553

Signed-off-by: Olivier Matz 
---
 app/test-pmd/testpmd.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 1428974..e5f5986 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -444,10 +444,13 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned nb_mbuf,
mb_size, (unsigned) mb_mempool_cache,
sizeof(struct rte_pktmbuf_pool_private),
socket_id, 0);
+   if (rte_mp == NULL)
+   goto err;

if (rte_mempool_populate_anon(rte_mp) == 0) {
rte_mempool_free(rte_mp);
rte_mp = NULL;
+   goto err;
}
rte_pktmbuf_pool_init(rte_mp, NULL);
rte_mempool_obj_iter(rte_mp, rte_pktmbuf_init, NULL);
@@ -458,6 +461,7 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned nb_mbuf,
}
}

+err:
if (rte_mp == NULL) {
rte_exit(EXIT_FAILURE,
"Creation of mbuf pool for socket %u failed: %s\n",
-- 
2.8.1

[dpdk-dev] [PATCH v2] testpmd: fix crash when mempool allocation fails

[Olivier Matz]

Sorry, I just resent the same one...

On 09/09/2016 11:40 AM, Olivier Matz wrote:
> Avoid access to mempool pointer if it is NULL.
> 
> Fixes: b19a0c75a0d4 ("app/testpmd: remove anonymous mempool code")
> Coverity issue: 127553
> 
> Signed-off-by: Olivier Matz 
> ---
>  app/test-pmd/testpmd.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index 1428974..e0f8285 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -444,10 +444,13 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned 
> nb_mbuf,
>   mb_size, (unsigned) mb_mempool_cache,
>   sizeof(struct rte_pktmbuf_pool_private),
>   socket_id, 0);
> + if (rte_mp == NULL)
> + goto err;
>  
>   if (rte_mempool_populate_anon(rte_mp) == 0) {
>   rte_mempool_free(rte_mp);
>   rte_mp = NULL;
> + goto err;
>   }
>   rte_pktmbuf_pool_init(rte_mp, NULL);
>   rte_mempool_obj_iter(rte_mp, rte_pktmbuf_init, NULL);
> @@ -458,6 +461,7 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned nb_mbuf,
>   }
>   }
>  
> + err:
>   if (rte_mp == NULL) {
>   rte_exit(EXIT_FAILURE,
>   "Creation of mbuf pool for socket %u failed: %s\n",
> 

[dpdk-dev] [PATCH v2] testpmd: fix crash when mempool allocation fails

[Olivier Matz]

Avoid access to mempool pointer if it is NULL.

Fixes: b19a0c75a0d4 ("app/testpmd: remove anonymous mempool code")
Coverity issue: 127553

Signed-off-by: Olivier Matz 
---
 app/test-pmd/testpmd.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 1428974..e0f8285 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -444,10 +444,13 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned nb_mbuf,
mb_size, (unsigned) mb_mempool_cache,
sizeof(struct rte_pktmbuf_pool_private),
socket_id, 0);
+   if (rte_mp == NULL)
+   goto err;

if (rte_mempool_populate_anon(rte_mp) == 0) {
rte_mempool_free(rte_mp);
rte_mp = NULL;
+   goto err;
}
rte_pktmbuf_pool_init(rte_mp, NULL);
rte_mempool_obj_iter(rte_mp, rte_pktmbuf_init, NULL);
@@ -458,6 +461,7 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned nb_mbuf,
}
}

+ err:
if (rte_mp == NULL) {
rte_exit(EXIT_FAILURE,
"Creation of mbuf pool for socket %u failed: %s\n",
-- 
2.8.1

[dpdk-dev] [PATCH 1/6] ethdev: add Tx preparation

[Jerin Jacob]

On Thu, Sep 08, 2016 at 04:09:05PM +, Kulasek, TomaszX wrote:
> Hi Jerin,

Hi TomaszX,

> 
> > -Original Message-
> > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> > Sent: Thursday, September 8, 2016 09:29
> > To: Kulasek, TomaszX 
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 1/6] ethdev: add Tx preparation
> > 
> 
> [...]
> 
> > > +static inline uint16_t
> > > +rte_eth_tx_prep(uint8_t port_id, uint16_t queue_id, struct rte_mbuf
> > **tx_pkts,
> > > + uint16_t nb_pkts)
> > > +{
> > > + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> > > +
> > > + if (!dev->tx_pkt_prep) {
> > > + rte_errno = -ENOTSUP;
> > 
> > rte_errno update may not be necessary here. see below
> > 
> > > + return 0;
> > IMO, We should return "nb_pkts" here instead of 0(i.e, all the packets are
> > valid in-case PMD does not have tx_prep function) and in-case of "0"
> > the following check in the application also will fail for no reason if
> > (nb_prep < nb_pkts) {
> > printf("tx_prep failed\n");
> > }
> > 
> 
> Yes, it seems to be reasonable.
> 
> > 
> > > + }
> > > +
> > > +#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > + if (queue_id >= dev->data->nb_tx_queues) {
> > > + RTE_PMD_DEBUG_TRACE("Invalid TX queue_id=%d\n", queue_id);
> > > + rte_errno = -EINVAL;
> > > + return 0;
> > > + }
> > > +#endif
> > > +
> > > + return (*dev->tx_pkt_prep)(dev->data->tx_queues[queue_id],
> > > + tx_pkts, nb_pkts);
> > > +}
> > > +
> > 
> > IMO, We need to provide a compile time option for rte_eth_tx_prep as NOOP.
> > Default option should be non NOOP but incase a _target_ want to override
> > to NOOP it should be possible, the reasons is:
> > 
> > - Low-end ARMv7,ARMv8 targets may not have PCIE-RC support and it may have
> > only integrated NIC controller. On those targets, where integrated NIC
> > controller does not use tx_prep service it can made it as NOOP to save
> > cycles on following "rte_eth_tx_prep" and associated "if (unlikely(nb_prep
> > < nb_rx))" checks in the application.
> > 
> > /* Prepare burst of TX packets */
> > nb_prep = rte_eth_tx_prep(fs->rx_port, 0, pkts_burst, nb_rx);
> > 
> > if (unlikely(nb_prep < nb_rx)) {
> > int i;
> > for (i = nb_prep; i < nb_rx; i++)
> > rte_pktmbuf_free(pkts_burst[i]); }
> > 
> 
> You mean to have a code for NOOP like:
> 
> 
>   /* Prepare burst of TX packets */
>   nb_prep = nb_rx; /* rte_eth_tx_prep(fs->rx_port, 0, pkts_burst, nb_rx); 
> */
>  
>   if (unlikely(nb_prep < nb_rx)) {
>  int i;
>  for (i = nb_prep; i < nb_rx; i++)
>  rte_pktmbuf_free(pkts_burst[i]); }
> 
> 
> and let optimizer to remove unused parts?

I thought of creating compile time NOOP like this,
CONFIG_RTE_LIBRTE_ETHDEV_TXPREP_SUPPORT=y in config/common_base and
and have two flavors of definitions for rte_eth_tx_prep

#ifdef RTE_LIBRTE_ETHDEV_TXPREP_SUPPORT
static inline uint16_t
rte_eth_tx_prep(uint8_t port_id, uint16_t queue_id, struct rte_mbuf
**tx_pkts, uint16_t nb_pkts)
{
Proposed implementation
}
#else
static inline uint16_t
rte_eth_tx_prep(uint8_t port_id, uint16_t queue_id, struct rte_mbuf
**tx_pkts, uint16_t nb_pkts)
{
(void)port_id;
(void)queue_id;
..
}
#endif

> 
> 
> IMHO it should be an application issue to use tx_prep or not.

Some cases even _target_(example: config/defconfig_arm64-*) can also decides 
that.
An example of such target is:
Low-end ARMv7,ARMv8 targets may not have PCIE-RC support and it may have
only integrated NIC controller. On those targets/configs, where integrated NIC
controller does not use tx_prep service it can made it as NOOP to save
cycles on following "rte_eth_tx_prep" and associated "if (unlikely(nb_prep
< nb_rx))" checks in the application.

> 
> While part of the job is done by the driver (verification and preparation), 
> and part by application (error handling), such a global compile time option 
> can introduce inconsistency, if application will not handle both cases.

Each DPDK application build/compile against the target/config so I think
it is OK.

> 
> If someone wants to turn off this functionality, it should be done on 
> application level, e.g. with compilation option.
>  

[dpdk-dev] [RFC] igb_uio: deprecate iomem and ioport mapping

[David Marchand]

Hello Jianfeng,

On Thu, Sep 1, 2016 at 4:16 AM, Jianfeng Tan  wrote:
> Previously in igb_uio, iomem is mapped, and both ioport and io mem
> are recorded into uio framework, which is duplicated and makes the
> code too complex.
>
> For iomem, DPDK user space code never opens or reads files under
> /sys/pci/bus/devices/:xx:xx.x/uio/uioY/maps/. Instead,
> /sys/pci/bus/devices/:xx:xx.x/resourceY are used to map device
> memory.
>
> For ioport, non-x86 platforms cannot read from files under
> /sys/pci/bus/devices/:xx:xx.x/uio/uioY/portio/ directly, because
> non-x86 platforms need to map port region for access in user space,
> see non-x86 version pci_uio_ioport_map(). x86 platforms can use the
> the same way as uio_pci_generic.
>
> This patch deprecates iomem and ioport mapping in igb_uio kernel
> module, and adjusts the iomem implementation in both igb_uio and
> uio_pci_generic:
>   - for x86 platform, get ports info from /proc/ioports;
>   - for non-x86 platform, map and get ports info by pci_uio_ioport_map().
>
> Note: this will affect those applications who are using files under
> /sys/pci/bus/devices/:xx:xx.x/uio/uioY/maps/ and
> /sys/pci/bus/devices/:xx:xx.x/uio/uioY/portio/.
>
> Signed-off-by: Jianfeng Tan 
> ---
>  lib/librte_eal/linuxapp/eal/eal_pci.c |   4 -
>  lib/librte_eal/linuxapp/eal/eal_pci_uio.c |  56 +-
>  lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 119 
> ++
>  3 files changed, 9 insertions(+), 170 deletions(-)

[snip]

> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c 
> b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> index 1786b75..28d09ed 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c

[snip]

> -   /* FIXME only for primary process ? */
> -   if (dev->intr_handle.type == RTE_INTR_HANDLE_UNKNOWN) {
> -
> -   snprintf(filename, sizeof(filename), "/dev/uio%u", uio_num);
> -   dev->intr_handle.fd = open(filename, O_RDWR);
> -   if (dev->intr_handle.fd < 0) {
> -   RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
> -   filename, strerror(errno));
> -   return -1;
> -   }
> -   dev->intr_handle.type = RTE_INTR_HANDLE_UIO;
> -   }

The only potential issue I can see removing this is that if a device
has no iomem resource, then its interrupt fd will never be
initialised.
I can see no problem at the moment, so let's go with this.
If such a problem arises later, we can separate this from the resource
mapping stuff (with a new api ?).

The rest looks good to me.

As Ferruh said, this should go through deprecation notices then go in 17.02.


-- 
David Marchand

[dpdk-dev] [PATCH v9 01/25] eal: define macro container_of

[Adrien Mazarguil]

On Fri, Sep 09, 2016 at 09:49:06AM +0530, Shreyansh Jain wrote:
> Hi Ferruh,
> 
> On Thursday 08 September 2016 07:46 PM, Ferruh Yigit wrote:
> >On 9/7/2016 3:07 PM, Shreyansh Jain wrote:
> >>Signed-off-by: Jan Viktorin 
> >>Signed-off-by: Shreyansh Jain 
> >>---
> >> lib/librte_eal/common/include/rte_common.h | 21 +
> >> 1 file changed, 21 insertions(+)
> >>
> >>diff --git a/lib/librte_eal/common/include/rte_common.h 
> >>b/lib/librte_eal/common/include/rte_common.h
> >>index 332f2a4..c5d94f3 100644
> >>--- a/lib/librte_eal/common/include/rte_common.h
> >>+++ b/lib/librte_eal/common/include/rte_common.h
> >>@@ -322,6 +322,27 @@ rte_bsf32(uint32_t v)
> >> #define offsetof(TYPE, MEMBER)  __builtin_offsetof (TYPE, MEMBER)
> >> #endif
> >>
> >>+/**
> >>+ * Return pointer to the wrapping struct instance.
> >>+ * Example:
> >>+ *
> >>+ *  struct wrapper {
> >>+ *  ...
> >>+ *  struct child c;
> >>+ *  ...
> >>+ *  };
> >>+ *
> >>+ *  struct child *x = obtain(...);
> >>+ *  struct wrapper *w = container_of(x, struct wrapper, c);
> >>+ *
> >>+ * Some implementation already have this defined, thus, conditional
> >>+ * declaration.
> >>+ */
> >>+#ifndef container_of
> >>+#define container_of(p, type, member) \
> >>+   ((type *) (((char *) (p)) - offsetof(type, member)))
> >>+#endif
> >>+
> >> #define _RTE_STR(x) #x
> >> /** Take a macro value and get a string version of it */
> >> #define RTE_STR(x) _RTE_STR(x)
> >>
> >
> >Some mlx5 files includes dpdk version of container_of first, they
> >produce following warning:
> >
> >In file included from .../dpdk/build/include/rte_mbuf.h:57:0,
> > from .../dpdk/build/include/rte_ether.h:52,
> > from .../dpdk/drivers/net/mlx5/mlx5_trigger.c:38:
> >/usr/include/infiniband/verbs.h: In function ?verbs_get_device?:
> >/dpdk/build/include/rte_common.h:343:14: warning: cast discards
> >?const? qualifier from pointer target type [-Wcast-qual]
> >  ((type *) (((char *) (p)) - offsetof(type, member)))
> >
> >The verbs.h version of container_of is same with dpdk one, I am not able
> >to find why one gives warning but other not.
> 
> Thanks for highlighting. I am setting up my environment and will have a
> look.

This warning is a known issue in the Verbs header that will be addressed
eventually. It occurs even without Shreyansh's patch (more likely when
CONFIG_RTE_LIBRTE_MLX4_DEBUG and/or CONFIG_RTE_LIBRTE_MLX5_DEBUG are
enabled).

Your container_of() macro is fine, no need to spend time on this.

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH] kni: unregister an unregisterd net_device could cause a kernel crash

[zhouyangchao]

Signed-off-by: zhouyangchao 
---
 lib/librte_eal/linuxapp/kni/kni_misc.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c 
b/lib/librte_eal/linuxapp/kni/kni_misc.c
index 67e9b7d..ad4e603 100644
--- a/lib/librte_eal/linuxapp/kni/kni_misc.c
+++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
@@ -361,7 +361,9 @@ kni_dev_remove(struct kni_dev *dev)
igb_kni_remove(dev->pci_dev);

if (dev->net_dev) {
-   unregister_netdev(dev->net_dev);
+   if (dev->netdev->reg_state == NETREG_REGISTERED){
+   unregister_netdev(dev->net_dev);
+   }
free_netdev(dev->net_dev);
}

-- 
1.7.1

[dpdk-dev] [dpdk-stable] [PATCH] testpmd: fix crash when mempool allocation fails

[Olivier Matz]

Hi Yuanhan,

On 09/09/2016 10:25 AM, Yuanhan Liu wrote:
> On Fri, Sep 09, 2016 at 10:16:25AM +0200, Olivier Matz wrote:
>> Avoid access to mempool pointer if it is NULL.
>>
>> Fixes: b19a0c75a0d4 ("app/testpmd: remove anonymous mempool code")
>> Coverity issue: 127553
>>
>> Signed-off-by: Olivier Matz 
>> ---
>>  app/test-pmd/testpmd.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
>> index 1428974..e0f8285 100644
>> --- a/app/test-pmd/testpmd.c
>> +++ b/app/test-pmd/testpmd.c
>> @@ -444,10 +444,13 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned 
>> nb_mbuf,
>>  mb_size, (unsigned) mb_mempool_cache,
>>  sizeof(struct rte_pktmbuf_pool_private),
>>  socket_id, 0);
>> +if (rte_mp == NULL)
>> +goto err;
>>  
>>  if (rte_mempool_populate_anon(rte_mp) == 0) {
>>  rte_mempool_free(rte_mp);
>>  rte_mp = NULL;
>> +goto err;
>>  }
>>  rte_pktmbuf_pool_init(rte_mp, NULL);
>>  rte_mempool_obj_iter(rte_mp, rte_pktmbuf_init, NULL);
>> @@ -458,6 +461,7 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned 
>> nb_mbuf,
>>  }
>>  }
>>  
>> + err:
> 
> A minor nit: there is a heading white space char.
> 

Well, that's something I've been doing since a long time due to my
editor config, but I cannot find any good reason for doing that.

I'll send a v2 without this space (and fix my config for next times ;))

Olivier

[dpdk-dev] [PATCH] kni: unregister an unregisterd net_device could cause a kernel crash

[zhouyangchao]

Signed-off-by: zhouyangchao 
---
 lib/librte_eal/linuxapp/kni/kni_misc.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c 
b/lib/librte_eal/linuxapp/kni/kni_misc.c
index 67e9b7d..17b6d7a 100644
--- a/lib/librte_eal/linuxapp/kni/kni_misc.c
+++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
@@ -361,6 +361,9 @@ kni_dev_remove(struct kni_dev *dev)
igb_kni_remove(dev->pci_dev);

if (dev->net_dev) {
+   if (dev->net_dev->state == NETREG_REGISTERED) {
+   unregister_netdev(dev->net_dev);
+   }
unregister_netdev(dev->net_dev);
free_netdev(dev->net_dev);
}
-- 
1.7.1

[dpdk-dev] [PATCH] testpmd: fix crash when mempool allocation fails

[Olivier Matz]

Avoid access to mempool pointer if it is NULL.

Fixes: b19a0c75a0d4 ("app/testpmd: remove anonymous mempool code")
Coverity issue: 127553

Signed-off-by: Olivier Matz 
---
 app/test-pmd/testpmd.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 1428974..e0f8285 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -444,10 +444,13 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned nb_mbuf,
mb_size, (unsigned) mb_mempool_cache,
sizeof(struct rte_pktmbuf_pool_private),
socket_id, 0);
+   if (rte_mp == NULL)
+   goto err;

if (rte_mempool_populate_anon(rte_mp) == 0) {
rte_mempool_free(rte_mp);
rte_mp = NULL;
+   goto err;
}
rte_pktmbuf_pool_init(rte_mp, NULL);
rte_mempool_obj_iter(rte_mp, rte_pktmbuf_init, NULL);
@@ -458,6 +461,7 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned nb_mbuf,
}
}

+ err:
if (rte_mp == NULL) {
rte_exit(EXIT_FAILURE,
"Creation of mbuf pool for socket %u failed: %s\n",
-- 
2.8.1

[dpdk-dev] [PATCH] ethdev: clarify API comment for imissed stats

[Olivier Matz]

The "imissed" stats represent RX packets dropped by the HW,
so we should not talk about mbufs as the hardware is not aware
of this structure. Buffer seems to be a better word.

Fixes: 4eadb8ba11b7 ("ethdev: do not deprecate imissed counter")

Signed-off-by: Olivier Matz 
---
 lib/librte_ether/rte_ethdev.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index b0fe033..f4bc272 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -198,7 +198,7 @@ struct rte_eth_stats {
uint64_t obytes;/**< Total number of successfully transmitted 
bytes. */
uint64_t imissed;
/**< Total of RX packets dropped by the HW,
-* because there are no available mbufs (i.e. RX queues are full).
+* because there are no available buffer (i.e. RX queues are full).
 */
uint64_t ierrors;   /**< Total number of erroneous received packets. */
uint64_t oerrors;   /**< Total number of failed transmitted packets. */
-- 
2.8.1

[dpdk-dev] sysfs permission problem when running dpdk app in lxc

[Moon-Sang Lee]

I found many other guys face the same issue as mine, but no replies to
their question.
Anyway, there are three major option groups including apparmor, seccome,
and cgroup.
It seems that some security options of lxc prevent my DPDK app from opening
sysfs file in RW mode.
I changed lxc.aa_profile to unconfied, and that resolved my issue.



On Mon, Sep 5, 2016 at 2:33 PM, Moon-Sang Lee  wrote:

>
> I'm using ubuntu 16.04 LTS as my host and installed lxd on it.
> When I try to run my dpdk(2.2.0) app in the container, I got following
> error message.
>
> EAL: lcore 9 is ready (tid=17fd700;cpuset=[9])
> EAL: lcore 3 is ready (tid=c915700;cpuset=[3])
> EAL: lcore 11 is ready (tid=ffc700;cpuset=[11])
> EAL: lcore 5 is ready (tid=27ff700;cpuset=[5])
> EAL: lcore 7 is ready (tid=1ffe700;cpuset=[7])
> EAL: lcore 13 is ready (tid=7fb700;cpuset=[13])
> EAL: PCI device :06:00.0 on NUMA socket -1
> EAL:   probe driver: 8086:10e8 rte_igb_pmd
> EAL:   Not managed by a supported kernel driver, skipped
> EAL: PCI device :06:00.1 on NUMA socket -1
> EAL:   probe driver: 8086:10e8 rte_igb_pmd
> EAL:   Not managed by a supported kernel driver, skipped
> EAL: PCI device :07:00.0 on NUMA socket -1
> EAL:   probe driver: 8086:10e8 rte_igb_pmd
> EAL: Cannot open /sys/class/uio/uio0/device/config: Permission denied
> EAL: Error - exiting with code: 1
>   Cause: Requested device :07:00.0 cannot be used
>
>
>
> However, it seems ok of the permission when I list those files.
> I appreciate any comments.
>
> root at test4:~# cat /proc/mounts |grep sysfs
> sysfs /sys sysfs rw,relatime 0 0
> root at test4:~# ls -al /sys/class/uio/uio0/device/config
> -rw-r--r-- 1 root root 4096 Sep  5 04:56 /sys/class/uio/uio0/device/config
> root at test4:~# ls -al /dev/uio0
> crw-rw-rw- 1 root root 243, 0 Sep  5 04:16 /dev/uio0
> root at test4:~#
>
>
>
> --
> Moon-Sang Lee, SW Engineer
> Email: sang0627 at gmail.com
> Wisdom begins in wonder. *Socrates*
>



-- 
Moon-Sang Lee, SW Engineer
Email: sang0627 at gmail.com
Wisdom begins in wonder. *Socrates*

[dpdk-dev] [PATCH v2 8/8] app/testpmd: hide segsize when unrelevant in csum engine

[Olivier Matz]

When TSO is not asked, hide the segment size.

Signed-off-by: Olivier Matz 
---
 app/test-pmd/csumonly.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 9938150..4b36d74 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -809,7 +809,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
(testpmd_ol_flags & 
TESTPMD_TX_OFFLOAD_OUTER_IP_CKSUM))
printf("tx: m->outer_l2_len=%d 
m->outer_l3_len=%d\n",
m->outer_l2_len, m->outer_l3_len);
-   if (info.tso_segsz != 0)
+   if (info.tso_segsz != 0 && (m->ol_flags & 
PKT_TX_TCP_SEG))
printf("tx: m->tso_segsz=%d\n", m->tso_segsz);
rte_get_tx_ol_flag_list(m->ol_flags, buf, sizeof(buf));
printf("tx: flags=%s", buf);
-- 
2.8.1

[dpdk-dev] [PATCH v2 7/8] app/testpmd: don't use tso if packet is too small

[Olivier Matz]

Asking for TSO (TCP Segmentation Offload) on packets that are already
smaller than (headers + MSS) does not work, for instance on ixgbe.

Fix the csumonly engine to only set the TSO flag when a segmentation
offload is really required, i.e. when packet is large enough.

Signed-off-by: Olivier Matz 
---
 app/test-pmd/csumonly.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 35edf1d..9938150 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -102,6 +102,7 @@ struct testpmd_offload_info {
uint16_t outer_l3_len;
uint8_t outer_l4_proto;
uint16_t tso_segsz;
+   uint32_t pkt_len;
 };

 /* simplified GRE header */
@@ -329,13 +330,20 @@ process_inner_cksums(void *l3_hdr, const struct 
testpmd_offload_info *info,
struct tcp_hdr *tcp_hdr;
struct sctp_hdr *sctp_hdr;
uint64_t ol_flags = 0;
+   uint32_t max_pkt_len, tso_segsz = 0;
+
+   /* ensure packet is large enough to require tso */
+   max_pkt_len = info->l2_len + info->l3_len + info->l4_len +
+   info->tso_segsz;
+   if (info->tso_segsz != 0 && info->pkt_len > max_pkt_len)
+   tso_segsz = info->tso_segsz;

if (info->ethertype == _htons(ETHER_TYPE_IPv4)) {
ipv4_hdr = l3_hdr;
ipv4_hdr->hdr_checksum = 0;

ol_flags |= PKT_TX_IPV4;
-   if (info->tso_segsz != 0 && info->l4_proto == IPPROTO_TCP) {
+   if (tso_segsz != 0 && info->l4_proto == IPPROTO_TCP) {
ol_flags |= PKT_TX_IP_CKSUM;
} else {
if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_IP_CKSUM)
@@ -367,7 +375,7 @@ process_inner_cksums(void *l3_hdr, const struct 
testpmd_offload_info *info,
} else if (info->l4_proto == IPPROTO_TCP) {
tcp_hdr = (struct tcp_hdr *)((char *)l3_hdr + info->l3_len);
tcp_hdr->cksum = 0;
-   if (info->tso_segsz != 0) {
+   if (tso_segsz != 0) {
ol_flags |= PKT_TX_TCP_SEG;
tcp_hdr->cksum = get_psd_sum(l3_hdr, info->ethertype,
ol_flags);
@@ -667,6 +675,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)

m = pkts_burst[i];
info.is_tunnel = 0;
+   info.pkt_len = rte_pktmbuf_pkt_len(m);
tx_ol_flags = 0;
rx_ol_flags = m->ol_flags;

-- 
2.8.1

[dpdk-dev] [PATCH v2 6/8] app/testpmd: display rx port in csum engine

[Olivier Matz]

This information is useful when debugging, especially with
bidirectional traffic.

Signed-off-by: Olivier Matz 
---
 app/test-pmd/csumonly.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index ee98724..35edf1d 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -774,8 +774,8 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
char buf[256];

printf("-\n");
-   printf("mbuf=%p, pkt_len=%u, nb_segs=%hhu:\n",
-   m, m->pkt_len, m->nb_segs);
+   printf("port=%u, mbuf=%p, pkt_len=%u, nb_segs=%hhu:\n",
+   fs->rx_port, m, m->pkt_len, m->nb_segs);
/* dump rx parsed packet info */
rte_get_rx_ol_flag_list(rx_ol_flags, buf, sizeof(buf));
printf("rx: l2_len=%d ethertype=%x l3_len=%d "
-- 
2.8.1

[dpdk-dev] [PATCH v2 5/8] app/testpmd: do not change ip addrs in csum engine

[Olivier Matz]

The csum forward engine was updated to change the IP addresses in the
packet data in
commit 51f694dd40f5 ("app/testpmd: rework checksum forward engine")

This was done to ensure that the checksum is correctly reprocessed when
using hardware checksum offload. But the functions
process_inner_cksums() and process_outer_cksums() already reset the
checksum field to 0, so this is not necessary.

Moreover, this makes the engine more complex than needed, and prevents
to easily use it to forward traffic (like iperf) as it modifies the
packets.

This patch drops this behavior.

Signed-off-by: Olivier Matz 
---
 app/test-pmd/csumonly.c | 30 --
 1 file changed, 4 insertions(+), 26 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index a484b18..ee98724 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -318,21 +318,6 @@ parse_encap_ip(void *encap_ip, struct testpmd_offload_info 
*info)
info->l2_len = 0;
 }

-/* modify the IPv4 or IPv4 source address of a packet */
-static void
-change_ip_addresses(void *l3_hdr, uint16_t ethertype)
-{
-   struct ipv4_hdr *ipv4_hdr = l3_hdr;
-   struct ipv6_hdr *ipv6_hdr = l3_hdr;
-
-   if (ethertype == _htons(ETHER_TYPE_IPv4)) {
-   ipv4_hdr->src_addr =
-   rte_cpu_to_be_32(rte_be_to_cpu_32(ipv4_hdr->src_addr) + 
1);
-   } else if (ethertype == _htons(ETHER_TYPE_IPv6)) {
-   ipv6_hdr->src_addr[15] = ipv6_hdr->src_addr[15] + 1;
-   }
-}
-
 /* if possible, calculate the checksum of a packet in hw or sw,
  * depending on the testpmd command line configuration */
 static uint64_t
@@ -609,7 +594,6 @@ pkt_copy_split(const struct rte_mbuf *pkt)
  * Receive a burst of packets, and for each packet:
  *  - parse packet, and try to recognize a supported packet type (1)
  *  - if it's not a supported packet type, don't touch the packet, else:
- *  - modify the IPs in inner headers and in outer headers if any
  *  - reprocess the checksum of all supported layers. This is done in SW
  *or HW, depending on testpmd command line configuration
  *  - if TSO is enabled in testpmd command line, also flag the mbuf for TCP
@@ -726,20 +710,14 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
l3_hdr = (char *)l3_hdr + info.outer_l3_len + 
info.l2_len;
}

-   /* step 2: change all source IPs (v4 or v6) so we need
-* to recompute the chksums even if they were correct */
-
-   change_ip_addresses(l3_hdr, info.ethertype);
-   if (info.is_tunnel == 1)
-   change_ip_addresses(outer_l3_hdr, info.outer_ethertype);
-
-   /* step 3: depending on user command line configuration,
+   /* step 2: depending on user command line configuration,
 * recompute checksum either in software or flag the
 * mbuf to offload the calculation to the NIC. If TSO
 * is configured, prepare the mbuf for TCP segmentation. */

/* process checksums of inner headers first */
-   tx_ol_flags |= process_inner_cksums(l3_hdr, &info, 
testpmd_ol_flags);
+   tx_ol_flags |= process_inner_cksums(l3_hdr, &info,
+   testpmd_ol_flags);

/* Then process outer headers if any. Note that the software
 * checksum will be wrong if one of the inner checksums is
@@ -749,7 +727,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
testpmd_ol_flags);
}

-   /* step 4: fill the mbuf meta data (flags and header lengths) */
+   /* step 3: fill the mbuf meta data (flags and header lengths) */

if (info.is_tunnel == 1) {
if (testpmd_ol_flags & 
TESTPMD_TX_OFFLOAD_OUTER_IP_CKSUM) {
-- 
2.8.1

[dpdk-dev] [PATCH v2 4/8] app/testpmd: add option to enable lro

[Olivier Matz]

Introduce a new argument '--enable-lro' to ask testpmd to enable the LRO
feature on enabled ports, like it's done for '--enable-rx-cksum' for
instance.

Signed-off-by: Olivier Matz 
---
 app/test-pmd/parameters.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 8792c2c..612ad37 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -150,6 +150,7 @@ usage(char* progname)
   "If the drop-queue doesn't exist, the packet is dropped. "
   "By default drop-queue=127.\n");
printf("  --crc-strip: enable CRC stripping by hardware.\n");
+   printf("  --enable-lro: enable large receive offload.\n");
printf("  --enable-rx-cksum: enable rx hardware checksum offload.\n");
printf("  --disable-hw-vlan: disable hardware vlan.\n");
printf("  --disable-hw-vlan-filter: disable hardware vlan filter.\n");
@@ -525,6 +526,7 @@ launch_args_parse(int argc, char** argv)
{ "pkt-filter-size",1, 0, 0 },
{ "pkt-filter-drop-queue",  1, 0, 0 },
{ "crc-strip",  0, 0, 0 },
+   { "enable-lro", 0, 0, 0 },
{ "enable-rx-cksum",0, 0, 0 },
{ "enable-scatter", 0, 0, 0 },
{ "disable-hw-vlan",0, 0, 0 },
@@ -765,6 +767,8 @@ launch_args_parse(int argc, char** argv)
}
if (!strcmp(lgopts[opt_idx].name, "crc-strip"))
rx_mode.hw_strip_crc = 1;
+   if (!strcmp(lgopts[opt_idx].name, "enable-lro"))
+   rx_mode.enable_lro = 1;
if (!strcmp(lgopts[opt_idx].name, "enable-scatter"))
rx_mode.enable_scatter = 1;
if (!strcmp(lgopts[opt_idx].name, "enable-rx-cksum"))
-- 
2.8.1

[dpdk-dev] [PATCH v2 3/8] app/testpmd: dump rx flags in csum engine

[Olivier Matz]

Signed-off-by: Olivier Matz 
---
 app/test-pmd/csumonly.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 7cc51df..a484b18 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -641,7 +641,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
uint16_t nb_rx;
uint16_t nb_tx;
uint16_t i;
-   uint64_t ol_flags;
+   uint64_t rx_ol_flags, tx_ol_flags;
uint16_t testpmd_ol_flags;
uint32_t retry;
uint32_t rx_bad_ip_csum;
@@ -681,13 +681,14 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
rte_prefetch0(rte_pktmbuf_mtod(pkts_burst[i + 1],
   void *));

-   ol_flags = 0;
-   info.is_tunnel = 0;
m = pkts_burst[i];
+   info.is_tunnel = 0;
+   tx_ol_flags = 0;
+   rx_ol_flags = m->ol_flags;

/* Update the L3/L4 checksum error packet statistics */
-   rx_bad_ip_csum += ((m->ol_flags & PKT_RX_IP_CKSUM_BAD) != 0);
-   rx_bad_l4_csum += ((m->ol_flags & PKT_RX_L4_CKSUM_BAD) != 0);
+   rx_bad_ip_csum += ((rx_ol_flags & PKT_RX_IP_CKSUM_BAD) != 0);
+   rx_bad_l4_csum += ((rx_ol_flags & PKT_RX_L4_CKSUM_BAD) != 0);

/* step 1: dissect packet, parsing optional vlan, ip4/ip6, vxlan
 * and inner headers */
@@ -738,13 +739,13 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
 * is configured, prepare the mbuf for TCP segmentation. */

/* process checksums of inner headers first */
-   ol_flags |= process_inner_cksums(l3_hdr, &info, 
testpmd_ol_flags);
+   tx_ol_flags |= process_inner_cksums(l3_hdr, &info, 
testpmd_ol_flags);

/* Then process outer headers if any. Note that the software
 * checksum will be wrong if one of the inner checksums is
 * processed in hardware. */
if (info.is_tunnel == 1) {
-   ol_flags |= process_outer_cksums(outer_l3_hdr, &info,
+   tx_ol_flags |= process_outer_cksums(outer_l3_hdr, &info,
testpmd_ol_flags);
}

@@ -778,7 +779,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
m->l4_len = info.l4_len;
}
m->tso_segsz = info.tso_segsz;
-   m->ol_flags = ol_flags;
+   m->ol_flags = tx_ol_flags;

/* Do split & copy for the packet. */
if (tx_pkt_split != TX_PKT_SPLIT_OFF) {
@@ -798,10 +799,11 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
printf("mbuf=%p, pkt_len=%u, nb_segs=%hhu:\n",
m, m->pkt_len, m->nb_segs);
/* dump rx parsed packet info */
+   rte_get_rx_ol_flag_list(rx_ol_flags, buf, sizeof(buf));
printf("rx: l2_len=%d ethertype=%x l3_len=%d "
-   "l4_proto=%d l4_len=%d\n",
+   "l4_proto=%d l4_len=%d flags=%s\n",
info.l2_len, rte_be_to_cpu_16(info.ethertype),
-   info.l3_len, info.l4_proto, info.l4_len);
+   info.l3_len, info.l4_proto, info.l4_len, buf);
if (info.is_tunnel == 1)
printf("rx: outer_l2_len=%d outer_ethertype=%x "
"outer_l3_len=%d\n", info.outer_l2_len,
-- 
2.8.1

[dpdk-dev] [PATCH v2 2/8] app/testpmd: use new function to dump offload flags

[Olivier Matz]

Use the functions introduced in the previous commit to dump the offload
flags.

Signed-off-by: Olivier Matz 
---
 app/test-pmd/csumonly.c | 27 +++
 app/test-pmd/rxonly.c   | 15 ++-
 2 files changed, 5 insertions(+), 37 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index ac4bd8f..7cc51df 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -792,23 +792,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)

/* if verbose mode is enabled, dump debug info */
if (verbose_level > 0) {
-   struct {
-   uint64_t flag;
-   uint64_t mask;
-   } tx_flags[] = {
-   { PKT_TX_IP_CKSUM, PKT_TX_IP_CKSUM },
-   { PKT_TX_UDP_CKSUM, PKT_TX_L4_MASK },
-   { PKT_TX_TCP_CKSUM, PKT_TX_L4_MASK },
-   { PKT_TX_SCTP_CKSUM, PKT_TX_L4_MASK },
-   { PKT_TX_IPV4, PKT_TX_IPV4 },
-   { PKT_TX_IPV6, PKT_TX_IPV6 },
-   { PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IP_CKSUM 
},
-   { PKT_TX_OUTER_IPV4, PKT_TX_OUTER_IPV4 },
-   { PKT_TX_OUTER_IPV6, PKT_TX_OUTER_IPV6 },
-   { PKT_TX_TCP_SEG, PKT_TX_TCP_SEG },
-   };
-   unsigned j;
-   const char *name;
+   char buf[256];

printf("-\n");
printf("mbuf=%p, pkt_len=%u, nb_segs=%hhu:\n",
@@ -838,13 +822,8 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
m->outer_l2_len, m->outer_l3_len);
if (info.tso_segsz != 0)
printf("tx: m->tso_segsz=%d\n", m->tso_segsz);
-   printf("tx: flags=");
-   for (j = 0; j < sizeof(tx_flags)/sizeof(*tx_flags); 
j++) {
-   name = 
rte_get_tx_ol_flag_name(tx_flags[j].flag);
-   if ((m->ol_flags & tx_flags[j].mask) ==
-   tx_flags[j].flag)
-   printf("%s ", name);
-   }
+   rte_get_tx_ol_flag_list(m->ol_flags, buf, sizeof(buf));
+   printf("tx: flags=%s", buf);
printf("\n");
}
}
diff --git a/app/test-pmd/rxonly.c b/app/test-pmd/rxonly.c
index b83d0c7..3886000 100644
--- a/app/test-pmd/rxonly.c
+++ b/app/test-pmd/rxonly.c
@@ -230,19 +230,8 @@ pkt_burst_receive(struct fwd_stream *fs)
}
printf(" - Receive queue=0x%x", (unsigned) fs->rx_queue);
printf("\n");
-   if (ol_flags != 0) {
-   unsigned rxf;
-   const char *name;
-
-   for (rxf = 0; rxf < sizeof(mb->ol_flags) * 8; rxf++) {
-   if ((ol_flags & (1ULL << rxf)) == 0)
-   continue;
-   name = rte_get_rx_ol_flag_name(1ULL << rxf);
-   if (name == NULL)
-   continue;
-   printf("  %s\n", name);
-   }
-   }
+   rte_get_rx_ol_flag_list(mb->ol_flags, buf, sizeof(buf));
+   printf("  ol_flags: %s\n", buf);
rte_pktmbuf_free(mb);
}

-- 
2.8.1

[dpdk-dev] [PATCH v2 1/8] mbuf: add function to dump ol flag list

[Olivier Matz]

The functions rte_get_rx_ol_flag_name() and rte_get_tx_ol_flag_name()
can dump one flag, or set of flag that are part of the same mask (ex:
PKT_TX_UDP_CKSUM, part of PKT_TX_L4_MASK). But they are not designed to
dump the list of flags contained in mbuf->ol_flags.

This commit introduce new functions to do that. Similarly to the packet
type dump functions, the goal is to factorize the code that could be
used in several applications and reduce the risk of desynchronization
between the flags and the dump functions.

Signed-off-by: Olivier Matz 
---
 doc/guides/rel_notes/release_16_11.rst |  5 ++
 lib/librte_mbuf/rte_mbuf.c | 91 ++
 lib/librte_mbuf/rte_mbuf.h | 28 +++
 lib/librte_mbuf/rte_mbuf_version.map   |  2 +
 4 files changed, 126 insertions(+)

diff --git a/doc/guides/rel_notes/release_16_11.rst 
b/doc/guides/rel_notes/release_16_11.rst
index 36111f3..a877e58 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -50,6 +50,11 @@ New Features

   Added new functions ``rte_get_ptype_*()`` to dump a packet type as a string.

+* **Added functions to dump the offload flags as a string.**
+
+  Added two new functions ``rte_get_rx_ol_flag_list()`` and
+  ``rte_get_tx_ol_flag_list()`` to dump offload flags as a string.
+
 Resolved Issues
 ---

diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index fb2b962..56f37e6 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -319,6 +319,53 @@ const char *rte_get_rx_ol_flag_name(uint64_t mask)
}
 }

+struct flag_mask {
+   uint64_t flag;
+   uint64_t mask;
+   const char *default_name;
+};
+
+/* write the list of rx ol flags in buffer buf */
+int rte_get_rx_ol_flag_list(uint64_t mask, char *buf, size_t buflen)
+{
+   const struct flag_mask rx_flags[] = {
+   { PKT_RX_VLAN_PKT, PKT_RX_VLAN_PKT, NULL },
+   { PKT_RX_RSS_HASH, PKT_RX_RSS_HASH, NULL },
+   { PKT_RX_FDIR, PKT_RX_FDIR, NULL },
+   { PKT_RX_L4_CKSUM_BAD, PKT_RX_L4_CKSUM_BAD, NULL },
+   { PKT_RX_IP_CKSUM_BAD, PKT_RX_IP_CKSUM_BAD, NULL },
+   { PKT_RX_EIP_CKSUM_BAD, PKT_RX_EIP_CKSUM_BAD, NULL },
+   { PKT_RX_VLAN_STRIPPED, PKT_RX_VLAN_STRIPPED, NULL },
+   { PKT_RX_IEEE1588_PTP, PKT_RX_IEEE1588_PTP, NULL },
+   { PKT_RX_IEEE1588_TMST, PKT_RX_IEEE1588_TMST, NULL },
+   { PKT_RX_QINQ_STRIPPED, PKT_RX_QINQ_STRIPPED, NULL },
+   };
+   const char *name;
+   unsigned int i;
+   int ret;
+
+   if (buflen == 0)
+   return -1;
+
+   buf[0] = '\0';
+   for (i = 0; i < RTE_DIM(rx_flags); i++) {
+   if ((mask & rx_flags[i].mask) != rx_flags[i].flag)
+   continue;
+   name = rte_get_rx_ol_flag_name(rx_flags[i].flag);
+   if (name == NULL)
+   name = rx_flags[i].default_name;
+   ret = snprintf(buf, buflen, "%s ", name);
+   if (ret < 0)
+   return -1;
+   if ((size_t)ret >= buflen)
+   return -1;
+   buf += ret;
+   buflen -= ret;
+   }
+
+   return 0;
+}
+
 /*
  * Get the name of a TX offload flag. Must be kept synchronized with flag
  * definitions in rte_mbuf.h.
@@ -341,3 +388,47 @@ const char *rte_get_tx_ol_flag_name(uint64_t mask)
default: return NULL;
}
 }
+
+/* write the list of tx ol flags in buffer buf */
+int rte_get_tx_ol_flag_list(uint64_t mask, char *buf, size_t buflen)
+{
+   const struct flag_mask tx_flags[] = {
+   { PKT_TX_VLAN_PKT, PKT_TX_VLAN_PKT, NULL },
+   { PKT_TX_IP_CKSUM, PKT_TX_IP_CKSUM, NULL },
+   { PKT_TX_TCP_CKSUM, PKT_TX_L4_MASK, NULL },
+   { PKT_TX_SCTP_CKSUM, PKT_TX_L4_MASK, NULL },
+   { PKT_TX_UDP_CKSUM, PKT_TX_L4_MASK, NULL },
+   { PKT_TX_L4_NO_CKSUM, PKT_TX_L4_MASK, "PKT_TX_L4_NO_CKSUM" },
+   { PKT_TX_IEEE1588_TMST, PKT_TX_IEEE1588_TMST, NULL },
+   { PKT_TX_TCP_SEG, PKT_TX_TCP_SEG, NULL },
+   { PKT_TX_IPV4, PKT_TX_IPV4, NULL },
+   { PKT_TX_IPV6, PKT_TX_IPV6, NULL },
+   { PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IP_CKSUM, NULL },
+   { PKT_TX_OUTER_IPV4, PKT_TX_OUTER_IPV4, NULL },
+   { PKT_TX_OUTER_IPV6, PKT_TX_OUTER_IPV6, NULL },
+   };
+   const char *name;
+   unsigned int i;
+   int ret;
+
+   if (buflen == 0)
+   return -1;
+
+   buf[0] = '\0';
+   for (i = 0; i < RTE_DIM(tx_flags); i++) {
+   if ((mask & tx_flags[i].mask) != tx_flags[i].flag)
+   continue;
+   name = rte_get_tx_ol_flag_name(tx_flags[i].flag);
+   if (name == NULL)
+   name = tx_flags[i].default_name;
+

[dpdk-dev] [PATCH v2 0/8] Misc enhancements in testpmd

[Olivier Matz]

This patchset introduces several enhancements or minor fixes
in testpmd. It is targetted for v16.11, and applies on top of
software ptype v2 patchset [1].

These patches are useful to validate the virtio offload
patchset [2] (to be rebased).

[1] http://dpdk.org/ml/archives/dev/2016-August/045876.html
[2] http://dpdk.org/ml/archives/dev/2016-July/044404.html

changes v1 -> v2:
- rebase on top of sw ptype v2 patch

Olivier Matz (8):
  mbuf: add function to dump ol flag list
  app/testpmd: use new function to dump offload flags
  app/testpmd: dump rx flags in csum engine
  app/testpmd: add option to enable lro
  app/testpmd: do not change ip addrs in csum engine
  app/testpmd: display rx port in csum engine
  app/testpmd: don't use tso if packet is too small
  app/testpmd: hide segsize when unrelevant in csum engine

 app/test-pmd/csumonly.c| 96 --
 app/test-pmd/parameters.c  |  4 ++
 app/test-pmd/rxonly.c  | 15 +-
 doc/guides/rel_notes/release_16_11.rst |  5 ++
 lib/librte_mbuf/rte_mbuf.c | 91 
 lib/librte_mbuf/rte_mbuf.h | 28 ++
 lib/librte_mbuf/rte_mbuf_version.map   |  2 +
 7 files changed, 164 insertions(+), 77 deletions(-)

-- 
2.8.1

[dpdk-dev] [PATCH v3] ntnic: add PMD driver

[Neil Horman]

On Fri, Sep 09, 2016 at 12:48:38PM +, Finn Christensen wrote:
> This is the Napatech NTNIC Poll Mode Driver (PMD) for DPDK.
> 
> This patch adds support for Napatech NICs to DPDK. This is the
> initial implementation.
> 
> Signed-off-by: Finn Christensen 
> ---
> v3:
>   * Removed the need for binary libraries on build
> v2:
>   * Added information how to build the PMD without NIC
> Board Support Package
>   * Fixed some formatting issues
So, this is a step in the right direction, but I think its solving the wrong
problem.  If you have a dependency on an external library, thats ok, and
accessing it via dlopen makes it possible to build the library without having
that library present, but it not really in keeping with the spirit of what I
meant.  This driver is still effectively dependent on a binary blob that we have
no visibility into.  The better solution is releasing the source for the ntnic
and ntos libraries.  The license file in the referenced git tree indicates its
BSD licensed, so I don't think there should be a problem in doing that.

Neil

> ---
>  MAINTAINERS |5 +
>  config/common_base  |6 +
>  doc/guides/nics/features/ntnic.ini  |   14 +
>  doc/guides/nics/index.rst   |1 +
>  doc/guides/nics/ntnic.rst   |  145 
>  drivers/net/Makefile|1 +
>  drivers/net/ntnic/Makefile  |   66 ++
>  drivers/net/ntnic/rte_eth_ntnic.c   | 1150 
> +++
>  drivers/net/ntnic/rte_pmd_ntnic_version.map |4 +
>  mk/rte.app.mk   |3 +
>  10 files changed, 1395 insertions(+)
>  create mode 100644 doc/guides/nics/features/ntnic.ini
>  create mode 100644 doc/guides/nics/ntnic.rst
>  create mode 100644 drivers/net/ntnic/Makefile
>  create mode 100644 drivers/net/ntnic/rte_eth_ntnic.c
>  create mode 100644 drivers/net/ntnic/rte_pmd_ntnic_version.map
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bc9aa02..d3e5f56 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -356,6 +356,11 @@ M: Sony Chacko 
>  F: drivers/net/qede/
>  F: doc/guides/nics/qede.rst
> 
> +Napatech ntnic
> +M: Finn Christensen 
> +F: drivers/net/ntnic/
> +F: doc/guides/nics/ntnic.rst
> +
>  RedHat virtio
>  M: Huawei Xie 
>  M: Yuanhan Liu 
> diff --git a/config/common_base b/config/common_base
> index 7830535..4a3b2b8 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -309,6 +309,12 @@ CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
>  CONFIG_RTE_LIBRTE_PMD_PCAP=n
> 
>  #
> +# Compile software PMD backed by NTNIC files
> +#
> +CONFIG_RTE_LIBRTE_PMD_NTNIC=n
> +
> +
> +#
>  # Compile link bonding PMD library
>  #
>  CONFIG_RTE_LIBRTE_PMD_BOND=y
> diff --git a/doc/guides/nics/features/ntnic.ini 
> b/doc/guides/nics/features/ntnic.ini
> new file mode 100644
> index 000..4237e6e
> --- /dev/null
> +++ b/doc/guides/nics/features/ntnic.ini
> @@ -0,0 +1,14 @@
> +;
> +; Supported features of the 'ntnic' network poll mode driver.
> +;
> +; Refer to default.ini for the full list of available PMD features.
> +;
> +[Features]
> +Link status  = Y
> +Queue start/stop = Y
> +Promiscuous mode = Y
> +Jumbo frame  = Y
> +Basic stats  = Y
> +Multiprocess aware   = Y
> +x86-64   = Y
> +Usage doc= Y
> diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
> index 92d56a5..5c4205c 100644
> --- a/doc/guides/nics/index.rst
> +++ b/doc/guides/nics/index.rst
> @@ -52,6 +52,7 @@ Network Interface Controller Drivers
>  qede
>  szedata2
>  thunderx
> +ntnic
>  virtio
>  vhost
>  vmxnet3
> diff --git a/doc/guides/nics/ntnic.rst b/doc/guides/nics/ntnic.rst
> new file mode 100644
> index 000..f9398db
> --- /dev/null
> +++ b/doc/guides/nics/ntnic.rst
> @@ -0,0 +1,145 @@
> +..  BSD LICENSE
> +Copyright (c) 2016 Napatech A/S
> +All rights reserved.
> +
> +Redistribution and use in source and binary forms, with or without
> +modification, are permitted provided that the following conditions
> +are met:
> +
> +* Redistributions of source code must retain the above copyright
> +notice, this list of conditions and the following disclaimer.
> +* Redistributions in binary form must reproduce the above copyright
> +notice, this list of conditions and the following disclaimer in
> +the documentation and/or other materials provided with the
> +distribution.
> +* Neither the name of Napatech nor the names of its
> +contributors may be used to endorse or promote products derived
> +from this software without specific prior written permission.
> +
> +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO

[dpdk-dev] [PATCH v9 01/25] eal: define macro container_of

[Shreyansh Jain]

Hi Ferruh,

On Thursday 08 September 2016 07:46 PM, Ferruh Yigit wrote:
> On 9/7/2016 3:07 PM, Shreyansh Jain wrote:
>> Signed-off-by: Jan Viktorin 
>> Signed-off-by: Shreyansh Jain 
>> ---
>>  lib/librte_eal/common/include/rte_common.h | 21 +
>>  1 file changed, 21 insertions(+)
>>
>> diff --git a/lib/librte_eal/common/include/rte_common.h 
>> b/lib/librte_eal/common/include/rte_common.h
>> index 332f2a4..c5d94f3 100644
>> --- a/lib/librte_eal/common/include/rte_common.h
>> +++ b/lib/librte_eal/common/include/rte_common.h
>> @@ -322,6 +322,27 @@ rte_bsf32(uint32_t v)
>>  #define offsetof(TYPE, MEMBER)  __builtin_offsetof (TYPE, MEMBER)
>>  #endif
>>
>> +/**
>> + * Return pointer to the wrapping struct instance.
>> + * Example:
>> + *
>> + *  struct wrapper {
>> + *  ...
>> + *  struct child c;
>> + *  ...
>> + *  };
>> + *
>> + *  struct child *x = obtain(...);
>> + *  struct wrapper *w = container_of(x, struct wrapper, c);
>> + *
>> + * Some implementation already have this defined, thus, conditional
>> + * declaration.
>> + */
>> +#ifndef container_of
>> +#define container_of(p, type, member) \
>> +((type *) (((char *) (p)) - offsetof(type, member)))
>> +#endif
>> +
>>  #define _RTE_STR(x) #x
>>  /** Take a macro value and get a string version of it */
>>  #define RTE_STR(x) _RTE_STR(x)
>>
>
> Some mlx5 files includes dpdk version of container_of first, they
> produce following warning:
>
> In file included from .../dpdk/build/include/rte_mbuf.h:57:0,
>  from .../dpdk/build/include/rte_ether.h:52,
>  from .../dpdk/drivers/net/mlx5/mlx5_trigger.c:38:
> /usr/include/infiniband/verbs.h: In function ?verbs_get_device?:
> /dpdk/build/include/rte_common.h:343:14: warning: cast discards
> ?const? qualifier from pointer target type [-Wcast-qual]
>   ((type *) (((char *) (p)) - offsetof(type, member)))
>
> The verbs.h version of container_of is same with dpdk one, I am not able
> to find why one gives warning but other not.

Thanks for highlighting. I am setting up my environment and will have a 
look.

>
> Regards,
> ferruh
>
>

-- 
Shreyansh

[dpdk-dev] [PATCH] net/kni: add KNI PMD

[Thomas Monjalon]

2016-09-08 19:11, Ferruh Yigit:
> On 9/8/2016 10:38 AM, Thomas Monjalon wrote:
> > 2016-09-08 10:25, Bruce Richardson:
> >> On Thu, Sep 08, 2016 at 09:44:55AM +0200, Thomas Monjalon wrote:
> >>> 2016-09-06 11:33, Ferruh Yigit:
>  Add KNI PMD which wraps librte_kni for ease of use.
> 
>  KNI PMD can be used as any regular PMD to send / receive packets to the
>  Linux networking stack.
> >>>
> >>> Good move!
> >>> Why not deprecate librte_kni and move all the code in the PMD later?
> >>
> >> +1 to this plan. However, I don't think it all needs to be done in one 
> >> patchset,
> >> though, does it?
> > 
> > I think the deprecation notice must be in this patchset along with some
> > __rte_deprecated in front of librte_kni functions.
> > Then the move of the library in the PMD could be done in the next release.
> > 
> 
> Not sure about deprecating librte_kni, this means existing KNI
> applications needs to be updated. What is the benefit of this effort?
> 
> Also librte_kni supports more than what PMD does, like PMD doesn't have
> ethtool support or binding kernel threads, it uses hardcoded mbuf_size...
> 
> I was thinking PMD as a data only, simplified use case of library.

OK, thanks for the clarification.

[dpdk-dev] [PATCH v2] net/vhost: add pmd xstats

[Yang, Zhiyong]

Hi, Harry:

Your idea looks very good.

Thanks
--Zhiyong
> -Original Message-
> From: Van Haaren, Harry
> Sent: Friday, September 9, 2016 4:41 PM
> To: Yang, Zhiyong ; dev at dpdk.org
> Cc: yuanhan.liu at linux.intel.com; thomas.monjalon at 6wind.com;
> "mailto:pmatilai"@redhat.com; Yang, Zhiyong 
> Subject: RE: [dpdk-dev] [PATCH v2] net/vhost: add pmd xstats
> 
> Hi Zhiyong,
> 
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhiyong Yang
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH v2] net/vhost: add pmd xstats
> >
> > +struct vhost_xstats {
> > +   uint64_t stat[16];
> > +};
> 
> Perhaps we could create an enum to access the stat array?
> 
> enum VHOST_STAT {
>...
>VHOST_STAT_64_PKT,
>...
> };
> 
> > +   {"broadcast_packets",
> > +   offsetof(struct vhost_queue, xstats.stat[8])},
> 
> I think the "magic number" 8 here could be from the enum, and would be
> more clear which statistic is being accessed.
> 
> > +   if (pkt_len == 64) {
> > +   xstats_update->stat[1]++;
> 
> Similarly, incrementing the counters would be more representative if it
> looked like
> 
> xstats_update->stat[VHOST_STAT_64_PKT]++;   /* or similar */
> 
> -Harry

[dpdk-dev] [RFC PATCH v2 0/5] add API's for VF management

[Pattan, Reshma]

Hi Thomas and Ferruh,

Can you take a look and  provide comments on ixgbe driver and ethdev changes.

Thanks,
Reshma

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bernard Iremonger
> Sent: Friday, August 26, 2016 10:10 AM
> To: Shah, Rahul R ; Lu, Wenzhuo
> ; dev at dpdk.org
> Cc: Iremonger, Bernard 
> Subject: [dpdk-dev] [RFC PATCH v2 0/5] add API's for VF management
> 
> This RFC patchset contains new DPDK API's requested by AT&T for use with the
> Virtual Function Daemon (VFD).
> 
> The need to configure and manage VF's on a NIC has grown to the point where
> AT&T have devloped a DPDK based tool, VFD, to do this.
> 
> This RFC proposes to add the following API extensions to DPDK:
>   mailbox communication callback support
>   VF configuration
> 
> Nine new functions have been added to the eth_dev_ops structure.
> Corresponding functions have been added to the ixgbe PMD for the Niantic NIC.
> 
> Two new callback functions have been added.
> Changes have been made to the ixgbe_rcv_msg_from_vf function to use the
> callback functions.
> 
> Changes have been made to testpmd to facilitate testing of the new API's.
> The testpmd documentation has been updated to document the testpmd
> changes.
> 
> Note:
> Adding new functions to the eth_dev_ops structure will cause an ABI breakage.
> 
> Changes in V2:
> rebase to latest master branch.
> fix compile  error with clang.
> 
> Bernard Iremonger (5):
>   librte_ether: add internal callback functions
>   net/ixgbe: add callback to user app on VF to PF mbox msg
>   librte_ether: add API's for VF management
>   net/ixgbe: add functions for VF management
>   app/test_pmd: add tests for new API's
> 
>  app/test-pmd/cmdline.c  | 700 
> 
>  doc/guides/testpmd_app_ug/testpmd_funcs.rst |  68 ++-
>  drivers/net/ixgbe/ixgbe_ethdev.c| 179 +++
>  drivers/net/ixgbe/ixgbe_pf.c|  39 +-
>  lib/librte_ether/rte_ethdev.c   | 176 +++
>  lib/librte_ether/rte_ethdev.h   | 284 +++
>  lib/librte_ether/rte_ether_version.map  |  16 +
>  7 files changed, 1455 insertions(+), 7 deletions(-)
> 
> --
> 2.9.0

[dpdk-dev] [PATCH v2] net/vhost: add pmd xstats

[Van Haaren, Harry]

Hi Zhiyong,

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhiyong Yang
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] net/vhost: add pmd xstats
> 
> +struct vhost_xstats {
> + uint64_t stat[16];
> +};

Perhaps we could create an enum to access the stat array?

enum VHOST_STAT {
   ...
   VHOST_STAT_64_PKT,
   ...
};

> + {"broadcast_packets",
> + offsetof(struct vhost_queue, xstats.stat[8])},

I think the "magic number" 8 here could be from the enum, and would be more 
clear which statistic is being accessed.

> + if (pkt_len == 64) {
> + xstats_update->stat[1]++;

Similarly, incrementing the counters would be more representative if it looked 
like

xstats_update->stat[VHOST_STAT_64_PKT]++;   /* or similar */

-Harry

[dpdk-dev] VLAN of SRIOV VF with DPDK

[Dey, Souvik]

Hi,
  I have having an unique issue to get the VLAN tags upto the VM 
instance running ixgbevf pmd. Currently my setup looks like this :

Host running 7.1 RHEL , linux 3.10.0-229.el7.x86_64 with 10G 82599ES NIC cards 
with firmware : 0x8838 and ixgbe driver version 4.0.1-k-rh7.1

Guest running Debian 7 , linux 3.2.73 with VF attached from the 10G PF. We are 
using DPDK 2.1 on the guest to receive packets and pass it to the linux kernel 
using kni interfaces.

Now, our requirement is to have VLAN come up to the Guest from the outside and 
the Guest should be able to send VLAN packets out too.

We have set hw_vlan_strip to 0 so that the vlan is not stripped by the VF. Also 
we have not configured any VLAN id on the VF, so that the rx vlan filtration is 
not turned on in the HOST.

We have configured only one rx queue and 2 tx queues. With this configuration 
when we send packets from the kernel through kni with VLAN tags , packets are 
getting dropped in the host saying spoofed packets. I have also turned off 
spoofchk off on the VF and then the TX packets were going out. But the RX 
packets were not even reaching the guest.

If I remove my DPDK app and try with normal Debian linux, then we are seeing 
both the TX and RX packets following with proper VLAN tags up to the guest. In 
this case we need not turn of spoofchk on the VF also.

I am performing simple ping test as of now.

Also, I don't see any kni callback when we configure the VLAN on the guest 
which can go down till the Host. I also see that we are not setting the 
software/hardware vfta table at all in the ixgbevf code. Is this required to be 
setup, as I feel the kernel might be doing it .

Any help or pointers to this issue will be of great help.

--
Regards,
Souvik

[dpdk-dev] [PATCH v2] add mtu set in virtio

[Dey, Souvik]

Are we good to get this in for 16.11 and then revisit this when the VHOST 
improvements comes in. This will atleast take care of the gap between 16.11 and 
VHOST improvements coming in.

--
Regards,
Souvik

-Original Message-
From: Yuanhan Liu [mailto:yuanhan@linux.intel.com] 
Sent: Thursday, September 8, 2016 3:57 AM
To: Maxime Coquelin 
Cc: Dey, Souvik ; stephen at networkplumber.org; 
huawei.xie at intel.com; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio

On Thu, Sep 08, 2016 at 09:50:34AM +0200, Maxime Coquelin wrote:
> 
> 
> On 09/08/2016 09:30 AM, Yuanhan Liu wrote:
> >On Wed, Sep 07, 2016 at 11:16:47AM +0200, Maxime Coquelin wrote:
> >>
> >>
> >>On 09/07/2016 05:25 AM, Yuanhan Liu wrote:
> >>>On Tue, Aug 30, 2016 at 09:57:39AM +0200, Maxime Coquelin wrote:
> Hi Souvik,
> 
> On 08/30/2016 01:02 AM, souvikdey33 wrote:
> >Signed-off-by: Souvik Dey 
> >
> >Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey 
> >")
> >Reviewed-by: Stephen Hemminger 
> >
> >Virtio interfaces should also support setting of mtu, as in case 
> >of cloud it is expected to have the consistent mtu across the 
> >infrastructure that the dhcp server sends and not hardcoded to 
> >1500(default).
> >---
> >drivers/net/virtio/virtio_ethdev.c | 12 
> >1 file changed, 12 insertions(+)
> 
> FYI, there are some on-going changes in the VIRTIO specification 
> so that the VHOST interface exposes its MTU to its VIRTIO peer.
> It may also be used as an alternative of what you patch achieves.
> 
> I am working on its implementation in Qemu/DPDK, our goal being to 
> reduce performance drops for small packets with Rx mergeable 
> buffers feature enabled.
> >>>
> >>>Mind to educate me a bit on how that works?
> >>
> >>Of course.
> >>
> >>Basically, this is a way to advise the MTU we want in the guest.
> >>In the guest, if GRO is not enabled:
> >> - In case of Kernel virtio-net, it could be used to size the SKBs 
> >>at the expected MTU. If possible, we could disable Rx mergeable 
> >>buffers.
> >> - In case of virtio PMD, if the MTU advised by host is lower than 
> >>the pre-allocated mbuf size for the receive queue, then we should 
> >>not need mergeable buffers.
> >
> >Thanks for the explanation!
> >
> >I see. So, the point is to avoid using mergeable buffers while it is 
> >enabled.
> >
> >>Does that sound reasonnable?
> >
> >Yeah, maybe. Just don't know how well it may work in real life. Have 
> >you got any rought data so far?
> 
> The PoC is not done yet, only Qemu part is implemented.
> But what we noticed is that for small packets, we have a 50% 
> degradation when rx mergeable buffers are on when running PVP 
> use-case.
> 
> Main part of the degradation is due an additional cache-miss in 
> virtio-pmd receive path, because we fetch the header to get the number 
> of buffer.
> 
> When sending only small packets and removing this access, we recover 
> 25% of the degradation.
> 
> The 25% remaining part may be reduced significantly with Zhihong series.
> 
> Hope it answer your questions.

Yes, it does and thanks for the info.

--yliu

[dpdk-dev] [PATCH] mempool: fix check flags

[Hiroyuki Mikita]

Sorry,
I did not notice the same kind of patch.
I close this patch.

Hiroyuki

2016-09-08 23:46 GMT+09:00 Olivier Matz :
> Hi Hiroki, Ferruh,
>
> On 09/08/2016 04:44 PM, Ferruh Yigit wrote:
>> On 9/8/2016 3:28 PM, Hiroyuki Mikita wrote:
>>> fix check flags in case of single producer and single consumer
>>>
>>> Fixes: 449c49b9 ("mempool: support handler operations")
>>>
>>> Signed-off-by: Hiroyuki Mikita 
>>> ---
>>>  lib/librte_mempool/rte_mempool.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/lib/librte_mempool/rte_mempool.c 
>>> b/lib/librte_mempool/rte_mempool.c
>>> index 2e28e2e..61bd63c 100644
>>> --- a/lib/librte_mempool/rte_mempool.c
>>> +++ b/lib/librte_mempool/rte_mempool.c
>>> @@ -879,7 +879,7 @@ rte_mempool_create(const char *name, unsigned n, 
>>> unsigned elt_size,
>>>   * Since we have 4 combinations of the SP/SC/MP/MC examine the flags to
>>>   * set the correct index into the table of ops structs.
>>>   */
>>> -if (flags & (MEMPOOL_F_SP_PUT | MEMPOOL_F_SC_GET))
>>> +if ((flags & MEMPOOL_F_SP_PUT) & (flags & MEMPOOL_F_SC_GET))
>>
>> Isn't this always false?
>>
>> What about:
>> if ((flags & MEMPOOL_F_SP_PUT) && (flags & MEMPOOL_F_SC_GET))
>>
>>>  rte_mempool_set_ops_byname(mp, "ring_sp_sc", NULL);
>>>  else if (flags & MEMPOOL_F_SP_PUT)
>>>  rte_mempool_set_ops_byname(mp, "ring_sp_mc", NULL);
>>>
>>
>
> Looks the same kind of patch was posted few hours before:
> http://dpdk.org/dev/patchwork/patch/15686/
>
> Regards,
> Olivier