[dpdk-dev] [PATCH v4 12/12] examples/l3fwd: add option to parse ptype

2016-02-26 Thread Tan, Jianfeng
Hi Konstantin,

On 2/26/2016 9:14 PM, Ananyev, Konstantin wrote:
> Hi Jianfeng,
>
>> +static int
...
>> +if (hdr_len == sizeof(struct ipv4_hdr) &&
>> +(hdr->next_proto_id == 6 ||
>> + hdr->next_proto_id == 17))
> Use IPPORTO_UDP, IPPORTO_TCP instead of hardcoded values.

Yes, will fix it.

>> +packet_type |= RTE_PTYPE_L3_IPV4;
>> +}
> Actually it is a good point:
> for EM case should l3fwd process only TCP/UDP packets?
> If yes, then it needs to check not only L3, but also L4 type too
> Which means that for EM and LPM check_packet_type_ok() should also be 
> different.
> Or we can leave it as it is - in that case EM even for non UDP/TCP packet 
> would still
> do route  lookup using first 4B of L3 payload.

I'd like to follow the first approach, (if nobody strongly objects to 
it), because it's EM's real intention to use 5 tuples.

> If you choose first approach, then there is another thing to consider -
> there are 2 patches in flight for l3fwd:
> http://dpdk.org/dev/patchwork/patch/10800/
> http://dpdk.org/dev/patchwork/patch/10782/
>
> Which makes LPM/EM choice for l3fwd a runtime decision.
> So  APP_LOOKUP_METHOD macro would not be available after it.
> Probably need to take that into account for your changes.
> Might be exclude l3fwd from this patch series, then rebase it
> on these patches and submit as a separate one?

Thanks for reminding me of this. And that sounds a good idea to me. This 
commit will be excluded and submitted as a separate one.

>> +#elif (APP_LOOKUP_METHOD == APP_LOOKUP_LPM)
>> +packet_type |= RTE_PTYPE_L3_IPV4_EXT_UNKNOWN;
>> +#endif
>> +break;
>> +case ETHER_TYPE_IPv6:
>> +#if (APP_LOOKUP_METHOD == APP_LOOKUP_EXACT_MATCH)
>> +{
>> +struct ipv6_hdr *hdr;
>> +
>> +hdr = (struct ipv6_hdr *)((uint8_t *)eth_hdr +
>> +  sizeof(struct ether_hdr));
>> +if (hdr->proto == 6 || hdr->proto == 17)
>> +packet_type |= RTE_PTYPE_L3_IPV4;
> s/ RTE_PTYPE_L3_IPV4/RTE_PTYPE_L3_IPV6/
> ?

Oops, nice catch. Will fix it.

Thanks,
Jianfeng

> Apart from that the series looks good to me.
> Konstantin
>



[dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding

2016-02-26 Thread Thomas Monjalon
2016-02-26 09:24, Wang, Xiao W:
> Hi,
> 
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Friday, February 26, 2016 5:06 PM
> > To: Wang, Xiao W 
> > Cc: Richardson, Bruce ; Chen, Jing D
> > ; dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
> > 
> > 2016-02-26 04:31, Wang, Xiao W:
> > > From: Richardson, Bruce
> > > > On Thu, Feb 25, 2016 at 03:45:45PM +, Chen, Jing D wrote:
> > > > > From: Richardson, Bruce
> > > > > > On Thu, Feb 25, 2016 at 10:04:02AM +, Chen, Jing D wrote:
> > > > > > > This feature is trying to use FTAG (a unique tech in fm10k)
> > > > > > > instead of mac/vlan to forward packets. App need a way to tell
> > > > > > > PMD driver that which forwarding style it would like to use.
> > > > > >
> > > > > > Why not just specify this in the port configuration at setup time?
> > > > > >
> > > > >
> > > > > Please educate me. I think the port configuration flags are also
> > > > > common to all PMD Drivers. Is it possible to add a flag like
> > "RTE_USE_FTAG"
> > > > and pass to PMD driver?
> > > > >
> > > > They are.
> > > > For something PMD specific, like FTAG, it's always a challenge, and
> > > > I don't know off the top of my head if there is a simple option.
> > > > However, given the choice between an mbuf flag and a port config
> > > > flag, I'd always choose the former.
> > > > Other alternatives would be to have a fm10k specific API in the
> > > > fm10k driver alone.
> > > >
> > > > I'll let Thomas as ethdev maintainer comment if he has other
> > > > suggestions as to how to handle this case. I suspect this won't be
> > > > the first device-specific piece of functionality we need to deal with.
> > > >
> > > > /Bruce
> > >
> > > Whatever method we choose, we have to find a way for the user to
> > > express his need for FTAG, it maybe a build time config option, or a
> > > port config flag (no such flag now), or a fast path flag in mbuf (no
> > > such flag now) etc. For the customer Topsec's use case, they use FTAG
> > > for all the TX packets, so all the above methods (per build config,
> > > per port config, per mbuf config) can meet their need. Since the pmd
> > > frame work is for common, it's hard to add new fields only for one 
> > > specific
> > NIC, so I add a build time config and make an introduction in the doc.
> > >
> > > Thanks for the discussion, Thomas, do you have any suggestions?
> > 
> > I don't understand why you say this feature is specific to fm10k. Can we
> > imagine another NIC having this capability?
> 
> As you know, fm10k has a switch logic between the Mac and Phy, every packets
> Sent out from the host will be switched inside the NIC, other NICs don't have
> a switch inside, and the FTAG feature is related to the switch function.
> 
> As introduced in the second patch:
> The FM10K family of NICs support the addition of a Fabric Tag (FTAG) to carry
> special information. The FTAG is placed at the beginning of the frame, it 
> contains
> information such as where the packet comes from and goes, and the vlan tag. In
> FTAG based forwarding mode, the switch logic forwards packets according to
> glort (global resource tag) information, rather than the mac and vlan table.
> So this is a feature specific to fm10k.

No I still don't think you should consider it specific to fm10k.
But yes it is specific to a switch device.
I'm OK to have a structure for switch configuration in ethdev.


[dpdk-dev] [PATCH] i40e: Fix a typo.

2016-02-26 Thread Rami Rosen
This patch fixes a typo in a comment in the definition of
the i40e_pf struct.

Signed-off-by: Rami Rosen 
---
 drivers/net/i40e/i40e_ethdev.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 6edd7dd..8ebac9d 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -408,7 +408,7 @@ struct i40e_pf {

struct rte_eth_dev_data *dev_data; /* Pointer to the device data */
struct ether_addr dev_addr; /* PF device mac address */
-   uint64_t flags; /* PF featuer flags */
+   uint64_t flags; /* PF feature flags */
/* All kinds of queue pair setting for different VSIs */
struct i40e_pf_vf *vfs;
uint16_t vf_num;
-- 
2.5.0



[dpdk-dev] Virtio xstats problem

2016-02-26 Thread Igor Ryzhov
Sent a patch: http://dpdk.org/dev/patchwork/patch/10887/ 
.

> 26 . 2016 ?., ? 17:35, Igor Ryzhov  ???(?):
> 
> Hello, Harry.
> 
> Understood about size of packets. It's a bit confusing, because in all other 
> drivers undersized packet is an error. Maybe we should add another one size 
> bin for virtio - 60 to 63 bytes?
> 
> I already checked about multicast/broadcast counters - broadcast packets are 
> counted twice:
> 
>   vq->multicast += is_multicast_ether_addr(ea);
>   vq->broadcast += is_broadcast_ether_addr(ea);
> 
> I think it should be something like:
> 
>   if (is_multicast_ether_addr(ea)) {
>   if (is_broadcast_ether_addr(ea)) {
>   vq->broadcast++;
>   } else {
>   vq->multicast++;
>   }
>   }
> 
> Best regards,
> Igor
> 
>> 26 . 2016 ?., ? 17:29, Van Haaren, Harry  
>> ???(?):
>> 
>>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Igor Ryzhov
>>> I found some problem with virtio xstats counters.
>>> 
>>> Example:
>>> 
>>> rx_good_packets: 3
>>> rx_good_bytes: 180
>>> rx_errors: 0
>>> 
>>> rx_q0_good_packets: 3
>>> rx_q0_good_bytes: 180
>>> rx_q0_errors: 0
>>> 
>>> rx_q0_multicast_packets: 3
>>> rx_q0_broadcast_packets: 1
>>> rx_q0_undersize_packets: 3
>> 
>>> It means that undersize packets are counted as good packets instead of 
>>> errors.
>> 
>> Are you sending 64 byte packets? There are no 4 bytes of CRC on virtual
>> interfaces, so 60 bytes per packet is OK.
>> 
>>> Or maybe
>>> size of packet is calculated wrong.
>>> I don't have time now to check it more deeply - I can do it sometime later, 
>>> but maybe
>>> someone want to help.
>> 
>> Are the packets multicast or broadcast?
>> It looks like one of the counters there is wrong.
>> 
>>> PS. Is it a common practice to count broadcast packets twice - in broadcast 
>>> and multicast
>>> counters?
>> 
>> No packet should be counted twice - it must be put into one bucket of mutli, 
>> broad or unicast.
>> 
>> -Harry
> 



[dpdk-dev] [PATCH] virtio: don't count broadcast packets in multicast packets counter

2016-02-26 Thread Igor Ryzhov
Signed-off-by: Igor Ryzhov 
---
 drivers/net/virtio/virtio_rxtx.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 41a1366..fe18e1d 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -543,8 +543,13 @@ virtio_update_packet_stats(struct virtqueue *vq, struct 
rte_mbuf *mbuf)
}

ea = rte_pktmbuf_mtod(mbuf, struct ether_addr *);
-   vq->multicast += is_multicast_ether_addr(ea);
-   vq->broadcast += is_broadcast_ether_addr(ea);
+   if (is_multicast_ether_addr(ea)) {
+   if (is_broadcast_ether_addr(ea)) {
+   vq->broadcast++;
+   } else {
+   vq->multicast++;
+   }
+   }
 }

 #define VIRTIO_MBUF_BURST_SZ 64
-- 
2.6.4



[dpdk-dev] [PATCH 0/2] bonding fixes

2016-02-26 Thread Bruce Richardson
On Mon, Feb 22, 2016 at 01:20:18PM +, Doherty, Declan wrote:
> > -Original Message-
> > From: Iremonger, Bernard
> > Sent: Wednesday, February 10, 2016 10:14 AM
> > To: dev at dpdk.org
> > Cc: Doherty, Declan ; Iremonger, Bernard
> > 
> > Subject: [PATCH 0/2] bonding fixes
> > 
> > These patches fix segmentation faults which were occurring when
> > slave devices were detached before being removed from the bonding
> > device.
> > The slave devices must now be removed from the bonding device
> > before they can be detached.
> > The bonding device cannot be detached now until all slave devices
> > have been removed from it.
> > 
> > Bernare Iremonger (2):
> >   bonding: fix detach of bonded device
> >   bonding: fix detach of bonded slave devices
> > 
> >  drivers/net/bonding/rte_eth_bond_api.c | 40 
> > +++-
> > --
> >  lib/librte_ether/rte_ethdev.c  |  8 +--
> >  lib/librte_ether/rte_ethdev.h  |  4 +++-
> >  3 files changed, 26 insertions(+), 26 deletions(-)
> > 
> > --
> > 2.6.3
> 
> Series Acked-by: Declan Doherty 

Applied to dpdk-next-net/rel_16_04

/Bruce



[dpdk-dev] client_server example application crash with virtio

2016-02-26 Thread Kyle Larose
Hrm. This may not be correct. It looks like there is some interaction between 
the primary and secondary here. vtpci_ops must be in shared memory. When I 
initialize my secondary, it overwrites the primary's with its address. I just 
checked, and without my patch, the secondary's vtpci_ops points to the location 
in the primary's address space:

In the primary:
EAL:   Not managed by a supported kernel driver, skipped
EAL: PCI Port IO found start=0xc060
>>>Initialized to ops: 0x59f6e0
EAL: PCI device :00:07.0 on NUMA socket -1
EAL:   probe driver: 1af4:1000 rte_virtio_pmd
EAL:   Device is blacklisted, not initializing

In the secondary:
(gdb) p vq->hw->vtpci_ops
$1 = (const struct virtio_pci_ops *) 0x59f6e0

It's not clear to me offhand how to resolve this. Unless the code to which the 
ops points is loaded at the exact same memory location, you need different ops 
pointers.

-Original Message-
From: Kyle Larose 
Sent: Friday, February 26, 2016 11:47 AM
To: 'dev at dpdk.org'
Subject: client_server example application crash with virtio

I just ran into an issue trying to run the client server example application 
using virito. Whenever the client (running as a secondary process) tried to 
send packets, it would crash. I traced the issue to an invalid vtpci_ops 
structure:

(gdb) p *vq->hw->vtpci_ops
$6 = {
  read_dev_cfg = 0x756d2073726f7470,
  write_dev_cfg = 0x6562206562207473,
  reset = 0x6425206e65657774,
  get_status = 0x20642520646e6120,
  set_status = 0x766973756c636e69,
  get_features = 0x7561666544202e65,
  set_features = 0xa5d64255b20746c,
  get_isr = 0x0,
  set_config_irq = 0x657472203a444d50,
  get_queue_num = 0x705f65626778635f,
  setup_queue = 0x203a7325203a646d,
  del_queue = 0x20746b702078616d,
  notify_queue = 0x7473756d206e656c
}

It looks like this is not being initialized in secondary processes, because we 
short-circuit the ethdev init here, before we call vtpci_init.

if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
rx_func_get(eth_dev);
return 0;
}

Has  anyone submitted a patch to fix this?

I found that the following seemed to make it work, though I'm not sure it's 
appropriate. I can submit it as a patch if nobody else has done so yet. (I'd 
clean it up to return an error code if the init fails).

git diff drivers/net/virtio/virtio_ethdev.c
diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index caa970c..5002847 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1002,6 +1002,8 @@ rx_func_get(struct rte_eth_dev *eth_dev)
eth_dev->rx_pkt_burst = _recv_mergeable_pkts;
else
eth_dev->rx_pkt_burst = _recv_pkts;
+
+vtpci_init(eth_dev->pci_dev, (struct 
virtio_hw*)eth_dev->data->dev_private);
 }

 /*

Thanks,

Kyle


[dpdk-dev] [PATCH v3] driver/net/mpipe: fix the crash/hung issue when testpmd quits

2016-02-26 Thread Bruce Richardson
On Wed, Feb 10, 2016 at 12:15:21AM -0500, Liming Sun wrote:
> Fixes: the hung/crash issue when quitting testpmd under high
> traffic rate. The following issue were found and fixed.
> 1. edesc->size is not initialized properly in mpipe_do_xmit() and could
>cause buffer leak or corruption when HW buffer return is used.
> 2. Check the 'idesc.be' error bit in mpipe_recv_flush() to make sure
>buffer is valid before releasing it. This is to avoid issues when
>running out of buffers.
> 3. priv->rx_buffers counter is not accurate when HW buffer return is
>used. Remove this counter to simplify the code.
> 
> Signed-off-by: Liming Sun 
> Acked-by: Zhigang Lu 
> ---

Applied to dpdk-next-net/rel_16_04

/Bruce



[dpdk-dev] [PATCH v9 0/2] Add VHOST PMD

2016-02-26 Thread Tetsuya Mukawa
On 2016/02/26 13:29, Tetsuya Mukawa wrote:
> On 2016/02/25 16:51, Qiu, Michael wrote:
>> On 2/24/2016 1:10 PM, Tetsuya Mukawa wrote:
>>> On 2016/02/24 11:45, Qiu, Michael wrote:
 Hi,  Tetsuya

 When I applied your v6 patch, I could reach 9.5Mpps with 64B packet.

 But when apply v9 only 8.4 Mpps, could you figure out why has
 performance drop?
>>> Hi Michael,
>>>
>>> Thanks for checking it.
>>> I tried to re-produce it, but I don't see the drop on my environment.
>>> (My cpu is Xeon E5-2697-v2, and the performances of v6 and v9 patch are
>>> almost 5.9Mpps)
>>> Did you use totally same code except for vhost PMD?
>> Yes, totally same code and same platform, only difference is versions of
>> vhost PMD.
>>
>> BTW, I have set the frontend mergeable off.
> I have checked below cases.
>  - Case1: Disable mergeable feature in virtio-net PMD.
>  - Case2: Disable mergeable feature in virtio-net PMD and use
> '--txqflags=0xf01' option to use simple ring deploying.
> Both cases,  I still cannot see the drop.
>
> Anyway, I will send a few patch-series to determine the cause of drop.
> So, could you please apply them and check the performance to determine
> which cause the drop?

Hi Michael,

I may find what causes the drop.
Could you please restart testpmd on guest when you see the drop, then
check performance again?

I guess the drop will occur only first time when testpmd on guest and
host is connected.
Here are rough steps.

1. Start testpmd on host
2. Start QEMU
3. Start testpmd on guest

Then you will see the drop.
Probably, if testpmd on guest is restarted, then you don't see the drop
again.

4. Type 'quit' on guest.
5. Start testpmd on guest again.

If so, I guess the drop is caused by queue notifying.
Could you please let me know whether your issue is above case?

Thanks,
Tetsuya

> Thanks,
> Tetsuya
>
>> Thanks,
>> Michael
>>> Thanks,
>>> Tetsuya
>>>
 Thanks,
 Michael
 On 2/9/2016 5:38 PM, Tetsuya Mukawa wrote:
> The patch introduces a new PMD. This PMD is implemented as thin wrapper
> of librte_vhost.
>
>
> PATCH v9 changes:
>  - Fix a null pointer access issue implemented in v8 patch.
>
> PATCH v8 changes:
>  - Manage ether devices list instead of internal structures list.
>  - Remove needless NULL checking.
>  - Replace "pthread_exit" to "return NULL".
>  - Replace rte_panic to RTE_LOG, also add error handling.
>  - Remove duplicated lines.
>  - Remove needless casting.
>  - Follow coding style.
>  - Remove needless parenthesis.
>
> PATCH v7 changes:
>  - Remove needless parenthesis.
>  - Add release note.
>  - Remove needless line wraps.
>  - Add null pointer check in vring_state_changed().
>  - Free queue memory in eth_queue_release().
>  - Fix wrong variable name.
>  - Fix error handling code of eth_dev_vhost_create() and
>rte_pmd_vhost_devuninit().
>  - Remove needless null checking from rte_pmd_vhost_devinit/devuninit().
>  - Use port id to create mac address.
>  - Add doxygen style comments in "rte_eth_vhost.h".
>  - Fix wrong comment in "mk/rte.app.mk".
>
> PATCH v6 changes:
>  - Remove rte_vhost_driver_pmd_callback_registe().
>  - Support link status interrupt.
>  - Support queue state changed interrupt.
>  - Add rte_eth_vhost_get_queue_event().
>  - Support numa node detection when new device is connected.
>
> PATCH v5 changes:
>  - Rebase on latest master.
>  - Fix RX/TX routine to count RX/TX bytes.
>  - Fix RX/TX routine not to count as error packets if enqueue/dequeue
>cannot send all packets.
>  - Fix if-condition checking for multiqueues.
>  - Add "static" to pthread variable.
>  - Fix format.
>  - Change default behavior not to receive queueing event from driver.
>  - Split the patch to separate rte_eth_vhost_portid2vdev().
>
> PATCH v4 changes:
>  - Rebase on latest DPDK tree.
>  - Fix cording style.
>  - Fix code not to invoke multiple messaging handling threads.
>  - Fix code to handle vdev parameters correctly.
>  - Remove needless cast.
>  - Remove needless if-condition before rt_free().
>
> PATCH v3 changes:
>  - Rebase on latest matser
>  - Specify correct queue_id in RX/TX function.
>
> PATCH v2 changes:
>  - Remove a below patch that fixes vhost library.
>The patch was applied as a separate patch.
>- vhost: fix crash with multiqueue enabled
>  - Fix typos.
>(Thanks to Thomas, Monjalon)
>  - Rebase on latest tree with above bernard's patches.
>
> PATCH v1 changes:
>  - Support vhost multiple queues.
>  - Rebase on "remove pci driver from vdevs".
>  - Optimize RX/TX functions.
>  - Fix resource leaks.
>  - Fix compile issue.
>  - Add patch to fix vhost library.
>
> RFC PATCH v3 changes:
>  - Optimize performance.

[dpdk-dev] Virtio xstats problem

2016-02-26 Thread Igor Ryzhov
Hello, Harry.

Understood about size of packets. It's a bit confusing, because in all other 
drivers undersized packet is an error. Maybe we should add another one size bin 
for virtio - 60 to 63 bytes?

I already checked about multicast/broadcast counters - broadcast packets are 
counted twice:

vq->multicast += is_multicast_ether_addr(ea);
vq->broadcast += is_broadcast_ether_addr(ea);

I think it should be something like:

if (is_multicast_ether_addr(ea)) {
if (is_broadcast_ether_addr(ea)) {
vq->broadcast++;
} else {
vq->multicast++;
}
}

Best regards,
Igor

> 26 . 2016 ?., ? 17:29, Van Haaren, Harry  
> ???(?):
> 
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Igor Ryzhov
>> I found some problem with virtio xstats counters.
>> 
>> Example:
>> 
>> rx_good_packets: 3
>> rx_good_bytes: 180
>> rx_errors: 0
>> 
>> rx_q0_good_packets: 3
>> rx_q0_good_bytes: 180
>> rx_q0_errors: 0
>> 
>> rx_q0_multicast_packets: 3
>> rx_q0_broadcast_packets: 1
>> rx_q0_undersize_packets: 3
> 
>> It means that undersize packets are counted as good packets instead of 
>> errors.
> 
> Are you sending 64 byte packets? There are no 4 bytes of CRC on virtual
> interfaces, so 60 bytes per packet is OK.
> 
>> Or maybe
>> size of packet is calculated wrong.
>> I don't have time now to check it more deeply - I can do it sometime later, 
>> but maybe
>> someone want to help.
> 
> Are the packets multicast or broadcast?
> It looks like one of the counters there is wrong.
> 
>> PS. Is it a common practice to count broadcast packets twice - in broadcast 
>> and multicast
>> counters?
> 
> No packet should be counted twice - it must be put into one bucket of mutli, 
> broad or unicast.
> 
> -Harry



[dpdk-dev] [PATCH v3 2/2] cryptodev: change burst API to be crypto op oriented

2016-02-26 Thread Declan Doherty
This patch modifies the crypto burst enqueue/dequeue APIs to operate on bursts
rte_crypto_op's rather than the current implementation which operates on
rte_mbuf bursts, this simplifies the burst processing in the crypto PMDs and the
use of crypto operations in general.

The changes also continues the separatation of the symmetric operation 
parameters
from the more general operation parameters, this will simplify the integration 
of
asymmetric crypto operations in the future.

As well as the changes to the crypto APIs this patch adds functions for managing
rte_crypto_op pools to the cryptodev API. It modifies the existing PMDs, unit
tests and sample application to work with the modified APIs and finally
removes the now unused rte_mbuf_offload library.

Signed-off-by: Declan Doherty 
---
 MAINTAINERS|   6 +-
 app/test/test_cryptodev.c  | 804 +++--
 app/test/test_cryptodev.h  |   9 +-
 app/test/test_cryptodev_perf.c | 253 +++
 config/common_bsdapp   |   8 -
 config/common_linuxapp |   8 -
 doc/api/doxy-api-index.md  |   1 -
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 171 +++--
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  12 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h |   2 +-
 drivers/crypto/qat/qat_crypto.c| 123 ++--
 drivers/crypto/qat/qat_crypto.h|  12 +-
 drivers/crypto/qat/rte_qat_cryptodev.c |   4 +-
 examples/l2fwd-crypto/main.c   | 283 
 lib/Makefile   |   1 -
 lib/librte_cryptodev/rte_crypto.h  | 367 +-
 lib/librte_cryptodev/rte_crypto_sym.h  | 377 +-
 lib/librte_cryptodev/rte_cryptodev.c   |  76 ++
 lib/librte_cryptodev/rte_cryptodev.h   | 109 ++-
 lib/librte_cryptodev/rte_cryptodev_version.map |   3 +-
 lib/librte_mbuf/rte_mbuf.h |   6 -
 lib/librte_mbuf_offload/Makefile   |  52 --
 lib/librte_mbuf_offload/rte_mbuf_offload.c | 100 ---
 lib/librte_mbuf_offload/rte_mbuf_offload.h | 310 
 .../rte_mbuf_offload_version.map   |   7 -
 25 files changed, 1577 insertions(+), 1527 deletions(-)
 delete mode 100644 lib/librte_mbuf_offload/Makefile
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload.c
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload.h
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index 628bc05..ad6b45e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -222,16 +222,12 @@ F: lib/librte_mbuf/
 F: doc/guides/prog_guide/mbuf_lib.rst
 F: app/test/test_mbuf.c

-Packet buffer offload - EXPERIMENTAL
-M: Declan Doherty 
-F: lib/librte_mbuf_offload/
-
 Ethernet API
 M: Thomas Monjalon 
 F: lib/librte_ether/
 F: scripts/test-null.sh

-Crypto API - EXPERIMENTAL
+Crypto API
 M: Declan Doherty 
 F: lib/librte_cryptodev/
 F: app/test/test_cryptodev*
diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 951b443..e3d40d5 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -35,7 +35,6 @@
 #include 
 #include 
 #include 
-#include 

 #include 
 #include 
@@ -48,7 +47,7 @@ static enum rte_cryptodev_type gbl_cryptodev_type;

 struct crypto_testsuite_params {
struct rte_mempool *mbuf_pool;
-   struct rte_mempool *mbuf_ol_pool;
+   struct rte_mempool *op_mpool;
struct rte_cryptodev_config conf;
struct rte_cryptodev_qp_conf qp_conf;

@@ -62,8 +61,7 @@ struct crypto_unittest_params {

struct rte_cryptodev_sym_session *sess;

-   struct rte_mbuf_offload *ol;
-   struct rte_crypto_sym_op *op;
+   struct rte_crypto_op *op;

struct rte_mbuf *obuf, *ibuf;

@@ -104,7 +102,7 @@ setup_test_string(struct rte_mempool *mpool,
return m;
 }

-#if HEX_DUMP
+#ifdef HEX_DUMP
 static void
 hexdump_mbuf_data(FILE *f, const char *title, struct rte_mbuf *m)
 {
@@ -112,27 +110,29 @@ hexdump_mbuf_data(FILE *f, const char *title, struct 
rte_mbuf *m)
 }
 #endif

-static struct rte_mbuf *
-process_crypto_request(uint8_t dev_id, struct rte_mbuf *ibuf)
+static struct rte_crypto_op *
+process_crypto_request(uint8_t dev_id, struct rte_crypto_op *op)
 {
-   struct rte_mbuf *obuf = NULL;
-#if HEX_DUMP
+#ifdef HEX_DUMP
hexdump_mbuf_data(stdout, "Enqueued Packet", ibuf);
 #endif

-   if (rte_cryptodev_enqueue_burst(dev_id, 0, , 1) != 1) {
+   if (rte_cryptodev_enqueue_burst(dev_id, 0, , 1) != 1) {
printf("Error sending packet for encryption");
return NULL;
}
-   while (rte_cryptodev_dequeue_burst(dev_id, 0, , 1) == 0)
+
+   op = NULL;
+
+   while (rte_cryptodev_dequeue_burst(dev_id, 0, , 1) 

[dpdk-dev] [PATCH v3 1/2] cryptodev: API tidy and changes to support future extensions

2016-02-26 Thread Declan Doherty
From: Fiona Trahe 

This patch splits symmetric specific definitions and functions away from the
common crypto APIs to facilitate the future extension and expansion of the
cryptodev framework, in order to allow  asymmetric crypto operations to be
introduced at a later date, as well as to clean the logical structure of the
public includes. The patch also introduces the _sym prefix to symmetric
specific structure and functions to improve clarity in the API.

Signed-off-by: Fiona Trahe 
Signed-off-by: Declan Doherty 
---
 app/test/test_cryptodev.c  | 164 +++---
 app/test/test_cryptodev_perf.c |  79 +--
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c |  44 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |   6 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h |   4 +-
 drivers/crypto/qat/qat_crypto.c|  51 +-
 drivers/crypto/qat/qat_crypto.h|  10 +-
 drivers/crypto/qat/rte_qat_cryptodev.c |   8 +-
 examples/l2fwd-crypto/main.c   |  33 +-
 lib/librte_cryptodev/Makefile  |   1 +
 lib/librte_cryptodev/rte_crypto.h  | 563 +--
 lib/librte_cryptodev/rte_crypto_sym.h  | 613 +
 lib/librte_cryptodev/rte_cryptodev.c   |  39 +-
 lib/librte_cryptodev/rte_cryptodev.h   |  80 ++-
 lib/librte_cryptodev/rte_cryptodev_pmd.h   |  32 +-
 lib/librte_mbuf_offload/rte_mbuf_offload.h |  22 +-
 16 files changed, 912 insertions(+), 837 deletions(-)
 create mode 100644 lib/librte_cryptodev/rte_crypto_sym.h

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 62f8fb0..951b443 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2015-2016 Intel Corporation. All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
  *   modification, are permitted provided that the following conditions
@@ -57,13 +57,13 @@ struct crypto_testsuite_params {
 };

 struct crypto_unittest_params {
-   struct rte_crypto_xform cipher_xform;
-   struct rte_crypto_xform auth_xform;
+   struct rte_crypto_sym_xform cipher_xform;
+   struct rte_crypto_sym_xform auth_xform;

-   struct rte_cryptodev_session *sess;
+   struct rte_cryptodev_sym_session *sess;

struct rte_mbuf_offload *ol;
-   struct rte_crypto_op *op;
+   struct rte_crypto_sym_op *op;

struct rte_mbuf *obuf, *ibuf;

@@ -78,7 +78,7 @@ test_AES_CBC_HMAC_SHA512_decrypt_create_session_params(
struct crypto_unittest_params *ut_params);

 static int
-test_AES_CBC_HMAC_SHA512_decrypt_perform(struct rte_cryptodev_session *sess,
+test_AES_CBC_HMAC_SHA512_decrypt_perform(struct rte_cryptodev_sym_session 
*sess,
struct crypto_unittest_params *ut_params,
struct crypto_testsuite_params *ts_param);

@@ -165,7 +165,8 @@ testsuite_setup(void)
ts_params->mbuf_ol_pool = rte_pktmbuf_offload_pool_create(
"MBUF_OFFLOAD_POOL",
NUM_MBUFS, MBUF_CACHE_SIZE,
-   DEFAULT_NUM_XFORMS * sizeof(struct rte_crypto_xform),
+   DEFAULT_NUM_XFORMS *
+   sizeof(struct rte_crypto_sym_xform),
rte_socket_id());
if (ts_params->mbuf_ol_pool == NULL) {
RTE_LOG(ERR, USER1, "Can't create CRYPTO_OP_POOL\n");
@@ -220,7 +221,7 @@ testsuite_setup(void)

ts_params->conf.nb_queue_pairs = info.max_nb_queue_pairs;
ts_params->conf.socket_id = SOCKET_ID_ANY;
-   ts_params->conf.session_mp.nb_objs = info.max_nb_sessions;
+   ts_params->conf.session_mp.nb_objs = info.sym.max_nb_sessions;

TEST_ASSERT_SUCCESS(rte_cryptodev_configure(dev_id,
_params->conf),
@@ -275,7 +276,7 @@ ut_setup(void)
ts_params->conf.nb_queue_pairs = DEFAULT_NUM_QPS_PER_QAT_DEVICE;
ts_params->conf.socket_id = SOCKET_ID_ANY;
ts_params->conf.session_mp.nb_objs =
-   (gbl_cryptodev_type == RTE_CRYPTODEV_QAT_PMD) ?
+   (gbl_cryptodev_type == RTE_CRYPTODEV_QAT_SYM_PMD) ?
DEFAULT_NUM_OPS_INFLIGHT :
DEFAULT_NUM_OPS_INFLIGHT;

@@ -319,7 +320,7 @@ ut_teardown(void)

/* free crypto session structure */
if (ut_params->sess) {
-   rte_cryptodev_session_free(ts_params->valid_devs[0],
+   rte_cryptodev_sym_session_free(ts_params->valid_devs[0],
ut_params->sess);
ut_params->sess = NULL;
}
@@ -464,7 +465,7 @@ 

[dpdk-dev] [PATCH v3 0/2] cryptodev API changes

2016-02-26 Thread Declan Doherty
This patch set separates the symmetric crypto operations from generic operations
and then modifies the cryptodev burst API to accept bursts of rte_crypto_op
rather than rte_mbufs.

V3:
 - Addresses V2 comments
 - Rebased for head

Declan Doherty (1):
  cryptodev: change burst API to be crypto op oriented

Fiona Trahe (1):
  cryptodev: API tidy and changes to support future extensions

 MAINTAINERS|   6 +-
 app/test/test_cryptodev.c  | 894 +++--
 app/test/test_cryptodev.h  |   9 +-
 app/test/test_cryptodev_perf.c | 270 ---
 config/common_bsdapp   |   8 -
 config/common_linuxapp |   8 -
 doc/api/doxy-api-index.md  |   1 -
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 199 ++---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  18 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h |   6 +-
 drivers/crypto/qat/qat_crypto.c| 150 ++--
 drivers/crypto/qat/qat_crypto.h|  14 +-
 drivers/crypto/qat/rte_qat_cryptodev.c |   8 +-
 examples/l2fwd-crypto/main.c   | 300 ---
 lib/Makefile   |   1 -
 lib/librte_cryptodev/Makefile  |   1 +
 lib/librte_cryptodev/rte_crypto.h  | 822 ---
 lib/librte_cryptodev/rte_crypto_sym.h  | 642 +++
 lib/librte_cryptodev/rte_cryptodev.c   | 115 ++-
 lib/librte_cryptodev/rte_cryptodev.h   | 185 ++---
 lib/librte_cryptodev/rte_cryptodev_pmd.h   |  32 +-
 lib/librte_cryptodev/rte_cryptodev_version.map |   3 +-
 lib/librte_mbuf/rte_mbuf.h |   6 -
 lib/librte_mbuf_offload/Makefile   |  52 --
 lib/librte_mbuf_offload/rte_mbuf_offload.c | 100 ---
 lib/librte_mbuf_offload/rte_mbuf_offload.h | 310 ---
 .../rte_mbuf_offload_version.map   |   7 -
 27 files changed, 2146 insertions(+), 2021 deletions(-)
 create mode 100644 lib/librte_cryptodev/rte_crypto_sym.h
 delete mode 100644 lib/librte_mbuf_offload/Makefile
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload.c
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload.h
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload_version.map

-- 
2.5.0



[dpdk-dev] [PATCH v2] e1000: enable promiscuous and allmulticast support for VF

2016-02-26 Thread Bruce Richardson
On Tue, Feb 16, 2016 at 12:43:38AM +, Lu, Wenzhuo wrote:
> Hi Yury,
> 
> Acked-by: Wenzhuo Lu 
> 
Applied to dpdk-next-net/rel_16_04

/Bruce


[dpdk-dev] [PATCH v4 3/3] null: remove duplicate fields in internal data struct

2016-02-26 Thread Ferruh Yigit
1- remove duplicate nb_rx/tx_queues fields from internals
2- remove duplicate numa_node field from internals

Signed-off-by: Ferruh Yigit 
Tested-by: Tetsuya Mukawa 
Acked-by: Tetsuya Mukawa 
Acked-by: Nicolas Pernas Maradei 
---
 drivers/net/null/rte_eth_null.c | 36 
 1 file changed, 12 insertions(+), 24 deletions(-)

diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 77fc988..1c354ad 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -69,10 +69,6 @@ struct null_queue {
 struct pmd_internals {
unsigned packet_size;
unsigned packet_copy;
-   unsigned numa_node;
-
-   unsigned nb_rx_queues;
-   unsigned nb_tx_queues;

struct null_queue rx_null_queues[RTE_MAX_QUEUES_PER_PORT];
struct null_queue tx_null_queues[RTE_MAX_QUEUES_PER_PORT];
@@ -192,13 +188,8 @@ eth_null_copy_tx(void *q, struct rte_mbuf **bufs, uint16_t 
nb_bufs)
 }

 static int
-eth_dev_configure(struct rte_eth_dev *dev) {
-   struct pmd_internals *internals;
-
-   internals = dev->data->dev_private;
-   internals->nb_rx_queues = dev->data->nb_rx_queues;
-   internals->nb_tx_queues = dev->data->nb_tx_queues;
-
+eth_dev_configure(struct rte_eth_dev *dev __rte_unused)
+{
return 0;
 }

@@ -237,7 +228,7 @@ eth_rx_queue_setup(struct rte_eth_dev *dev, uint16_t 
rx_queue_id,

internals = dev->data->dev_private;

-   if (rx_queue_id >= internals->nb_rx_queues)
+   if (rx_queue_id >= dev->data->nb_rx_queues)
return -ENODEV;

packet_size = internals->packet_size;
@@ -246,7 +237,7 @@ eth_rx_queue_setup(struct rte_eth_dev *dev, uint16_t 
rx_queue_id,
dev->data->rx_queues[rx_queue_id] =
>rx_null_queues[rx_queue_id];
dummy_packet = rte_zmalloc_socket(NULL,
-   packet_size, 0, internals->numa_node);
+   packet_size, 0, dev->data->numa_node);
if (dummy_packet == NULL)
return -ENOMEM;

@@ -271,7 +262,7 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t 
tx_queue_id,

internals = dev->data->dev_private;

-   if (tx_queue_id >= internals->nb_tx_queues)
+   if (tx_queue_id >= dev->data->nb_tx_queues)
return -ENODEV;

packet_size = internals->packet_size;
@@ -279,7 +270,7 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t 
tx_queue_id,
dev->data->tx_queues[tx_queue_id] =
>tx_null_queues[tx_queue_id];
dummy_packet = rte_zmalloc_socket(NULL,
-   packet_size, 0, internals->numa_node);
+   packet_size, 0, dev->data->numa_node);
if (dummy_packet == NULL)
return -ENOMEM;

@@ -323,7 +314,7 @@ eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats 
*igb_stats)

internal = dev->data->dev_private;
num_stats = RTE_MIN((unsigned)RTE_ETHDEV_QUEUE_STAT_CNTRS,
-   RTE_MIN(internal->nb_rx_queues,
+   RTE_MIN(dev->data->nb_rx_queues,
RTE_DIM(internal->rx_null_queues)));
for (i = 0; i < num_stats; i++) {
igb_stats->q_ipackets[i] =
@@ -332,7 +323,7 @@ eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats 
*igb_stats)
}

num_stats = RTE_MIN((unsigned)RTE_ETHDEV_QUEUE_STAT_CNTRS,
-   RTE_MIN(internal->nb_tx_queues,
+   RTE_MIN(dev->data->nb_tx_queues,
RTE_DIM(internal->tx_null_queues)));
for (i = 0; i < num_stats; i++) {
igb_stats->q_opackets[i] =
@@ -535,11 +526,8 @@ eth_dev_null_create(const char *name,
/* NOTE: we'll replace the data element, of originally allocated eth_dev
 * so the nulls are local per-process */

-   internals->nb_rx_queues = nb_rx_queues;
-   internals->nb_tx_queues = nb_tx_queues;
internals->packet_size = packet_size;
internals->packet_copy = packet_copy;
-   internals->numa_node = numa_node;

internals->flow_type_rss_offloads =  ETH_RSS_PROTO_MASK;
internals->reta_size = RTE_DIM(internals->reta_conf) * 
RTE_RETA_GROUP_SIZE;
@@ -560,10 +548,10 @@ eth_dev_null_create(const char *name,
TAILQ_INIT(_dev->link_intr_cbs);

eth_dev->driver = NULL;
-   eth_dev->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
-   eth_dev->data->kdrv = RTE_KDRV_NONE;
-   eth_dev->data->drv_name = drivername;
-   eth_dev->data->numa_node = numa_node;
+   data->dev_flags = RTE_ETH_DEV_DETACHABLE;
+   data->kdrv = RTE_KDRV_NONE;
+   data->drv_name = drivername;
+   data->numa_node = numa_node;

/* finally assign rx and tx ops */
if (packet_copy) {
-- 
2.5.0



[dpdk-dev] [PATCH v4 2/3] ring: variable rename and code cleanup

2016-02-26 Thread Ferruh Yigit
Rename nb_rx/tx_queues fields in internals struct to max_rx/tx_queues
Updated fields required to keep max queue numbers configured. For current
queue number requirements data->nb_rx/tx_queues fields used.

Some checkpatch corrections and code clenaup.

Signed-off-by: Ferruh Yigit 
---
 drivers/net/ring/rte_eth_ring.c | 59 -
 1 file changed, 29 insertions(+), 30 deletions(-)

diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index d92b088..c9ecb0e 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -59,8 +59,8 @@ struct ring_queue {
 };

 struct pmd_internals {
-   unsigned nb_rx_queues;
-   unsigned nb_tx_queues;
+   unsigned max_rx_queues;
+   unsigned max_tx_queues;

struct ring_queue rx_ring_queues[RTE_PMD_RING_MAX_RX_RINGS];
struct ring_queue tx_ring_queues[RTE_PMD_RING_MAX_TX_RINGS];
@@ -138,7 +138,7 @@ eth_dev_set_link_up(struct rte_eth_dev *dev)
 }

 static int
-eth_rx_queue_setup(struct rte_eth_dev *dev,uint16_t rx_queue_id,
+eth_rx_queue_setup(struct rte_eth_dev *dev, uint16_t rx_queue_id,
uint16_t nb_rx_desc __rte_unused,
unsigned int socket_id __rte_unused,
const struct rte_eth_rxconf *rx_conf 
__rte_unused,
@@ -169,36 +169,36 @@ eth_dev_info(struct rte_eth_dev *dev,
dev_info->driver_name = drivername;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (uint32_t)-1;
-   dev_info->max_rx_queues = (uint16_t)internals->nb_rx_queues;
-   dev_info->max_tx_queues = (uint16_t)internals->nb_tx_queues;
+   dev_info->max_rx_queues = (uint16_t)internals->max_rx_queues;
+   dev_info->max_tx_queues = (uint16_t)internals->max_tx_queues;
dev_info->min_rx_bufsize = 0;
dev_info->pci_dev = NULL;
 }

 static void
-eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *igb_stats)
+eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
 {
unsigned i;
unsigned long rx_total = 0, tx_total = 0, tx_err_total = 0;
const struct pmd_internals *internal = dev->data->dev_private;

for (i = 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS &&
-   i < internal->nb_rx_queues; i++) {
-   igb_stats->q_ipackets[i] = 
internal->rx_ring_queues[i].rx_pkts.cnt;
-   rx_total += igb_stats->q_ipackets[i];
+   i < dev->data->nb_rx_queues; i++) {
+   stats->q_ipackets[i] = internal->rx_ring_queues[i].rx_pkts.cnt;
+   rx_total += stats->q_ipackets[i];
}

for (i = 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS &&
-   i < internal->nb_tx_queues; i++) {
-   igb_stats->q_opackets[i] = 
internal->tx_ring_queues[i].tx_pkts.cnt;
-   igb_stats->q_errors[i] = 
internal->tx_ring_queues[i].err_pkts.cnt;
-   tx_total += igb_stats->q_opackets[i];
-   tx_err_total += igb_stats->q_errors[i];
+   i < dev->data->nb_tx_queues; i++) {
+   stats->q_opackets[i] = internal->tx_ring_queues[i].tx_pkts.cnt;
+   stats->q_errors[i] = internal->tx_ring_queues[i].err_pkts.cnt;
+   tx_total += stats->q_opackets[i];
+   tx_err_total += stats->q_errors[i];
}

-   igb_stats->ipackets = rx_total;
-   igb_stats->opackets = tx_total;
-   igb_stats->oerrors = tx_err_total;
+   stats->ipackets = rx_total;
+   stats->opackets = tx_total;
+   stats->oerrors = tx_err_total;
 }

 static void
@@ -206,9 +206,9 @@ eth_stats_reset(struct rte_eth_dev *dev)
 {
unsigned i;
struct pmd_internals *internal = dev->data->dev_private;
-   for (i = 0; i < internal->nb_rx_queues; i++)
+   for (i = 0; i < dev->data->nb_rx_queues; i++)
internal->rx_ring_queues[i].rx_pkts.cnt = 0;
-   for (i = 0; i < internal->nb_tx_queues; i++) {
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
internal->tx_ring_queues[i].tx_pkts.cnt = 0;
internal->tx_ring_queues[i].err_pkts.cnt = 0;
}
@@ -262,7 +262,6 @@ rte_eth_from_rings(const char *name, struct rte_ring *const 
rx_queues[],
struct rte_eth_dev_data *data = NULL;
struct pmd_internals *internals = NULL;
struct rte_eth_dev *eth_dev = NULL;
-
unsigned i;

/* do some parameter checking */
@@ -291,15 +290,15 @@ rte_eth_from_rings(const char *name, struct rte_ring 
*const rx_queues[],
goto error;
}

-   data->rx_queues = rte_zmalloc_socket(name, sizeof(void *) * 
nb_rx_queues,
-   0, numa_node);
+   data->rx_queues = rte_zmalloc_socket(name,
+   sizeof(void *) * nb_rx_queues, 0, numa_node);
if (data->rx_queues == NULL) {
rte_errno = ENOMEM;

[dpdk-dev] [PATCH v4 1/3] pcap: remove duplicate fields in internal data struct

2016-02-26 Thread Ferruh Yigit
1- Remove duplicate nb_rx/tx_queues fields from internals
2- Move duplicate code into a common function

Signed-off-by: Ferruh Yigit 
Acked-by: Nicolas Pernas Maradei 
---
 drivers/net/pcap/rte_eth_pcap.c | 130 +++-
 1 file changed, 61 insertions(+), 69 deletions(-)

diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index f9230eb..c8b7dbd 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -103,8 +103,6 @@ struct tx_pcaps {
 struct pmd_internals {
struct pcap_rx_queue rx_queue[RTE_PMD_RING_MAX_RX_RINGS];
struct pcap_tx_queue tx_queue[RTE_PMD_RING_MAX_TX_RINGS];
-   unsigned nb_rx_queues;
-   unsigned nb_tx_queues;
int if_index;
int single_iface;
 };
@@ -396,7 +394,7 @@ eth_dev_start(struct rte_eth_dev *dev)
}

/* If not open already, open tx pcaps/dumpers */
-   for (i = 0; i < internals->nb_tx_queues; i++) {
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
tx = >tx_queue[i];

if (!tx->dumper && strcmp(tx->type, ETH_PCAP_TX_PCAP_ARG) == 0) 
{
@@ -411,7 +409,7 @@ eth_dev_start(struct rte_eth_dev *dev)
}

/* If not open already, open rx pcaps */
-   for (i = 0; i < internals->nb_rx_queues; i++) {
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
rx = >rx_queue[i];

if (rx->pcap != NULL)
@@ -457,7 +455,7 @@ eth_dev_stop(struct rte_eth_dev *dev)
goto status_down;
}

-   for (i = 0; i < internals->nb_tx_queues; i++) {
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
tx = >tx_queue[i];

if (tx->dumper != NULL) {
@@ -471,7 +469,7 @@ eth_dev_stop(struct rte_eth_dev *dev)
}
}

-   for (i = 0; i < internals->nb_rx_queues; i++) {
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
rx = >rx_queue[i];

if (rx->pcap != NULL) {
@@ -499,8 +497,8 @@ eth_dev_info(struct rte_eth_dev *dev,
dev_info->if_index = internals->if_index;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (uint32_t) -1;
-   dev_info->max_rx_queues = (uint16_t)internals->nb_rx_queues;
-   dev_info->max_tx_queues = (uint16_t)internals->nb_tx_queues;
+   dev_info->max_rx_queues = dev->data->nb_rx_queues;
+   dev_info->max_tx_queues = dev->data->nb_tx_queues;
dev_info->min_rx_bufsize = 0;
dev_info->pci_dev = NULL;
 }
@@ -515,16 +513,16 @@ eth_stats_get(struct rte_eth_dev *dev,
unsigned long tx_packets_err_total = 0;
const struct pmd_internals *internal = dev->data->dev_private;

-   for (i = 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS && i < 
internal->nb_rx_queues;
-   i++) {
+   for (i = 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS &&
+   i < dev->data->nb_rx_queues; i++) {
igb_stats->q_ipackets[i] = internal->rx_queue[i].rx_pkts;
igb_stats->q_ibytes[i] = internal->rx_queue[i].rx_bytes;
rx_packets_total += igb_stats->q_ipackets[i];
rx_bytes_total += igb_stats->q_ibytes[i];
}

-   for (i = 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS && i < 
internal->nb_tx_queues;
-   i++) {
+   for (i = 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS &&
+   i < dev->data->nb_tx_queues; i++) {
igb_stats->q_opackets[i] = internal->tx_queue[i].tx_pkts;
igb_stats->q_obytes[i] = internal->tx_queue[i].tx_bytes;
igb_stats->q_errors[i] = internal->tx_queue[i].err_pkts;
@@ -545,11 +543,11 @@ eth_stats_reset(struct rte_eth_dev *dev)
 {
unsigned i;
struct pmd_internals *internal = dev->data->dev_private;
-   for (i = 0; i < internal->nb_rx_queues; i++) {
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
internal->rx_queue[i].rx_pkts = 0;
internal->rx_queue[i].rx_bytes = 0;
}
-   for (i = 0; i < internal->nb_tx_queues; i++) {
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
internal->tx_queue[i].tx_pkts = 0;
internal->tx_queue[i].tx_bytes = 0;
internal->tx_queue[i].err_pkts = 0;
@@ -840,9 +838,6 @@ rte_pmd_init_internals(const char *name, const unsigned 
nb_rx_queues,
/* NOTE: we'll replace the data element, of originally allocated eth_dev
 * so the rings are local per-process */

-   (*internals)->nb_rx_queues = nb_rx_queues;
-   (*internals)->nb_tx_queues = nb_tx_queues;
-
if (pair == NULL)
(*internals)->if_index = 0;
else
@@ -860,11 +855,11 @@ rte_pmd_init_internals(const char *name, const unsigned 
nb_rx_queues,

(*eth_dev)->data = data;
(*eth_dev)->dev_ops = 
-   (*eth_dev)->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
(*eth_dev)->driver = NULL;
- 

[dpdk-dev] [PATCH v4 0/3] clean-up on virtual PMDs

2016-02-26 Thread Ferruh Yigit
This is a clean-up patch, no defect fixed, no functional difference 
expected.

Patch removes duplicated fields between data->dev_private
and data (struct rte_eth_dev_data) for pcap and null PMDs.
For ring, renames some variables and does code cleanup.

Also for pcap: move a common code into a function

v4:
* ring: Commit message updated to mention from code cleanup,
no code update.

v3:
* ring: Add fields in internal data struct back, rename them
these fields required to keep max configured queue number

v2:
* ring: Add memory allocation and queue assignment back, 
these are to make rte_eth_from_ring() work without 
rte_eth_dev_configure() or rte_eth_rx/tx_queue_setup() calls


Ferruh Yigit (3):
  pcap: remove duplicate fields in internal data struct
  ring: variable rename and code cleanup
  null: remove duplicate fields in internal data struct

 drivers/net/null/rte_eth_null.c |  36 ---
 drivers/net/pcap/rte_eth_pcap.c | 130 +++-
 drivers/net/ring/rte_eth_ring.c |  59 +-
 3 files changed, 102 insertions(+), 123 deletions(-)

-- 
2.5.0



[dpdk-dev] Virtio xstats problem

2016-02-26 Thread Igor Ryzhov
Hello.

I found some problem with virtio xstats counters.

Example:

rx_good_packets: 3
rx_good_bytes: 180
rx_errors: 0

rx_q0_good_packets: 3
rx_q0_good_bytes: 180
rx_q0_errors: 0

rx_q0_multicast_packets: 3
rx_q0_broadcast_packets: 1
rx_q0_undersize_packets: 3

It means that undersize packets are counted as good packets instead of errors. 
Or maybe size of packet is calculated wrong.
I don't have time now to check it more deeply - I can do it sometime later, but 
maybe someone want to help.

PS. Is it a common practice to count broadcast packets twice - in broadcast and 
multicast counters?

Best regards,
Igor


[dpdk-dev] client_server example application crash with virtio

2016-02-26 Thread Kyle Larose
I just ran into an issue trying to run the client server example application 
using virito. Whenever the client (running as a secondary process) tried to 
send packets, it would crash. I traced the issue to an invalid vtpci_ops 
structure:

(gdb) p *vq->hw->vtpci_ops
$6 = {
  read_dev_cfg = 0x756d2073726f7470,
  write_dev_cfg = 0x6562206562207473,
  reset = 0x6425206e65657774,
  get_status = 0x20642520646e6120,
  set_status = 0x766973756c636e69,
  get_features = 0x7561666544202e65,
  set_features = 0xa5d64255b20746c,
  get_isr = 0x0,
  set_config_irq = 0x657472203a444d50,
  get_queue_num = 0x705f65626778635f,
  setup_queue = 0x203a7325203a646d,
  del_queue = 0x20746b702078616d,
  notify_queue = 0x7473756d206e656c
}

It looks like this is not being initialized in secondary processes, because we 
short-circuit the ethdev init here, before we call vtpci_init.

if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
rx_func_get(eth_dev);
return 0;
}

Has  anyone submitted a patch to fix this?

I found that the following seemed to make it work, though I'm not sure it's 
appropriate. I can submit it as a patch if nobody else has done so yet. (I'd 
clean it up to return an error code if the init fails).

git diff drivers/net/virtio/virtio_ethdev.c
diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index caa970c..5002847 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1002,6 +1002,8 @@ rx_func_get(struct rte_eth_dev *eth_dev)
eth_dev->rx_pkt_burst = _recv_mergeable_pkts;
else
eth_dev->rx_pkt_burst = _recv_pkts;
+
+vtpci_init(eth_dev->pci_dev, (struct 
virtio_hw*)eth_dev->data->dev_private);
 }

 /*

Thanks,

Kyle


[dpdk-dev] [PATCH v2] fm10k: handle err flags in vector RX func

2016-02-26 Thread Bruce Richardson
On Thu, Feb 18, 2016 at 08:36:55AM +, Liang, Cunming wrote:
> Hi,
> 
> > -Original Message-
> > From: Chen, Jing D
> > Sent: Saturday, February 06, 2016 2:49 PM
> > To: Liang, Cunming; He, Shaopeng
> > Cc: dev at dpdk.org; Chen, Jing D
> > Subject: [PATCH v2] fm10k: handle err flags in vector RX func
> > 
> > From: "Chen Jing D(Mark)" 
> > 
> > Using SSE instructions to parse error flags in HW Rx descriptor,
> > then set corresponding bits of mbuf.
> > 
> > Signed-off-by: Chen Jing D(Mark) 
> Acked-by: Cunming Liang 

Applied to dpdk-next-net/rel_16_04

/Bruce


[dpdk-dev] DPDK with vhostuser - Issue in Testing with DPDK-Pktgen

2016-02-26 Thread Wiles, Keith
>Dear Przemek, Sean & Sugesh,
>
>It would be great if get your valuable inputs for the below listed issue. 
>We have setup DPDK with vhostuser in AllinOne setup on following software 
>platform.
>_
>Openstack: Kilo
>Distribution: Ubuntu 14.04
>OVS Version: 2.4.0
>DPDK 2.0.0
>_
>
>In our Openstack OVS-DPDK  set up, we are spawning 2 instance on same host 
>with Ubuntu and running DPDK-pktgen in one of the VM and measuring traffic 
>between VMs of same host.
>
>VMs spec are 8GB of memory and 4 core, we are using one port for pktgen 
>application.
> 
>Please fine the VM huge page setting as well,
> 
>HugePages_Total:1024
>HugePages_Free:  896
>HugePages_Rsvd:0
>HugePages_Surp:0
>Hugepagesize:   2048 kB
> 
>Please find the below command we are using,
> 
>./app/app/$RTE_TARGET/pktgen -c 0f -n 3  --proc-type auto --socket-mem 256 
>-b :00:03.0 -- -P -m "[1-3].0"
> 
>Regardless of the cores whatever we are passing here(-m "[1-3].0"), the 
>traffic is sending via only one core, remaining 2 cores are idle.

Let me look at the problem and verify it is not a bug or something else.

> 
>We have added specific property as well to the images we are using,
> 
>hw:?vif_multiqueue_?enabled=?true ? Flavor property
>hw_?vif_mutliqueue_?enabled=?true ? Image property
> 
>Still we got the same issue on the application.
> 
>From logs,
>. . . . .
>** Dev Info (rte_virtio_pmd:0) **
>   max_vfs:   0 min_rx_bufsize:  64 max_rx_pktlen :  9728 
>max_rx_queues :   1 max_tx_queues:   1
>. . . . .
> 
>
>Kindly suggest us something on this regard if we need to tune anything on 
>Openstack end or in pktgen application.
>
>
>Thanks & Regards
>Abhijeet Karve
>=-=-=
>Notice: The information contained in this e-mail
>message and/or attachments to it may contain 
>confidential or privileged information. If you are 
>not the intended recipient, any dissemination, use, 
>review, distribution, printing or copying of the 
>information contained in this e-mail message 
>and/or attachments to it are strictly prohibited. If 
>you have received this communication in error, 
>please notify us by reply e-mail or telephone and 
>immediately and permanently delete the message 
>and any attachments. Thank you
>
>
>


Regards,
Keith






[dpdk-dev] [PATCH v4 09/12] pmd/mlx5: add dev_ptype_info_get implementation

2016-02-26 Thread Tan, Jianfeng
Hi,

On 2/26/2016 4:26 PM, Adrien Mazarguil wrote:
> Hi Jianfeng,
>
> On Fri, Feb 26, 2016 at 08:09:28AM +0800, Jianfeng Tan wrote:
>> Signed-off-by: Jianfeng Tan 
>> ---
>>   drivers/net/mlx4/mlx4.c|  2 +-
>>   drivers/net/mlx5/mlx5.c|  1 +
>>   drivers/net/mlx5/mlx5.h|  1 +
>>   drivers/net/mlx5/mlx5_ethdev.c | 20 
>>   drivers/net/mlx5/mlx5_rxtx.c   |  2 ++
>>   5 files changed, 25 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
>> index 85fdebf..58f4e1a 100644
>> --- a/drivers/net/mlx4/mlx4.c
>> +++ b/drivers/net/mlx4/mlx4.c
>> @@ -4269,7 +4269,7 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct 
>> rte_eth_dev_info *info)
>>  priv_unlock(priv);
>>   }
>>   
>> -static uint32_t *
>> +static const uint32_t *
>>   mlx4_dev_ptype_info_get(struct rte_eth_dev *dev)
>>   {
>>  static const uint32_t ptypes[] = {
> I'm probably nitpicking here but this change should be merged in the mlx4
> patch. Otherwise both mlx4 and mlx5 patches look fine to me.
>

Oops, nice catch. It's should be in mlx4 commit. I'll fix it.

Thanks,
Jianfeng


[dpdk-dev] [PATCH v3 2/3] ring: rename fields in internal data struct

2016-02-26 Thread Bruce Richardson
On Fri, Feb 26, 2016 at 03:26:54PM +, Ferruh Yigit wrote:
> Rename nb_rx/tx_queues fields in internals struct to max_rx/tx_queues
> 
> This patch just does variable renaming to help understanding code better,
> nothing changed in functionality of the code.
> 
> Updated fields required to keep max queue numbers configured. For current
> queue number requirements data->nb_rx/tx_queues fields used.
> 
There are other changes in this patchset other than renaming the rx/tx queue
fields. They should be called out in the commit message, I think. The whitespace
cleanup change should probably be omitted from this patch as not related to
renaming.

/Bruce



[dpdk-dev] [PATCH v4 5/5] ixgbe: support VxLAN & NVGRE TX checksum off-load

2016-02-26 Thread Wenzhuo Lu
The patch add VxLAN & NVGRE TX checksum off-load. When the flag of
outer IP header checksum offload is set, we'll set the context
descriptor to enable this checksum off-load.

Also update release note for VxLAN & NVGRE checksum off-load support.

Signed-off-by: Wenzhuo Lu 
---
 doc/guides/rel_notes/release_16_04.rst |  9 ++
 drivers/net/ixgbe/ixgbe_ethdev.c   |  4 +++
 drivers/net/ixgbe/ixgbe_rxtx.c | 56 +++---
 drivers/net/ixgbe/ixgbe_rxtx.h |  6 +++-
 4 files changed, 63 insertions(+), 12 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 8273817..a17c2fb 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -46,6 +46,15 @@ This section should contain new features added in this 
release. Sample format:

 * **Added vhost-user live migration support.**

+* **Added support for VxLAN & NVGRE checksum off-load on X550.**
+
+  * Added support for VxLAN & NVGRE RX/TX checksum off-load on
+X550. RX/TX checksum off-load is provided on both inner and
+outer IP header and TCP header.
+  * Added functions to support VxLAN port configuration. The
+default VxLAN port number is 4789 but this can be updated
+programmatically.
+

 Resolved Issues
 ---
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 3ca17a9..87a8fa7 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2811,6 +2811,10 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
DEV_TX_OFFLOAD_SCTP_CKSUM  |
DEV_TX_OFFLOAD_TCP_TSO;

+   if (hw->mac.type == ixgbe_mac_X550 ||
+   hw->mac.type == ixgbe_mac_X550EM_x)
+   dev_info->tx_offload_capa |= DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM;
+
dev_info->default_rxconf = (struct rte_eth_rxconf) {
.rx_thresh = {
.pthresh = IXGBE_DEFAULT_RX_PTHRESH,
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 6b913ee..c2c71de 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -85,7 +85,8 @@
PKT_TX_VLAN_PKT |\
PKT_TX_IP_CKSUM |\
PKT_TX_L4_MASK | \
-   PKT_TX_TCP_SEG)
+   PKT_TX_TCP_SEG | \
+   PKT_TX_OUTER_IP_CKSUM)

 static inline struct rte_mbuf *
 rte_rxmbuf_alloc(struct rte_mempool *mp)
@@ -364,9 +365,11 @@ ixgbe_set_xmit_ctx(struct ixgbe_tx_queue *txq,
uint32_t ctx_idx;
uint32_t vlan_macip_lens;
union ixgbe_tx_offload tx_offload_mask;
+   uint32_t seqnum_seed = 0;

ctx_idx = txq->ctx_curr;
-   tx_offload_mask.data = 0;
+   tx_offload_mask.data[0] = 0;
+   tx_offload_mask.data[1] = 0;
type_tucmd_mlhl = 0;

/* Specify which HW CTX to upload. */
@@ -430,18 +433,35 @@ ixgbe_set_xmit_ctx(struct ixgbe_tx_queue *txq,
}
}

+   if (ol_flags & PKT_TX_OUTER_IP_CKSUM) {
+   tx_offload_mask.outer_l2_len |= ~0;
+   tx_offload_mask.outer_l3_len |= ~0;
+   tx_offload_mask.l2_len |= ~0;
+   seqnum_seed |= tx_offload.outer_l3_len
+  << IXGBE_ADVTXD_OUTER_IPLEN;
+   seqnum_seed |= tx_offload.l2_len
+  << IXGBE_ADVTXD_TUNNEL_LEN;
+   }
+
txq->ctx_cache[ctx_idx].flags = ol_flags;
-   txq->ctx_cache[ctx_idx].tx_offload.data  =
-   tx_offload_mask.data & tx_offload.data;
+   txq->ctx_cache[ctx_idx].tx_offload.data[0]  =
+   tx_offload_mask.data[0] & tx_offload.data[0];
+   txq->ctx_cache[ctx_idx].tx_offload.data[1]  =
+   tx_offload_mask.data[1] & tx_offload.data[1];
txq->ctx_cache[ctx_idx].tx_offload_mask= tx_offload_mask;

ctx_txd->type_tucmd_mlhl = rte_cpu_to_le_32(type_tucmd_mlhl);
vlan_macip_lens = tx_offload.l3_len;
-   vlan_macip_lens |= (tx_offload.l2_len << IXGBE_ADVTXD_MACLEN_SHIFT);
+   if (ol_flags & PKT_TX_OUTER_IP_CKSUM)
+   vlan_macip_lens |= (tx_offload.outer_l2_len <<
+   IXGBE_ADVTXD_MACLEN_SHIFT);
+   else
+   vlan_macip_lens |= (tx_offload.l2_len <<
+   IXGBE_ADVTXD_MACLEN_SHIFT);
vlan_macip_lens |= ((uint32_t)tx_offload.vlan_tci << 
IXGBE_ADVTXD_VLAN_SHIFT);
ctx_txd->vlan_macip_lens = rte_cpu_to_le_32(vlan_macip_lens);
ctx_txd->mss_l4len_idx   = rte_cpu_to_le_32(mss_l4len_idx);
-   ctx_txd->seqnum_seed = 0;
+   ctx_txd->seqnum_seed = seqnum_seed;
 }

 /*
@@ -454,16 +474,24 @@ what_advctx_update(struct ixgbe_tx_queue *txq, uint64_t 
flags,
 {
/* If match with the current used context */
if 

[dpdk-dev] [PATCH v4 0/5] Support VxLAN & NVGRE checksum off-load on X550

2016-02-26 Thread Wenzhuo Lu
This patch set add the VxLAN & NVGRE checksum off-load support.
Both RX and TX checksum off-load can be used for VxLAN & NVGRE.
And the VxLAN port can be set, it's implemented in this patch
set either.

V2:
* Update release note.

V3:
* Update RX/TX offload capability.
* Reuse PKT_RX_EIP_CKSUM_BAD but not add a new one.
* Correct the tunnel len for TX, and remove the useless out_l2_len.
* Don't set the tunnel type for TX, and remove the unused ol_flag_nvgre.

V4:
* Fix the issue that not setting the MAC length correctly.

Wenzhuo Lu (5):
  lib/librte_ether: change function name of tunnel port config
  i40e: rename the tunnel port config functions
  ixgbe: support UDP tunnel port config
  ixgbe: support VxLAN &  NVGRE RX checksum off-load
  ixgbe: support VxLAN &  NVGRE TX checksum off-load

 app/test-pmd/cmdline.c |   6 +-
 doc/guides/rel_notes/release_16_04.rst |   9 +++
 drivers/net/i40e/i40e_ethdev.c |  22 +++
 drivers/net/ixgbe/ixgbe_ethdev.c   | 103 +
 drivers/net/ixgbe/ixgbe_rxtx.c |  67 +
 drivers/net/ixgbe/ixgbe_rxtx.h |   6 +-
 examples/tep_termination/vxlan_setup.c |   2 +-
 lib/librte_ether/rte_ethdev.c  |  45 ++
 lib/librte_ether/rte_ethdev.h  |  19 ++
 lib/librte_mbuf/rte_mbuf.c |   2 +-
 lib/librte_mbuf/rte_mbuf.h |   2 +-
 11 files changed, 255 insertions(+), 28 deletions(-)

-- 
1.9.3



[dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer

2016-02-26 Thread Nélio Laranjeiro
On Mon, Jan 18, 2016 at 03:38:43PM +0100, Olivier MATZ wrote:
> Hi,
> 
> On 01/15/2016 10:00 AM, Panu Matilainen wrote:
>  diff --git a/lib/librte_cmdline/cmdline_rdline.h
>  b/lib/librte_cmdline/cmdline_rdline.h
>  index b9aad9b..72e2dad 100644
>  --- a/lib/librte_cmdline/cmdline_rdline.h
>  +++ b/lib/librte_cmdline/cmdline_rdline.h
>  @@ -93,7 +93,7 @@ extern "C" {
>    #endif
> 
>    /* configuration */
>  -#define RDLINE_BUF_SIZE 256
>  +#define RDLINE_BUF_SIZE 512
>    #define RDLINE_PROMPT_SIZE  32
>    #define RDLINE_VT100_BUF_SIZE  8
>    #define RDLINE_HISTORY_BUF_SIZE BUFSIZ
> >>>
> >>> Having to break a library ABI for a change like this is a bit
> >>> ridiculous.
> >>
> >> Sure, but John McNamara needed it to handle flow director with IPv6[1].
> >>
> >> For my part, I was needing it to manipulate the RETA table, but as I
> >> wrote in the cover letter, it ends by breaking other commands.
> >> Olivier Matz, has proposed another way to handle long commands lines[2],
> >> it could be a good idea to go on this direction.
> >>
> >> For RETA situation, we already discussed on a new API, but for now, I
> >> do not have time for it (and as it is another ABI breakage it could only
> >> be done for 16.07 or 2.4)[3].
> >>
> >> If this patch is no more needed we can just drop it, for that I would
> >> like to have the point of view from John.
> > 
> > Note that I was not objecting to the patch as such, I can easily see 256
> > characters not being enough for commandline buffer.
> > 
> > I was merely noting that having to break an ABI to increase an
> > effectively internal buffer size is a sign of a, um, less-than-optimal
> > library design.
> 
> You are right about the cmdline ABI. Changing this buffer size
> should not imply an ABI change. I'll try to find some time to
> investigate this issue.
> 
> Another question we could raise is: should we export the API of
> librte_cmdline to external applications? Now that baremetal dpdk is
> not supported, having this library in dpdk is probably useless as
> we can surely find standard replacements for it. A first step could
> be to mark it as "internal".
> 
> About the patch N?lio's patch itself, I'm not so convinced having more
> than 256 characters is absolutely required, and I would prefer to see
> the commands beeing reworked to be more human-readable. On the other
> hand, the ABI breakage was announced so there is no reason to nack
> this patch now.
> 
> Regards,
> Olivier

John,

What is your position about this patch?
Is it still needed?

Regards,

-- 
N?lio Laranjeiro
6WIND


[dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer

2016-02-26 Thread Mcnamara, John


> -Original Message-
> From: N?lio Laranjeiro [mailto:nelio.laranjeiro at 6wind.com]
> Sent: Friday, February 26, 2016 3:17 PM
> To: Mcnamara, John 
> Cc: Olivier MATZ ; Panu Matilainen
> ; dev at dpdk.org; Zhang, Helin  intel.com>;
> thomas.monjalon at 6wind.com; Lu, Wenzhuo ;
> olgas at mellanox.com
> Subject: Re: [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line
> buffer
> 
> 
> What is your position about this patch?
> Is it still needed?

Yes. It is still required.

Acked-by: John McNamara 



[dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding

2016-02-26 Thread David Marchand
On Fri, Feb 26, 2016 at 3:48 PM, Bruce Richardson
 wrote:
> On Fri, Feb 26, 2016 at 09:24:06AM +, Wang, Xiao W wrote:
>> Hi,
>> > > Thanks for the discussion, Thomas, do you have any suggestions?
>> >
>> > I don't understand why you say this feature is specific to fm10k. Can we
>> > imagine another NIC having this capability?
>>
>> As you know, fm10k has a switch logic between the Mac and Phy, every packets
>> Sent out from the host will be switched inside the NIC, other NICs don't have
>> a switch inside, and the FTAG feature is related to the switch function.
>>
>> As introduced in the second patch:
>> The FM10K family of NICs support the addition of a Fabric Tag (FTAG) to carry
>> special information. The FTAG is placed at the beginning of the frame, it 
>> contains
>> information such as where the packet comes from and goes, and the vlan tag. 
>> In
>> FTAG based forwarding mode, the switch logic forwards packets according to
>> glort (global resource tag) information, rather than the mac and vlan table.
>> So this is a feature specific to fm10k.
>
> If it is fm10k specific, how about just adding a public function to the fm10k
> driver to turn it on. The user app will be non-portable across NICs, but
> that's the price of using nic-specific features.

What about using a devargs ?
Something like :
-w :xx:xx.x,enable_ftag=1

The application still needs to know about this to enable it, but that
sounds better to me.
The only issue is that it can't work with hotplug at the moment.


-- 
David Marchand


[dpdk-dev] [PATCH v5 11/11] pmd/vmxnet3: add dev_ptype_info_get implementation

2016-02-26 Thread Jianfeng Tan
Signed-off-by: Jianfeng Tan 
---
 drivers/net/vmxnet3/vmxnet3_ethdev.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c 
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index c363bf6..ac120a1 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -86,6 +86,7 @@ static void vmxnet3_dev_stats_get(struct rte_eth_dev *dev,
struct rte_eth_stats *stats);
 static void vmxnet3_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
+static const uint32_t *vmxnet3_dev_ptype_info_get(struct rte_eth_dev *dev);
 static int vmxnet3_dev_vlan_filter_set(struct rte_eth_dev *dev,
   uint16_t vid, int on);
 static void vmxnet3_dev_vlan_offload_set(struct rte_eth_dev *dev, int mask);
@@ -118,6 +119,7 @@ static const struct eth_dev_ops vmxnet3_eth_dev_ops = {
.link_update  = vmxnet3_dev_link_update,
.stats_get= vmxnet3_dev_stats_get,
.dev_infos_get= vmxnet3_dev_info_get,
+   .dev_ptype_info_get   = vmxnet3_dev_ptype_info_get,
.vlan_filter_set  = vmxnet3_dev_vlan_filter_set,
.vlan_offload_set = vmxnet3_dev_vlan_offload_set,
.rx_queue_setup   = vmxnet3_dev_rx_queue_setup,
@@ -718,6 +720,20 @@ vmxnet3_dev_info_get(__attribute__((unused))struct 
rte_eth_dev *dev, struct rte_
};
 }

+static const uint32_t *
+vmxnet3_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+   static const uint32_t ptypes[] = {
+   RTE_PTYPE_L3_IPV4_EXT,
+   RTE_PTYPE_L3_IPV4,
+   RTE_PTYPE_UNKNOWN
+   };
+
+   if (dev->rx_pkt_burst == vmxnet3_recv_pkts)
+   return ptypes;
+   return NULL;
+}
+
 /* return 0 means link status changed, -1 means not changed */
 static int
 vmxnet3_dev_link_update(struct rte_eth_dev *dev, __attribute__((unused)) int 
wait_to_complete)
-- 
2.1.4



[dpdk-dev] [PATCH v5 10/11] pmd/nfp: add dev_ptype_info_get implementation

2016-02-26 Thread Jianfeng Tan
Signed-off-by: Jianfeng Tan 
---
 drivers/net/nfp/nfp_net.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index fd4dd39..5894a9d 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -1073,6 +1073,24 @@ nfp_net_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->hash_key_size = NFP_NET_CFG_RSS_KEY_SZ;
 }

+static const uint32_t *
+nfp_net_ptype_info_get(struct rte_eth_dev *dev)
+{
+   static const uint32_t ptypes[] = {
+   /* refers to nfp_net_set_hash() */
+   RTE_PTYPE_INNER_L3_IPV4,
+   RTE_PTYPE_INNER_L3_IPV6,
+   RTE_PTYPE_INNER_L3_IPV6_EXT,
+   RTE_PTYPE_INNER_L4_MASK,
+   RTE_PTYPE_UNKNOWN
+   };
+
+
+   if (dev->rx_pkt_burst == nfp_net_recv_pkts)
+   return ptypes;
+   return num;
+}
+
 static uint32_t
 nfp_net_rx_queue_count(struct rte_eth_dev *dev, uint16_t queue_idx)
 {
@@ -2292,6 +2310,7 @@ static struct eth_dev_ops nfp_net_eth_dev_ops = {
.stats_get  = nfp_net_stats_get,
.stats_reset= nfp_net_stats_reset,
.dev_infos_get  = nfp_net_infos_get,
+   .dev_ptype_info_get = nfp_net_ptype_info_get,
.mtu_set= nfp_net_dev_mtu_set,
.vlan_offload_set   = nfp_net_vlan_offload_set,
.reta_update= nfp_net_reta_update,
-- 
2.1.4



[dpdk-dev] [PATCH v5 09/11] pmd/mlx5: add dev_ptype_info_get implementation

2016-02-26 Thread Jianfeng Tan
Signed-off-by: Jianfeng Tan 
---
 drivers/net/mlx5/mlx5.c|  1 +
 drivers/net/mlx5/mlx5.h|  1 +
 drivers/net/mlx5/mlx5_ethdev.c | 20 
 drivers/net/mlx5/mlx5_rxtx.c   |  2 ++
 4 files changed, 24 insertions(+)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 821ee0f..e18b1e9 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -153,6 +153,7 @@ static const struct eth_dev_ops mlx5_dev_ops = {
.stats_get = mlx5_stats_get,
.stats_reset = mlx5_stats_reset,
.dev_infos_get = mlx5_dev_infos_get,
+   .dev_ptype_info_get = mlx5_dev_ptype_info_get,
.vlan_filter_set = mlx5_vlan_filter_set,
.rx_queue_setup = mlx5_rx_queue_setup,
.tx_queue_setup = mlx5_tx_queue_setup,
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index b84d31d..196435d 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -156,6 +156,7 @@ int priv_get_mtu(struct priv *, uint16_t *);
 int priv_set_flags(struct priv *, unsigned int, unsigned int);
 int mlx5_dev_configure(struct rte_eth_dev *);
 void mlx5_dev_infos_get(struct rte_eth_dev *, struct rte_eth_dev_info *);
+const uint32_t *mlx5_dev_ptype_info_get(struct rte_eth_dev *dev);
 int mlx5_link_update(struct rte_eth_dev *, int);
 int mlx5_dev_set_mtu(struct rte_eth_dev *, uint16_t);
 int mlx5_dev_get_flow_ctrl(struct rte_eth_dev *, struct rte_eth_fc_conf *);
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 1159fa3..406f8dc 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -526,6 +526,26 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
priv_unlock(priv);
 }

+const uint32_t *
+mlx5_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+   static const uint32_t ptypes[] = {
+   /* refers to rxq_cq_to_pkt_type() */
+   RTE_PTYPE_L3_IPV4,
+   RTE_PTYPE_L3_IPV6,
+   RTE_PTYPE_INNER_L3_IPV4,
+   RTE_PTYPE_INNER_L3_IPV6,
+   RTE_PTYPE_UNKNOWN
+
+   };
+
+   if (dev->rx_pkt_burst == mlx5_rx_burst ||
+   dev->rx_pkt_burst == mlx5_rx_burst_sp)
+   return ptypes;
+   return NULL;
+
+}
+
 /**
  * DPDK callback to retrieve physical link information (unlocked version).
  *
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index fa5e648..79bdf8d 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -603,6 +603,8 @@ stop:
  * @param flags
  *   RX completion flags returned by poll_length_flags().
  *
+ * @note: fix mlx5_dev_ptype_info_get() if any change here.
+ *
  * @return
  *   Packet type for struct rte_mbuf.
  */
-- 
2.1.4



[dpdk-dev] [PATCH v5 08/11] pmd/mlx4: add dev_ptype_info_get implementation

2016-02-26 Thread Jianfeng Tan
Signed-off-by: Jianfeng Tan 
---
 drivers/net/mlx4/mlx4.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index ee00151..58f4e1a 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -2835,6 +2835,8 @@ rxq_cleanup(struct rxq *rxq)
  * @param flags
  *   RX completion flags returned by poll_length_flags().
  *
+ * @note: fix mlx4_dev_ptype_info_get() if any change here.
+ *
  * @return
  *   Packet type for struct rte_mbuf.
  */
@@ -4267,6 +4269,24 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
priv_unlock(priv);
 }

+static const uint32_t *
+mlx4_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+   static const uint32_t ptypes[] = {
+   /* refers to rxq_cq_to_pkt_type() */
+   RTE_PTYPE_L3_IPV4,
+   RTE_PTYPE_L3_IPV6,
+   RTE_PTYPE_INNER_L3_IPV4,
+   RTE_PTYPE_INNER_L3_IPV6,
+   RTE_PTYPE_UNKNOWN
+   };
+
+   if (dev->rx_pkt_burst == mlx4_rx_burst ||
+   dev->rx_pkt_burst == mlx4_rx_burst_sp)
+   return ptypes;
+   return NULL;
+}
+
 /**
  * DPDK callback to get device statistics.
  *
@@ -4988,6 +5008,7 @@ static const struct eth_dev_ops mlx4_dev_ops = {
.stats_reset = mlx4_stats_reset,
.queue_stats_mapping_set = NULL,
.dev_infos_get = mlx4_dev_infos_get,
+   .dev_ptypes_info_get = mlx4_dev_ptype_info_get,
.vlan_filter_set = mlx4_vlan_filter_set,
.vlan_tpid_set = NULL,
.vlan_strip_queue_set = NULL,
-- 
2.1.4



[dpdk-dev] [PATCH v5 07/11] pmd/ixgbe: add dev_ptype_info_get implementation

2016-02-26 Thread Jianfeng Tan
Signed-off-by: Jianfeng Tan 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 38 ++
 drivers/net/ixgbe/ixgbe_ethdev.h |  2 ++
 drivers/net/ixgbe/ixgbe_rxtx.c   |  4 +++-
 3 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 3e6fe86..605d958 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -166,6 +166,7 @@ static int ixgbe_dev_queue_stats_mapping_set(struct 
rte_eth_dev *eth_dev,
 uint8_t is_rx);
 static void ixgbe_dev_info_get(struct rte_eth_dev *dev,
   struct rte_eth_dev_info *dev_info);
+static const uint32_t *ixgbe_dev_ptype_info_get(struct rte_eth_dev *dev);
 static void ixgbevf_dev_info_get(struct rte_eth_dev *dev,
 struct rte_eth_dev_info *dev_info);
 static int ixgbe_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
@@ -428,6 +429,7 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
.xstats_reset = ixgbe_dev_xstats_reset,
.queue_stats_mapping_set = ixgbe_dev_queue_stats_mapping_set,
.dev_infos_get= ixgbe_dev_info_get,
+   .dev_ptype_info_get   = ixgbe_dev_ptype_info_get,
.mtu_set  = ixgbe_dev_mtu_set,
.vlan_filter_set  = ixgbe_vlan_filter_set,
.vlan_tpid_set= ixgbe_vlan_tpid_set,
@@ -512,6 +514,7 @@ static const struct eth_dev_ops ixgbevf_eth_dev_ops = {
.xstats_reset = ixgbevf_dev_stats_reset,
.dev_close= ixgbevf_dev_close,
.dev_infos_get= ixgbevf_dev_info_get,
+   .dev_ptype_info_get   = ixgbe_dev_ptype_info_get,
.mtu_set  = ixgbevf_dev_set_mtu,
.vlan_filter_set  = ixgbevf_vlan_filter_set,
.vlan_strip_queue_set = ixgbevf_vlan_strip_queue_set,
@@ -2829,6 +2832,41 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->flow_type_rss_offloads = IXGBE_RSS_OFFLOAD_ALL;
 }

+static const uint32_t *
+ixgbe_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+   static const uint32_t ptypes[] = {
+   /* For non-vec functions,
+* refers to ixgbe_rxd_pkt_info_to_pkt_type();
+* for vec functions,
+* refers to _recv_raw_pkts_vec().
+*/
+   RTE_PTYPE_L2_ETHER,
+   RTE_PTYPE_L3_IPV4,
+   RTE_PTYPE_L3_IPV4_EXT,
+   RTE_PTYPE_L3_IPV6,
+   RTE_PTYPE_L3_IPV6_EXT,
+   RTE_PTYPE_L4_SCTP,
+   RTE_PTYPE_L4_TCP,
+   RTE_PTYPE_L4_UDP,
+   RTE_PTYPE_TUNNEL_IP,
+   RTE_PTYPE_INNER_L3_IPV6,
+   RTE_PTYPE_INNER_L3_IPV6_EXT,
+   RTE_PTYPE_INNER_L4_TCP,
+   RTE_PTYPE_INNER_L4_UDP,
+   RTE_PTYPE_UNKNOWN
+   };
+
+   if (dev->rx_pkt_burst == ixgbe_recv_pkts ||
+   dev->rx_pkt_burst == ixgbe_recv_pkts_lro_single_alloc ||
+   dev->rx_pkt_burst == ixgbe_recv_pkts_lro_bulk_alloc ||
+   dev->rx_pkt_burst == ixgbe_recv_pkts_bulk_alloc ||
+   dev->rx_pkt_burst == ixgbe_recv_pkts_vec ||
+   dev->rx_pkt_burst == ixgbe_recv_scattered_pkts_vec)
+   return ptypes;
+   return NULL;
+}
+
 static void
 ixgbevf_dev_info_get(struct rte_eth_dev *dev,
 struct rte_eth_dev_info *dev_info)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index d26771a..b07d3da 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -379,6 +379,8 @@ void ixgbevf_dev_rxtx_start(struct rte_eth_dev *dev);
 uint16_t ixgbe_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts);

+uint16_t ixgbe_recv_pkts_bulk_alloc(void *rx_queue, struct rte_mbuf **rx_pkts,
+   uint16_t nb_pkts);
 uint16_t ixgbe_recv_pkts_lro_single_alloc(void *rx_queue,
struct rte_mbuf **rx_pkts, uint16_t nb_pkts);
 uint16_t ixgbe_recv_pkts_lro_bulk_alloc(void *rx_queue,
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index e95e6b7..17851cc 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -899,6 +899,8 @@ end_of_tx:
 #define IXGBE_PACKET_TYPE_MAX   0X80
 #define IXGBE_PACKET_TYPE_MASK  0X7F
 #define IXGBE_PACKET_TYPE_SHIFT 0X04
+
+/* @note: fix ixgbe_dev_ptype_info_get() if any change here. */
 static inline uint32_t
 ixgbe_rxd_pkt_info_to_pkt_type(uint16_t pkt_info)
 {
@@ -1247,7 +1249,7 @@ rx_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
 }

 /* split requests into chunks of size RTE_PMD_IXGBE_RX_MAX_BURST */
-static uint16_t
+uint16_t
 ixgbe_recv_pkts_bulk_alloc(void *rx_queue, struct rte_mbuf **rx_pkts,
   uint16_t nb_pkts)

[dpdk-dev] [PATCH v5 06/11] pmd/i40e: add dev_ptype_info_get implementation

2016-02-26 Thread Jianfeng Tan
Signed-off-by: Jianfeng Tan 
---
 drivers/net/i40e/i40e_ethdev.c|  1 +
 drivers/net/i40e/i40e_ethdev_vf.c |  1 +
 drivers/net/i40e/i40e_rxtx.c  | 46 ++-
 drivers/net/i40e/i40e_rxtx.h  |  1 +
 4 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index ef24122..81849fa 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -439,6 +439,7 @@ static const struct eth_dev_ops i40e_eth_dev_ops = {
.xstats_reset = i40e_dev_stats_reset,
.queue_stats_mapping_set  = i40e_dev_queue_stats_mapping_set,
.dev_infos_get= i40e_dev_info_get,
+   .dev_ptype_info_get   = i40e_dev_ptype_info_get,
.vlan_filter_set  = i40e_vlan_filter_set,
.vlan_tpid_set= i40e_vlan_tpid_set,
.vlan_offload_set = i40e_vlan_offload_set,
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 13c5b3d..afd436e 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -196,6 +196,7 @@ static const struct eth_dev_ops i40evf_eth_dev_ops = {
.xstats_reset = i40evf_dev_xstats_reset,
.dev_close= i40evf_dev_close,
.dev_infos_get= i40evf_dev_info_get,
+   .dev_ptype_info_get   = i40e_dev_ptype_info_get,
.vlan_filter_set  = i40evf_vlan_filter_set,
.vlan_offload_set = i40evf_vlan_offload_set,
.vlan_pvid_set= i40evf_vlan_pvid_set,
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 40cffc1..1a952df 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -194,7 +194,10 @@ i40e_get_iee15888_flags(struct rte_mbuf *mb, uint64_t 
qword)
 }
 #endif

-/* For each value it means, datasheet of hardware can tell more details */
+/* For each value it means, datasheet of hardware can tell more details
+ *
+ * @note: fix i40e_dev_ptype_info_get() if any change here.
+ */
 static inline uint32_t
 i40e_rxd_pkt_type_mapping(uint8_t ptype)
 {
@@ -2093,6 +2096,47 @@ i40e_dev_tx_queue_stop(struct rte_eth_dev *dev, uint16_t 
tx_queue_id)
return 0;
 }

+const uint32_t *
+i40e_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+   static const uint32_t ptypes[] = {
+   /* refers to i40e_rxd_pkt_type_mapping() */
+   RTE_PTYPE_L2_ETHER,
+   RTE_PTYPE_L2_ETHER_TIMESYNC,
+   RTE_PTYPE_L2_ETHER_LLDP,
+   RTE_PTYPE_L2_ETHER_ARP,
+   RTE_PTYPE_L3_IPV4_EXT_UNKNOWN,
+   RTE_PTYPE_L3_IPV6_EXT_UNKNOWN,
+   RTE_PTYPE_L4_FRAG,
+   RTE_PTYPE_L4_ICMP,
+   RTE_PTYPE_L4_NONFRAG,
+   RTE_PTYPE_L4_SCTP,
+   RTE_PTYPE_L4_TCP,
+   RTE_PTYPE_L4_UDP,
+   RTE_PTYPE_TUNNEL_GRENAT,
+   RTE_PTYPE_TUNNEL_IP,
+   RTE_PTYPE_INNER_L2_ETHER,
+   RTE_PTYPE_INNER_L2_ETHER_VLAN,
+   RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN,
+   RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN,
+   RTE_PTYPE_INNER_L4_FRAG,
+   RTE_PTYPE_INNER_L4_ICMP,
+   RTE_PTYPE_INNER_L4_NONFRAG,
+   RTE_PTYPE_INNER_L4_SCTP,
+   RTE_PTYPE_INNER_L4_TCP,
+   RTE_PTYPE_INNER_L4_UDP,
+   RTE_PTYPE_UNKNOWN
+   };
+
+   if (dev->rx_pkt_burst == i40e_recv_pkts ||
+#ifdef RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC
+   dev->rx_pkt_burst == i40e_recv_pkts_bulk_alloc ||
+#endif
+   dev->rx_pkt_burst == i40e_recv_scattered_pkts)
+   return ptypes;
+   return NULL;
+}
+
 int
 i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
uint16_t queue_idx,
diff --git a/drivers/net/i40e/i40e_rxtx.h b/drivers/net/i40e/i40e_rxtx.h
index 5c2f5c2..3a59d81 100644
--- a/drivers/net/i40e/i40e_rxtx.h
+++ b/drivers/net/i40e/i40e_rxtx.h
@@ -200,6 +200,7 @@ int i40e_dev_rx_queue_start(struct rte_eth_dev *dev, 
uint16_t rx_queue_id);
 int i40e_dev_rx_queue_stop(struct rte_eth_dev *dev, uint16_t rx_queue_id);
 int i40e_dev_tx_queue_start(struct rte_eth_dev *dev, uint16_t tx_queue_id);
 int i40e_dev_tx_queue_stop(struct rte_eth_dev *dev, uint16_t tx_queue_id);
+const uint32_t *i40e_dev_ptype_info_get(struct rte_eth_dev *dev);
 int i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
uint16_t queue_idx,
uint16_t nb_desc,
-- 
2.1.4



[dpdk-dev] [PATCH v5 05/11] pmd/fm10k: add dev_ptype_info_get implementation

2016-02-26 Thread Jianfeng Tan
Signed-off-by: Jianfeng Tan 
---
 drivers/net/fm10k/fm10k_ethdev.c   | 50 ++
 drivers/net/fm10k/fm10k_rxtx.c |  3 +++
 drivers/net/fm10k/fm10k_rxtx_vec.c |  3 +++
 3 files changed, 56 insertions(+)

diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 421266b..429cbdd 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -1335,6 +1335,55 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
};
 }

+#ifdef RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE
+static const uint32_t *
+fm10k_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+   if (dev->rx_pkt_burst == fm10k_recv_pkts ||
+   dev->rx_pkt_burst == fm10k_recv_scattered_pkts) {
+   static uint32_t ptypes[] = {
+   /* refers to rx_desc_to_ol_flags() */
+   RTE_PTYPE_L2_ETHER,
+   RTE_PTYPE_L3_IPV4,
+   RTE_PTYPE_L3_IPV4_EXT,
+   RTE_PTYPE_L3_IPV6,
+   RTE_PTYPE_L3_IPV6_EXT,
+   RTE_PTYPE_L4_TCP,
+   RTE_PTYPE_L4_UDP,
+   RTE_PTYPE_UNKNOWN
+   };
+
+   return ptypes;
+   } else if (dev->rx_pkt_burst == fm10k_recv_pkts_vec ||
+  dev->rx_pkt_burst == fm10k_recv_scattered_pkts_vec) {
+   static uint32_t ptypes_vec[] = {
+   /* refers to fm10k_desc_to_pktype_v() */
+   RTE_PTYPE_L3_IPV4,
+   RTE_PTYPE_L3_IPV4_EXT,
+   RTE_PTYPE_L3_IPV6,
+   RTE_PTYPE_L3_IPV6_EXT,
+   RTE_PTYPE_L4_TCP,
+   RTE_PTYPE_L4_UDP,
+   RTE_PTYPE_TUNNEL_GENEVE,
+   RTE_PTYPE_TUNNEL_NVGRE,
+   RTE_PTYPE_TUNNEL_VXLAN,
+   RTE_PTYPE_TUNNEL_GRE,
+   RTE_PTYPE_UNKNOWN
+   };
+
+   return ptypes_vec;
+   }
+
+   return NULL;
+}
+#else
+static const uint32_t *
+fm10k_dev_ptype_info_get(struct rte_eth_dev *dev __rte_unused)
+{
+   return NULL;
+}
+#endif
+
 static int
 fm10k_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
 {
@@ -2423,6 +2472,7 @@ static const struct eth_dev_ops fm10k_eth_dev_ops = {
.xstats_reset   = fm10k_stats_reset,
.link_update= fm10k_link_update,
.dev_infos_get  = fm10k_dev_infos_get,
+   .dev_ptype_info_get = fm10k_dev_ptype_info_get,
.vlan_filter_set= fm10k_vlan_filter_set,
.vlan_offload_set   = fm10k_vlan_offload_set,
.mac_addr_add   = fm10k_macaddr_add,
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index e958865..cbe0111 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -65,6 +65,9 @@ static inline void dump_rxd(union fm10k_rx_desc *rxd)
 }
 #endif

+/* @note: When this function is changed, make corresponding change to
+ * fm10k_dev_ptype_info_get()
+ */
 static inline void
 rx_desc_to_ol_flags(struct rte_mbuf *m, const union fm10k_rx_desc *d)
 {
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c 
b/drivers/net/fm10k/fm10k_rxtx_vec.c
index 2a57eef..f347641 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -109,6 +109,9 @@ fm10k_desc_to_olflags_v(__m128i descs[4], struct rte_mbuf 
**rx_pkts)
rx_pkts[3]->ol_flags = vol.e[3];
 }

+/* @note: When this function is changed, make corresponding change to
+ * fm10k_dev_ptype_info_get().
+ */
 static inline void
 fm10k_desc_to_pktype_v(__m128i descs[4], struct rte_mbuf **rx_pkts)
 {
-- 
2.1.4



[dpdk-dev] [PATCH v5 04/11] pmd/enic: add dev_ptype_info_get implementation

2016-02-26 Thread Jianfeng Tan
Signed-off-by: Jianfeng Tan 
---
 drivers/net/enic/enic_ethdev.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 2a88043..fbeab6f 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -54,6 +54,9 @@
 #define ENICPMD_FUNC_TRACE() (void)0
 #endif

+static uint16_t enicpmd_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts);
+
 /*
  * The set of PCI devices this driver supports
  */
@@ -431,6 +434,19 @@ static void enicpmd_dev_info_get(struct rte_eth_dev 
*eth_dev,
DEV_TX_OFFLOAD_TCP_CKSUM;
 }

+static const uint32_t *enicpmd_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+   static const uint32_t ptypes[] = {
+   RTE_PTYPE_L3_IPV4,
+   RTE_PTYPE_L3_IPV6,
+   RTE_PTYPE_UNKNOWN
+   };
+
+   if (dev->rx_pkt_burst == enicpmd_recv_pkts)
+   return ptypes;
+   return NULL;
+}
+
 static void enicpmd_dev_promiscuous_enable(struct rte_eth_dev *eth_dev)
 {
struct enic *enic = pmd_priv(eth_dev);
@@ -566,6 +582,7 @@ static const struct eth_dev_ops enicpmd_eth_dev_ops = {
.stats_reset  = enicpmd_dev_stats_reset,
.queue_stats_mapping_set = NULL,
.dev_infos_get= enicpmd_dev_info_get,
+   .dev_ptype_info_get   = enicpmd_dev_ptype_info_get,
.mtu_set  = NULL,
.vlan_filter_set  = enicpmd_vlan_filter_set,
.vlan_tpid_set= NULL,
-- 
2.1.4



[dpdk-dev] [PATCH v5 03/11] pmd/e1000: add dev_ptype_info_get implementation

2016-02-26 Thread Jianfeng Tan
Signed-off-by: Jianfeng Tan 
---
 drivers/net/e1000/igb_ethdev.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 4ed5e95..b3a3ee6 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -103,6 +103,7 @@ static void eth_igb_stats_reset(struct rte_eth_dev *dev);
 static void eth_igb_xstats_reset(struct rte_eth_dev *dev);
 static void eth_igb_infos_get(struct rte_eth_dev *dev,
  struct rte_eth_dev_info *dev_info);
+static const uint32_t *eth_igb_ptype_info_get(struct rte_eth_dev *dev);
 static void eth_igbvf_infos_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
 static int  eth_igb_flow_ctrl_get(struct rte_eth_dev *dev,
@@ -319,6 +320,7 @@ static const struct eth_dev_ops eth_igb_ops = {
.stats_reset  = eth_igb_stats_reset,
.xstats_reset = eth_igb_xstats_reset,
.dev_infos_get= eth_igb_infos_get,
+   .dev_ptype_info_get   = eth_igb_ptype_info_get,
.mtu_set  = eth_igb_mtu_set,
.vlan_filter_set  = eth_igb_vlan_filter_set,
.vlan_tpid_set= eth_igb_vlan_tpid_set,
@@ -376,6 +378,7 @@ static const struct eth_dev_ops igbvf_eth_dev_ops = {
.xstats_reset = eth_igbvf_stats_reset,
.vlan_filter_set  = igbvf_vlan_filter_set,
.dev_infos_get= eth_igbvf_infos_get,
+   .dev_ptype_info_get   = eth_igb_ptype_info_get,
.rx_queue_setup   = eth_igb_rx_queue_setup,
.rx_queue_release = eth_igb_rx_queue_release,
.tx_queue_setup   = eth_igb_tx_queue_setup,
@@ -1910,6 +1913,33 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->tx_desc_lim = tx_desc_lim;
 }

+static const uint32_t *
+eth_igb_ptype_info_get(struct rte_eth_dev *dev)
+{
+   static const uint32_t ptypes[] = {
+   /* refers to igb_rxd_pkt_info_to_pkt_type() */
+   RTE_PTYPE_L2_ETHER,
+   RTE_PTYPE_L3_IPV4,
+   RTE_PTYPE_L3_IPV4_EXT,
+   RTE_PTYPE_L3_IPV6,
+   RTE_PTYPE_L3_IPV6_EXT,
+   RTE_PTYPE_L4_TCP,
+   RTE_PTYPE_L4_UDP,
+   RTE_PTYPE_L4_SCTP,
+   RTE_PTYPE_TUNNEL_IP,
+   RTE_PTYPE_INNER_L3_IPV6,
+   RTE_PTYPE_INNER_L3_IPV6_EXT,
+   RTE_PTYPE_INNER_L4_TCP,
+   RTE_PTYPE_INNER_L4_UDP,
+   RTE_PTYPE_UNKNOWN
+   };
+
+   if (dev->rx_pkt_burst == eth_igb_recv_pkts ||
+   dev->rx_pkt_burst == eth_igb_recv_scattered_pkts)
+   return ptypes;
+   return NULL;
+}
+
 static void
 eth_igbvf_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 {
-- 
2.1.4



[dpdk-dev] [PATCH v5 02/11] pmd/cxgbe: add dev_ptype_info_get implementation

2016-02-26 Thread Jianfeng Tan
Signed-off-by: Jianfeng Tan 
---
 drivers/net/cxgbe/cxgbe_ethdev.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 97ef152..33bd815 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -767,6 +767,19 @@ static int cxgbe_flow_ctrl_set(struct rte_eth_dev *eth_dev,
 >link_cfg);
 }

+static const uint32_t *cxgbe_dev_ptype_info_get(struct rte_eth_dev *eth_dev)
+{
+   static const uint32_t ptypes[] = {
+   RTE_PTYPE_L3_IPV4,
+   RTE_PTYPE_L3_IPV6,
+   RTE_PTYPE_UNKNOWN
+   };
+
+   if (eth_dev->rx_pkt_burst == cxgbe_recv_pkts)
+   return ptypes;
+   return NULL;
+}
+
 static struct eth_dev_ops cxgbe_eth_dev_ops = {
.dev_start  = cxgbe_dev_start,
.dev_stop   = cxgbe_dev_stop,
@@ -777,6 +790,7 @@ static struct eth_dev_ops cxgbe_eth_dev_ops = {
.allmulticast_disable   = cxgbe_dev_allmulticast_disable,
.dev_configure  = cxgbe_dev_configure,
.dev_infos_get  = cxgbe_dev_info_get,
+   .dev_ptype_info_get = cxgbe_dev_ptype_info_get,
.link_update= cxgbe_dev_link_update,
.mtu_set= cxgbe_dev_mtu_set,
.tx_queue_setup = cxgbe_dev_tx_queue_setup,
-- 
2.1.4



[dpdk-dev] [PATCH v5 01/11] ethdev: add API to query packet type filling info

2016-02-26 Thread Jianfeng Tan
Add a new API rte_eth_dev_get_ptype_info to query whether/what packet
type can be filled by given pmd rx burst function.

Signed-off-by: Jianfeng Tan 
---
 lib/librte_ether/rte_ethdev.c | 26 ++
 lib/librte_ether/rte_ethdev.h | 26 ++
 2 files changed, 52 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 1257965..66dc7c5 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1576,6 +1576,32 @@ rte_eth_dev_info_get(uint8_t port_id, struct 
rte_eth_dev_info *dev_info)
dev_info->driver_name = dev->data->drv_name;
 }

+int
+rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptype_mask,
+  uint32_t *ptypes, int num)
+{
+   int i, j;
+   struct rte_eth_dev *dev;
+   const uint32_t *all_ptypes;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+   dev = _eth_devices[port_id];
+   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_ptype_info_get, -ENOTSUP);
+   all_ptypes = (*dev->dev_ops->dev_ptype_info_get)(dev);
+
+   if (!all_ptypes)
+   return 0;
+
+   for (i = 0, j = 0; all_ptypes[i] != RTE_PTYPE_UNKNOWN; ++i)
+   if (all_ptypes[i] & ptype_mask) {
+   if (j < num)
+   ptypes[j] = all_ptypes[i];
+   j++;
+   }
+
+   return j;
+}
+
 void
 rte_eth_macaddr_get(uint8_t port_id, struct ether_addr *mac_addr)
 {
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 16da821..16f32a0 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1021,6 +1021,9 @@ typedef void (*eth_dev_infos_get_t)(struct rte_eth_dev 
*dev,
struct rte_eth_dev_info *dev_info);
 /**< @internal Get specific informations of an Ethernet device. */

+typedef const uint32_t *(*eth_dev_ptype_info_get_t)(struct rte_eth_dev *dev);
+/**< @internal Get ptype info of eth_rx_burst_t. */
+
 typedef int (*eth_queue_start_t)(struct rte_eth_dev *dev,
uint16_t queue_id);
 /**< @internal Start rx and tx of a queue of an Ethernet device. */
@@ -1347,6 +1350,7 @@ struct eth_dev_ops {
eth_queue_stats_mapping_set_t queue_stats_mapping_set;
/**< Configure per queue stat counter mapping. */
eth_dev_infos_get_tdev_infos_get; /**< Get device info. */
+   eth_dev_ptype_info_get_t   dev_ptype_info_get; /** Get ptype info */
mtu_set_t  mtu_set; /**< Set MTU. */
vlan_filter_set_t  vlan_filter_set;  /**< Filter VLAN Setup. */
vlan_tpid_set_tvlan_tpid_set;  /**< Outer VLAN TPID 
Setup. */
@@ -2268,6 +2272,28 @@ void rte_eth_macaddr_get(uint8_t port_id, struct 
ether_addr *mac_addr);
 void rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info);

 /**
+ * Retrieve the packet type information of an Ethernet device.
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @param ptype_mask
+ *   A hint of what kind of packet type which the caller is interested in.
+ * @param ptypes
+ *   An array pointer to store adequent packet types, allocated by caller.
+ * @param num
+ *  Size of the array pointed by param ptypes.
+ * @return
+ *   - (>0) Number of ptypes supported. If it exceeds param num, exceeding
+ *  packet types will not be filled in the given array.
+ *   - (0 or -ENOTSUP) if PMD does not fill the specified ptype.
+ *   - (-ENODEV) if *port_id* invalid.
+ */
+extern int rte_eth_dev_get_ptype_info(uint8_t port_id,
+ uint32_t ptype_mask,
+ uint32_t *ptypes,
+ int num);
+
+/**
  * Retrieve the MTU of an Ethernet device.
  *
  * @param port_id
-- 
2.1.4



[dpdk-dev] [PATCH v5 00/11] Add API to get packet type info

2016-02-26 Thread Jianfeng Tan
To achieve this, a new function pointer, dev_ptype_info_get, is added
into struct eth_dev_ops. For those devices who do not implement it, it
means it will not provide any ptype info.

v5:
  - Exclude l3fwd change from this series, as a separated one.
  - Fix malposition of mlx4 code in mlx5 commit introduced in v4.

v4:
  - Change how to use this API: to previously agreement reached in mail.

v3:
  - Change how to use this API: api to allocate mem for storing ptype
array; and caller to free the mem.
  - Change how to return back ptypes from PMDs: return a pointer to
corresponding static const array of supported ptypes, terminated
by RTE_PTYPE_UNKNOWN.
  - Fix l3fwd parse_packet_type() when EXACT_MATCH is enabled.
  - Fix l3fwd memory leak when calling the API.

v2:
  - Move ptype_mask filter function from each PMDs into ether layer.
  - Add ixgbe vPMD's ptype info.
  - Fix code style issues.

Signed-off-by: Jianfeng Tan 

Jianfeng Tan (11):
  ethdev: add API to query packet type filling info
  pmd/cxgbe: add dev_ptype_info_get implementation
  pmd/e1000: add dev_ptype_info_get implementation
  pmd/enic: add dev_ptype_info_get implementation
  pmd/fm10k: add dev_ptype_info_get implementation
  pmd/i40e: add dev_ptype_info_get implementation
  pmd/ixgbe: add dev_ptype_info_get implementation
  pmd/mlx4: add dev_ptype_info_get implementation
  pmd/mlx5: add dev_ptype_info_get implementation
  pmd/nfp: add dev_ptype_info_get implementation
  pmd/vmxnet3: add dev_ptype_info_get implementation

 drivers/net/cxgbe/cxgbe_ethdev.c | 14 ++
 drivers/net/e1000/igb_ethdev.c   | 30 ++
 drivers/net/enic/enic_ethdev.c   | 17 
 drivers/net/fm10k/fm10k_ethdev.c | 50 
 drivers/net/fm10k/fm10k_rxtx.c   |  3 +++
 drivers/net/fm10k/fm10k_rxtx_vec.c   |  3 +++
 drivers/net/i40e/i40e_ethdev.c   |  1 +
 drivers/net/i40e/i40e_ethdev_vf.c|  1 +
 drivers/net/i40e/i40e_rxtx.c | 46 -
 drivers/net/i40e/i40e_rxtx.h |  1 +
 drivers/net/ixgbe/ixgbe_ethdev.c | 38 +++
 drivers/net/ixgbe/ixgbe_ethdev.h |  2 ++
 drivers/net/ixgbe/ixgbe_rxtx.c   |  4 ++-
 drivers/net/mlx4/mlx4.c  | 21 +++
 drivers/net/mlx5/mlx5.c  |  1 +
 drivers/net/mlx5/mlx5.h  |  1 +
 drivers/net/mlx5/mlx5_ethdev.c   | 20 +++
 drivers/net/mlx5/mlx5_rxtx.c |  2 ++
 drivers/net/nfp/nfp_net.c| 19 ++
 drivers/net/vmxnet3/vmxnet3_ethdev.c | 16 
 lib/librte_ether/rte_ethdev.c| 26 +++
 lib/librte_ether/rte_ethdev.h| 26 +++
 22 files changed, 340 insertions(+), 2 deletions(-)

-- 
2.1.4



[dpdk-dev] [PATCH v3 3/3] null: remove duplicate fields in internal data struct

2016-02-26 Thread Ferruh Yigit
1- remove duplicate nb_rx/tx_queues fields from internals
2- remove duplicate numa_node field from internals

Signed-off-by: Ferruh Yigit 
Tested-by: Tetsuya Mukawa 
Acked-by: Tetsuya Mukawa 
Acked-by: Nicolas Pernas Maradei 
---
 drivers/net/null/rte_eth_null.c | 36 
 1 file changed, 12 insertions(+), 24 deletions(-)

diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 77fc988..1c354ad 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -69,10 +69,6 @@ struct null_queue {
 struct pmd_internals {
unsigned packet_size;
unsigned packet_copy;
-   unsigned numa_node;
-
-   unsigned nb_rx_queues;
-   unsigned nb_tx_queues;

struct null_queue rx_null_queues[RTE_MAX_QUEUES_PER_PORT];
struct null_queue tx_null_queues[RTE_MAX_QUEUES_PER_PORT];
@@ -192,13 +188,8 @@ eth_null_copy_tx(void *q, struct rte_mbuf **bufs, uint16_t 
nb_bufs)
 }

 static int
-eth_dev_configure(struct rte_eth_dev *dev) {
-   struct pmd_internals *internals;
-
-   internals = dev->data->dev_private;
-   internals->nb_rx_queues = dev->data->nb_rx_queues;
-   internals->nb_tx_queues = dev->data->nb_tx_queues;
-
+eth_dev_configure(struct rte_eth_dev *dev __rte_unused)
+{
return 0;
 }

@@ -237,7 +228,7 @@ eth_rx_queue_setup(struct rte_eth_dev *dev, uint16_t 
rx_queue_id,

internals = dev->data->dev_private;

-   if (rx_queue_id >= internals->nb_rx_queues)
+   if (rx_queue_id >= dev->data->nb_rx_queues)
return -ENODEV;

packet_size = internals->packet_size;
@@ -246,7 +237,7 @@ eth_rx_queue_setup(struct rte_eth_dev *dev, uint16_t 
rx_queue_id,
dev->data->rx_queues[rx_queue_id] =
>rx_null_queues[rx_queue_id];
dummy_packet = rte_zmalloc_socket(NULL,
-   packet_size, 0, internals->numa_node);
+   packet_size, 0, dev->data->numa_node);
if (dummy_packet == NULL)
return -ENOMEM;

@@ -271,7 +262,7 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t 
tx_queue_id,

internals = dev->data->dev_private;

-   if (tx_queue_id >= internals->nb_tx_queues)
+   if (tx_queue_id >= dev->data->nb_tx_queues)
return -ENODEV;

packet_size = internals->packet_size;
@@ -279,7 +270,7 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t 
tx_queue_id,
dev->data->tx_queues[tx_queue_id] =
>tx_null_queues[tx_queue_id];
dummy_packet = rte_zmalloc_socket(NULL,
-   packet_size, 0, internals->numa_node);
+   packet_size, 0, dev->data->numa_node);
if (dummy_packet == NULL)
return -ENOMEM;

@@ -323,7 +314,7 @@ eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats 
*igb_stats)

internal = dev->data->dev_private;
num_stats = RTE_MIN((unsigned)RTE_ETHDEV_QUEUE_STAT_CNTRS,
-   RTE_MIN(internal->nb_rx_queues,
+   RTE_MIN(dev->data->nb_rx_queues,
RTE_DIM(internal->rx_null_queues)));
for (i = 0; i < num_stats; i++) {
igb_stats->q_ipackets[i] =
@@ -332,7 +323,7 @@ eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats 
*igb_stats)
}

num_stats = RTE_MIN((unsigned)RTE_ETHDEV_QUEUE_STAT_CNTRS,
-   RTE_MIN(internal->nb_tx_queues,
+   RTE_MIN(dev->data->nb_tx_queues,
RTE_DIM(internal->tx_null_queues)));
for (i = 0; i < num_stats; i++) {
igb_stats->q_opackets[i] =
@@ -535,11 +526,8 @@ eth_dev_null_create(const char *name,
/* NOTE: we'll replace the data element, of originally allocated eth_dev
 * so the nulls are local per-process */

-   internals->nb_rx_queues = nb_rx_queues;
-   internals->nb_tx_queues = nb_tx_queues;
internals->packet_size = packet_size;
internals->packet_copy = packet_copy;
-   internals->numa_node = numa_node;

internals->flow_type_rss_offloads =  ETH_RSS_PROTO_MASK;
internals->reta_size = RTE_DIM(internals->reta_conf) * 
RTE_RETA_GROUP_SIZE;
@@ -560,10 +548,10 @@ eth_dev_null_create(const char *name,
TAILQ_INIT(_dev->link_intr_cbs);

eth_dev->driver = NULL;
-   eth_dev->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
-   eth_dev->data->kdrv = RTE_KDRV_NONE;
-   eth_dev->data->drv_name = drivername;
-   eth_dev->data->numa_node = numa_node;
+   data->dev_flags = RTE_ETH_DEV_DETACHABLE;
+   data->kdrv = RTE_KDRV_NONE;
+   data->drv_name = drivername;
+   data->numa_node = numa_node;

/* finally assign rx and tx ops */
if (packet_copy) {
-- 
2.5.0



[dpdk-dev] [PATCH v3 2/3] ring: rename fields in internal data struct

2016-02-26 Thread Ferruh Yigit
Rename nb_rx/tx_queues fields in internals struct to max_rx/tx_queues

This patch just does variable renaming to help understanding code better,
nothing changed in functionality of the code.

Updated fields required to keep max queue numbers configured. For current
queue number requirements data->nb_rx/tx_queues fields used.

Signed-off-by: Ferruh Yigit 
---
 drivers/net/ring/rte_eth_ring.c | 59 -
 1 file changed, 29 insertions(+), 30 deletions(-)

diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index d92b088..c9ecb0e 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -59,8 +59,8 @@ struct ring_queue {
 };

 struct pmd_internals {
-   unsigned nb_rx_queues;
-   unsigned nb_tx_queues;
+   unsigned max_rx_queues;
+   unsigned max_tx_queues;

struct ring_queue rx_ring_queues[RTE_PMD_RING_MAX_RX_RINGS];
struct ring_queue tx_ring_queues[RTE_PMD_RING_MAX_TX_RINGS];
@@ -138,7 +138,7 @@ eth_dev_set_link_up(struct rte_eth_dev *dev)
 }

 static int
-eth_rx_queue_setup(struct rte_eth_dev *dev,uint16_t rx_queue_id,
+eth_rx_queue_setup(struct rte_eth_dev *dev, uint16_t rx_queue_id,
uint16_t nb_rx_desc __rte_unused,
unsigned int socket_id __rte_unused,
const struct rte_eth_rxconf *rx_conf 
__rte_unused,
@@ -169,36 +169,36 @@ eth_dev_info(struct rte_eth_dev *dev,
dev_info->driver_name = drivername;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (uint32_t)-1;
-   dev_info->max_rx_queues = (uint16_t)internals->nb_rx_queues;
-   dev_info->max_tx_queues = (uint16_t)internals->nb_tx_queues;
+   dev_info->max_rx_queues = (uint16_t)internals->max_rx_queues;
+   dev_info->max_tx_queues = (uint16_t)internals->max_tx_queues;
dev_info->min_rx_bufsize = 0;
dev_info->pci_dev = NULL;
 }

 static void
-eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *igb_stats)
+eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
 {
unsigned i;
unsigned long rx_total = 0, tx_total = 0, tx_err_total = 0;
const struct pmd_internals *internal = dev->data->dev_private;

for (i = 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS &&
-   i < internal->nb_rx_queues; i++) {
-   igb_stats->q_ipackets[i] = 
internal->rx_ring_queues[i].rx_pkts.cnt;
-   rx_total += igb_stats->q_ipackets[i];
+   i < dev->data->nb_rx_queues; i++) {
+   stats->q_ipackets[i] = internal->rx_ring_queues[i].rx_pkts.cnt;
+   rx_total += stats->q_ipackets[i];
}

for (i = 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS &&
-   i < internal->nb_tx_queues; i++) {
-   igb_stats->q_opackets[i] = 
internal->tx_ring_queues[i].tx_pkts.cnt;
-   igb_stats->q_errors[i] = 
internal->tx_ring_queues[i].err_pkts.cnt;
-   tx_total += igb_stats->q_opackets[i];
-   tx_err_total += igb_stats->q_errors[i];
+   i < dev->data->nb_tx_queues; i++) {
+   stats->q_opackets[i] = internal->tx_ring_queues[i].tx_pkts.cnt;
+   stats->q_errors[i] = internal->tx_ring_queues[i].err_pkts.cnt;
+   tx_total += stats->q_opackets[i];
+   tx_err_total += stats->q_errors[i];
}

-   igb_stats->ipackets = rx_total;
-   igb_stats->opackets = tx_total;
-   igb_stats->oerrors = tx_err_total;
+   stats->ipackets = rx_total;
+   stats->opackets = tx_total;
+   stats->oerrors = tx_err_total;
 }

 static void
@@ -206,9 +206,9 @@ eth_stats_reset(struct rte_eth_dev *dev)
 {
unsigned i;
struct pmd_internals *internal = dev->data->dev_private;
-   for (i = 0; i < internal->nb_rx_queues; i++)
+   for (i = 0; i < dev->data->nb_rx_queues; i++)
internal->rx_ring_queues[i].rx_pkts.cnt = 0;
-   for (i = 0; i < internal->nb_tx_queues; i++) {
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
internal->tx_ring_queues[i].tx_pkts.cnt = 0;
internal->tx_ring_queues[i].err_pkts.cnt = 0;
}
@@ -262,7 +262,6 @@ rte_eth_from_rings(const char *name, struct rte_ring *const 
rx_queues[],
struct rte_eth_dev_data *data = NULL;
struct pmd_internals *internals = NULL;
struct rte_eth_dev *eth_dev = NULL;
-
unsigned i;

/* do some parameter checking */
@@ -291,15 +290,15 @@ rte_eth_from_rings(const char *name, struct rte_ring 
*const rx_queues[],
goto error;
}

-   data->rx_queues = rte_zmalloc_socket(name, sizeof(void *) * 
nb_rx_queues,
-   0, numa_node);
+   data->rx_queues = rte_zmalloc_socket(name,
+   sizeof(void *) * nb_rx_queues, 0, numa_node);
if 

[dpdk-dev] [PATCH v3 1/3] pcap: remove duplicate fields in internal data struct

2016-02-26 Thread Ferruh Yigit
1- Remove duplicate nb_rx/tx_queues fields from internals
2- Move duplicate code into a common function

Signed-off-by: Ferruh Yigit 
Acked-by: Nicolas Pernas Maradei 
---
 drivers/net/pcap/rte_eth_pcap.c | 130 +++-
 1 file changed, 61 insertions(+), 69 deletions(-)

diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index f9230eb..c8b7dbd 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -103,8 +103,6 @@ struct tx_pcaps {
 struct pmd_internals {
struct pcap_rx_queue rx_queue[RTE_PMD_RING_MAX_RX_RINGS];
struct pcap_tx_queue tx_queue[RTE_PMD_RING_MAX_TX_RINGS];
-   unsigned nb_rx_queues;
-   unsigned nb_tx_queues;
int if_index;
int single_iface;
 };
@@ -396,7 +394,7 @@ eth_dev_start(struct rte_eth_dev *dev)
}

/* If not open already, open tx pcaps/dumpers */
-   for (i = 0; i < internals->nb_tx_queues; i++) {
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
tx = >tx_queue[i];

if (!tx->dumper && strcmp(tx->type, ETH_PCAP_TX_PCAP_ARG) == 0) 
{
@@ -411,7 +409,7 @@ eth_dev_start(struct rte_eth_dev *dev)
}

/* If not open already, open rx pcaps */
-   for (i = 0; i < internals->nb_rx_queues; i++) {
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
rx = >rx_queue[i];

if (rx->pcap != NULL)
@@ -457,7 +455,7 @@ eth_dev_stop(struct rte_eth_dev *dev)
goto status_down;
}

-   for (i = 0; i < internals->nb_tx_queues; i++) {
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
tx = >tx_queue[i];

if (tx->dumper != NULL) {
@@ -471,7 +469,7 @@ eth_dev_stop(struct rte_eth_dev *dev)
}
}

-   for (i = 0; i < internals->nb_rx_queues; i++) {
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
rx = >rx_queue[i];

if (rx->pcap != NULL) {
@@ -499,8 +497,8 @@ eth_dev_info(struct rte_eth_dev *dev,
dev_info->if_index = internals->if_index;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (uint32_t) -1;
-   dev_info->max_rx_queues = (uint16_t)internals->nb_rx_queues;
-   dev_info->max_tx_queues = (uint16_t)internals->nb_tx_queues;
+   dev_info->max_rx_queues = dev->data->nb_rx_queues;
+   dev_info->max_tx_queues = dev->data->nb_tx_queues;
dev_info->min_rx_bufsize = 0;
dev_info->pci_dev = NULL;
 }
@@ -515,16 +513,16 @@ eth_stats_get(struct rte_eth_dev *dev,
unsigned long tx_packets_err_total = 0;
const struct pmd_internals *internal = dev->data->dev_private;

-   for (i = 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS && i < 
internal->nb_rx_queues;
-   i++) {
+   for (i = 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS &&
+   i < dev->data->nb_rx_queues; i++) {
igb_stats->q_ipackets[i] = internal->rx_queue[i].rx_pkts;
igb_stats->q_ibytes[i] = internal->rx_queue[i].rx_bytes;
rx_packets_total += igb_stats->q_ipackets[i];
rx_bytes_total += igb_stats->q_ibytes[i];
}

-   for (i = 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS && i < 
internal->nb_tx_queues;
-   i++) {
+   for (i = 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS &&
+   i < dev->data->nb_tx_queues; i++) {
igb_stats->q_opackets[i] = internal->tx_queue[i].tx_pkts;
igb_stats->q_obytes[i] = internal->tx_queue[i].tx_bytes;
igb_stats->q_errors[i] = internal->tx_queue[i].err_pkts;
@@ -545,11 +543,11 @@ eth_stats_reset(struct rte_eth_dev *dev)
 {
unsigned i;
struct pmd_internals *internal = dev->data->dev_private;
-   for (i = 0; i < internal->nb_rx_queues; i++) {
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
internal->rx_queue[i].rx_pkts = 0;
internal->rx_queue[i].rx_bytes = 0;
}
-   for (i = 0; i < internal->nb_tx_queues; i++) {
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
internal->tx_queue[i].tx_pkts = 0;
internal->tx_queue[i].tx_bytes = 0;
internal->tx_queue[i].err_pkts = 0;
@@ -840,9 +838,6 @@ rte_pmd_init_internals(const char *name, const unsigned 
nb_rx_queues,
/* NOTE: we'll replace the data element, of originally allocated eth_dev
 * so the rings are local per-process */

-   (*internals)->nb_rx_queues = nb_rx_queues;
-   (*internals)->nb_tx_queues = nb_tx_queues;
-
if (pair == NULL)
(*internals)->if_index = 0;
else
@@ -860,11 +855,11 @@ rte_pmd_init_internals(const char *name, const unsigned 
nb_rx_queues,

(*eth_dev)->data = data;
(*eth_dev)->dev_ops = 
-   (*eth_dev)->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
(*eth_dev)->driver = NULL;
- 

[dpdk-dev] [PATCH v3 0/3] clean-up on virtual PMDs

2016-02-26 Thread Ferruh Yigit
This is a clean-up patch, no defect fixed, no functional difference 
expected.

Patch removes duplicated fields between data->dev_private
and data (struct rte_eth_dev_data) for pcap and null PMDs.
For ring, renames some fields in private structure.

Also for pcap: move a common code into a function

v3:
* ring: Add fields in internal data struct back, rename them
these fields required to keep max configured queue number

v2:
* ring: Add memory allocation and queue assignment back, 
these are to make rte_eth_from_ring() work without 
rte_eth_dev_configure() or rte_eth_rx/tx_queue_setup() calls


Ferruh Yigit (3):
  pcap: remove duplicate fields in internal data struct
  ring: rename fields in internal data struct
  null: remove duplicate fields in internal data struct

 drivers/net/null/rte_eth_null.c |  36 ---
 drivers/net/pcap/rte_eth_pcap.c | 130 +++-
 drivers/net/ring/rte_eth_ring.c |  59 +-
 3 files changed, 102 insertions(+), 123 deletions(-)

-- 
2.5.0



[dpdk-dev] [PATCH] virtio: don't count broadcast packets in multicast packets counter

2016-02-26 Thread Van Haaren, Harry
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Igor Ryzhov
> Sent: Friday, February 26, 2016 3:01 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] virtio: don't count broadcast packets in 
> multicast packets
> counter
> 
> Signed-off-by: Igor Ryzhov 

Acked-by: Harry van Haaren 


[dpdk-dev] [PATCH v2] examples/skeleton-cat: PQoS CAT and CDP, example of libpqos usage

2016-02-26 Thread Wojciech Andralojc
Because of the feedback that we have received off the mailing list,
that extending EAL commands is not an option due to the
Intel Architecture nature of CAT,
we have changed the design of PQoS patch.

The current V2 patch implements a sample code, based on the DPDK skeleton
example app, that links against the existing 01.org PQoS library
(https://github.com/01org/intel-cmt-cat).
This eliminates the need for librte_pqos and EAL extensions introduced in
the V1 patch. The sample code implements a C module that parses
the application specific part of the command line with CAT configuration
options (--l3ca, same format as the V1 patch EAL command, but expects
CPU ids rather than lcores).
The module is easy to re-use in other applications as needed.

Signed-off-by: Wojciech Andralojc 
Signed-off-by: Tomasz Kantecki 
Signed-off-by: Marcel D Cornu 
---
Version 2:
* Added signal handlers to do clean-up on SIGINT and SIGTERM
* Clean-up function modified to zero globals (needed for testing)
* Init function modified to return more applicable errnos

Version 1:
* Initial version

Details of "--l3ca" app parameter to configure Intel CAT and CDP features:
--l3ca=bitmask@
--l3ca=(code_bitmask,data_bitmask)@

makes selected CPU's use specified CAT bitmasks, bitmasks must be
expressed in hexadecimal form

CAT and CDP features allow management of the CPU's last level cache.
CAT introduces classes of service (COS) that are essentially bitmasks.
In current CAT implementations, a bit in a COS bitmask corresponds to
one cache way in the last level cache.
A CPU core is always assigned to one of the CAT classes.
By programming CPU core assignment and COS bitmasks, applications can be
given exclusive, shared, or mixed access to the CPU's last level cache.
CDP extends CAT so that there are two bitmasks per COS,
one for data and one for code.
The number of classes and number of valid bits in a COS bitmask is CPU
model specific and COS bitmasks need to be contiguous. Sample code calls
this bitmask a cbm or a capacity bitmask.
By default, after reset, all CPU cores are assigned to COS 0 and all
classes are programmed to allow fill into all cache ways.
CDP is off by default.

For more information about CAT please see
https://github.com/01org/intel-cmt-cat

Known issues and limitations:
- --l3ca must be a first app parameter
---
 MAINTAINERS   |   4 +
 doc/guides/sample_app_ug/index.rst|   1 +
 doc/guides/sample_app_ug/skeleton-cat.rst | 461 ++
 examples/Makefile |   1 +
 examples/skeleton-cat/Makefile|  68 ++
 examples/skeleton-cat/basicfwd-cat.c  | 220 +++
 examples/skeleton-cat/cat.c   | 992 ++
 examples/skeleton-cat/cat.h   |  72 +++
 8 files changed, 1819 insertions(+)
 create mode 100644 doc/guides/sample_app_ug/skeleton-cat.rst
 create mode 100644 examples/skeleton-cat/Makefile
 create mode 100644 examples/skeleton-cat/basicfwd-cat.c
 create mode 100644 examples/skeleton-cat/cat.c
 create mode 100644 examples/skeleton-cat/cat.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 628bc05..7a6702b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -600,3 +600,7 @@ F: doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst
 M: Pablo de Lara 
 M: Daniel Mrzyglod 
 F: examples/ptpclient/
+
+M: Tomasz Kantecki 
+F: examples/skeleton-cat/
+F: doc/guides/sample_app_ug/skeleton-cat.rst
\ No newline at end of file
diff --git a/doc/guides/sample_app_ug/index.rst 
b/doc/guides/sample_app_ug/index.rst
index 8a646dd..f065e54 100644
--- a/doc/guides/sample_app_ug/index.rst
+++ b/doc/guides/sample_app_ug/index.rst
@@ -41,6 +41,7 @@ Sample Applications User Guide
 exception_path
 hello_world
 skeleton
+skeleton-cat
 rxtx_callbacks
 ip_frag
 ipv4_multicast
diff --git a/doc/guides/sample_app_ug/skeleton-cat.rst 
b/doc/guides/sample_app_ug/skeleton-cat.rst
new file mode 100644
index 000..cc174fc
--- /dev/null
+++ b/doc/guides/sample_app_ug/skeleton-cat.rst
@@ -0,0 +1,461 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR 

[dpdk-dev] [PATCH v3 2/2] i40evf: support to report pf reset event

2016-02-26 Thread Jingjing Wu
When Linux PF and DPDK VF are used for i40e PMD, In case of PF reset,
interrupt will go via adminq event, VF need be informed the event,
a callback mechanism is introduced by VF. This will allow VF to
invoke callback when reset happens.
Users can register a callback for this interrupt event like:
  rte_eth_dev_callback_register(portid,
RTE_ETH_EVENT_INTR_RESET,
reset_event_callback,
arg);

Signed-off-by: Jingjing Wu 
---
 doc/guides/rel_notes/release_16_04.rst |   1 +
 drivers/net/i40e/i40e_ethdev_vf.c  | 272 +
 lib/librte_ether/rte_ethdev.h  |   1 +
 3 files changed, 245 insertions(+), 29 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 3036f7d..596b6e2 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -70,6 +70,7 @@ This section should contain new features added in this 
release. Sample format:

 * **szedata2: Add functions for setting link up/down.**

+* **Added pf reset event reported in i40e vf PMD driver.

 Resolved Issues
 ---
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 4b15ed6..b6e360b 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -74,8 +74,6 @@
 #define I40EVF_BUSY_WAIT_DELAY 10
 #define I40EVF_BUSY_WAIT_COUNT 50
 #define MAX_RESET_WAIT_CNT 20
-/*ITR index for NOITR*/
-#define I40E_QINT_RQCTL_MSIX_INDX_NOITR 3

 struct i40evf_arq_msg_info {
enum i40e_virtchnl_ops ops;
@@ -151,6 +149,9 @@ static int
 i40evf_dev_rx_queue_intr_enable(struct rte_eth_dev *dev, uint16_t queue_id);
 static int
 i40evf_dev_rx_queue_intr_disable(struct rte_eth_dev *dev, uint16_t queue_id);
+static void i40evf_handle_pf_event(__rte_unused struct rte_eth_dev *dev,
+  uint8_t *msg,
+  uint16_t msglen);

 /* Default hash key buffer for RSS */
 static uint32_t rss_key_default[I40E_VFQF_HKEY_MAX_INDEX + 1];
@@ -355,19 +356,40 @@ i40evf_execute_vf_cmd(struct rte_eth_dev *dev, struct 
vf_cmd_info *args)
return err;
}

-   do {
-   ret = i40evf_read_pfmsg(dev, );
-   if (ret == I40EVF_MSG_CMD) {
-   err = 0;
-   break;
-   } else if (ret == I40EVF_MSG_ERR) {
-   err = -1;
-   break;
-   }
-   rte_delay_ms(ASQ_DELAY_MS);
-   /* If don't read msg or read sys event, continue */
-   } while (i++ < MAX_TRY_TIMES);
-   _clear_cmd(vf);
+   switch (args->ops) {
+   case I40E_VIRTCHNL_OP_RESET_VF:
+   /*no need to process in this function */
+   break;
+   case I40E_VIRTCHNL_OP_VERSION:
+   case I40E_VIRTCHNL_OP_GET_VF_RESOURCES:
+   /* for init adminq commands, need to poll the response */
+   do {
+   ret = i40evf_read_pfmsg(dev, );
+   if (ret == I40EVF_MSG_CMD) {
+   err = 0;
+   break;
+   } else if (ret == I40EVF_MSG_ERR) {
+   err = -1;
+   break;
+   }
+   rte_delay_ms(ASQ_DELAY_MS);
+   /* If don't read msg or read sys event, continue */
+   } while (i++ < MAX_TRY_TIMES);
+   _clear_cmd(vf);
+   break;
+
+   default:
+   /* for other adminq in running time, waiting the cmd done flag 
*/
+   do {
+   if (vf->pend_cmd == I40E_VIRTCHNL_OP_UNKNOWN) {
+   err = 0;
+   break;
+   }
+   rte_delay_ms(ASQ_DELAY_MS);
+   /* If don't read msg or read sys event, continue */
+   } while (i++ < MAX_TRY_TIMES);
+   break;
+   }

return err | vf->cmd_retval;
 }
@@ -716,7 +738,7 @@ i40evf_config_irq_map(struct rte_eth_dev *dev)

map_info = (struct i40e_virtchnl_irq_map_info *)cmd_buffer;
map_info->num_vectors = 1;
-   map_info->vecmap[0].rxitr_idx = I40E_QINT_RQCTL_MSIX_INDX_NOITR;
+   map_info->vecmap[0].rxitr_idx = I40E_ITR_INDEX_DEFAULT;
map_info->vecmap[0].vsi_id = vf->vsi_res->vsi_id;
/* Alway use default dynamic MSIX interrupt */
map_info->vecmap[0].vector_id = vector_id;
@@ -1090,6 +1112,38 @@ i40evf_dev_atomic_write_link_status(struct rte_eth_dev 
*dev,
return 0;
 }

+/* Disable IRQ0 */
+static inline void
+i40evf_disable_irq0(struct i40e_hw *hw)
+{
+   /* Disable all interrupt types */
+   I40E_WRITE_REG(hw, I40E_VFINT_ICR0_ENA1, 0);
+   I40E_WRITE_REG(hw, I40E_VFINT_DYN_CTL01,
+  

[dpdk-dev] [PATCH v3 1/2] i40evf: allocate virtchnl cmd buffer for each vf

2016-02-26 Thread Jingjing Wu
Currently, i40evf PMD uses a global static buffer to send virtchnl
command to host driver. It is shared by multi VFs.
This patch changed to allocate virtchnl cmd buffer for each VF.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/i40e_ethdev.h|   2 +
 drivers/net/i40e/i40e_ethdev_vf.c | 178 +++---
 2 files changed, 71 insertions(+), 109 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index db6173a..93adc49 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -494,7 +494,9 @@ struct i40e_vf {
bool link_up;
bool vf_reset;
volatile uint32_t pend_cmd; /* pending command not finished yet */
+   uint32_t cmd_retval; /* return value of the cmd response from PF */
u16 pend_msg; /* flags indicates events from pf not handled yet */
+   uint8_t *aq_resp; /* buffer to store the adminq response from PF */

/* VSI info */
struct i40e_virtchnl_vf_resource *vf_res; /* All VSIs */
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 13c5b3d..4b15ed6 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -103,9 +103,6 @@ enum i40evf_aq_result {
I40EVF_MSG_CMD,  /* Read async command result */
 };

-/* A share buffer to store the command result from PF driver */
-static uint8_t cmd_result_buffer[I40E_AQ_BUF_SZ];
-
 static int i40evf_dev_configure(struct rte_eth_dev *dev);
 static int i40evf_dev_start(struct rte_eth_dev *dev);
 static void i40evf_dev_stop(struct rte_eth_dev *dev);
@@ -237,31 +234,37 @@ i40evf_set_mac_type(struct i40e_hw *hw)
 }

 /*
- * Parse admin queue message.
- *
- * return value:
- *  < 0: meet error
- *  0: read sys msg
- *  > 0: read cmd result
+ * Read data in admin queue to get msg from pf driver
  */
 static enum i40evf_aq_result
-i40evf_parse_pfmsg(struct i40e_vf *vf,
-  struct i40e_arq_event_info *event,
-  struct i40evf_arq_msg_info *data)
+i40evf_read_pfmsg(struct rte_eth_dev *dev, struct i40evf_arq_msg_info *data)
 {
-   enum i40e_virtchnl_ops opcode = (enum i40e_virtchnl_ops)\
-   rte_le_to_cpu_32(event->desc.cookie_high);
-   enum i40e_status_code retval = (enum i40e_status_code)\
-   rte_le_to_cpu_32(event->desc.cookie_low);
-   enum i40evf_aq_result ret = I40EVF_MSG_CMD;
+   struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
+   struct i40e_arq_event_info event;
+   enum i40e_virtchnl_ops opcode;
+   enum i40e_status_code retval;
+   int ret;
+   enum i40evf_aq_result result = I40EVF_MSG_NON;
+
+   event.buf_len = data->buf_len;
+   event.msg_buf = data->msg;
+   ret = i40e_clean_arq_element(hw, , NULL);
+   /* Can't read any msg from adminQ */
+   if (ret) {
+   if (ret != I40E_ERR_ADMIN_QUEUE_NO_WORK)
+   result = I40EVF_MSG_ERR;
+   return result;
+   }

+   opcode = (enum 
i40e_virtchnl_ops)rte_le_to_cpu_32(event.desc.cookie_high);
+   retval = (enum i40e_status_code)rte_le_to_cpu_32(event.desc.cookie_low);
/* pf sys event */
if (opcode == I40E_VIRTCHNL_OP_EVENT) {
struct i40e_virtchnl_pf_event *vpe =
-   (struct i40e_virtchnl_pf_event *)event->msg_buf;
+   (struct i40e_virtchnl_pf_event *)event.msg_buf;

-   /* Initialize ret to sys event */
-   ret = I40EVF_MSG_SYS;
+   result = I40EVF_MSG_SYS;
switch (vpe->event) {
case I40E_VIRTCHNL_EVENT_LINK_CHANGE:
vf->link_up =
@@ -286,74 +289,17 @@ i40evf_parse_pfmsg(struct i40e_vf *vf,
}
} else {
/* async reply msg on command issued by vf previously */
-   ret = I40EVF_MSG_CMD;
+   result = I40EVF_MSG_CMD;
/* Actual data length read from PF */
-   data->msg_len = event->msg_len;
+   data->msg_len = event.msg_len;
}
-   /* fill the ops and result to notify VF */
+
data->result = retval;
data->ops = opcode;

-   return ret;
-}
-
-/*
- * Read data in admin queue to get msg from pf driver
- */
-static enum i40evf_aq_result
-i40evf_read_pfmsg(struct rte_eth_dev *dev, struct i40evf_arq_msg_info *data)
-{
-   struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
-   struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
-   struct i40e_arq_event_info event;
-   int ret;
-   enum i40evf_aq_result result = I40EVF_MSG_NON;
-
-   event.buf_len = data->buf_len;
-   event.msg_buf = data->msg;
-   ret = i40e_clean_arq_element(hw, , NULL);
-   /* Can't read any msg from 

[dpdk-dev] [PATCH v3 0/2] i40evf: pf reset event report

2016-02-26 Thread Jingjing Wu
v3 changes:
 - commit log doc rewording.
 - rebase on latest dpdk-next-net/rel_16_04 branch.
 - remove few useless line
 - adjust interval and increase times for waiting pf msg

v2 changes:
 - remove the change on vf reset status checking
 - add pf event report support in release note

When Linux PF and DPDK VF are used for i40e PMD, In case of PF reset,
interrupt request will go via adminq event, VF need be informed, a callback
mechanism is introduced by VF. This will allow VF to invoke callback when
reset happens.
Users can register a callback for this interrupt event like:
rte_eth_dev_callback_register(portid,
RTE_ETH_EVENT_INTR_RESET,
reset_event_callback,
arg);

Jingjing Wu (2):
  i40evf: allocate virtchnl cmd buffer for each vf
  i40evf: support to report pf reset event

 doc/guides/rel_notes/release_16_04.rst |   1 +
 drivers/net/i40e/i40e_ethdev.h |   2 +
 drivers/net/i40e/i40e_ethdev_vf.c  | 420 +++--
 lib/librte_ether/rte_ethdev.h  |   1 +
 4 files changed, 301 insertions(+), 123 deletions(-)

-- 
2.4.0



[dpdk-dev] [PATCH 3/3 v2] ixgbe: fix setting of VF MAC address

2016-02-26 Thread Bernard Iremonger
Fix setting of VF MAC address to allow a zero address.
Reprogram the RAR[0] with a zero MAC address, to ensure
ensure that the VF traffic goes to the PF after stop,
close and detach of the VF.

Fixes: af75078fece3 ("first public release")
Fixes: 00e30184daa0 ("ixgbe: add PF support")

ixgbe: don't overwrite perm addr
Signed-off-by: Bernard Iremonger 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 10 +-
 drivers/net/ixgbe/ixgbe_pf.c |  7 ---
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 759177a..5608f67 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3902,6 +3902,7 @@ static void
 ixgbevf_dev_close(struct rte_eth_dev *dev)
 {
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct ether_addr *addr = (struct ether_addr *)hw->mac.addr;

PMD_INIT_FUNC_TRACE();

@@ -3911,7 +3912,14 @@ ixgbevf_dev_close(struct rte_eth_dev *dev)

ixgbe_dev_free_queues(dev);

-   /* reprogram the RAR[0] in case user changed it. */
+   memset(addr->addr_bytes, 0, ETHER_ADDR_LEN);
+
+   /**
+* reprogram the RAR[0] with a zero mac address.
+* to ensure that the VF traffic goes to the PF
+* after stop, close and detach of the VF
+**/
+
ixgbe_set_rar(hw, 0, hw->mac.addr, 0, IXGBE_RAH_AV);
 }

diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c
index 2ffbd1f..e5cfd05 100644
--- a/drivers/net/ixgbe/ixgbe_pf.c
+++ b/drivers/net/ixgbe/ixgbe_pf.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -445,8 +445,9 @@ ixgbe_vf_set_mac_addr(struct rte_eth_dev *dev, uint32_t vf, 
uint32_t *msgbuf)
int rar_entry = hw->mac.num_rar_entries - (vf + 1);
uint8_t *new_mac = (uint8_t *)([1]);

-   if (is_valid_assigned_ether_addr((struct ether_addr*)new_mac)) {
-   rte_memcpy(vfinfo[vf].vf_mac_addresses, new_mac, 6);
+   if (is_unicast_ether_addr((struct ether_addr *)new_mac)) {
+   if (!is_zero_ether_addr((struct ether_addr *)new_mac))
+   rte_memcpy(vfinfo[vf].vf_mac_addresses, new_mac, 6);
return hw->mac.ops.set_rar(hw, rar_entry, new_mac, vf, 
IXGBE_RAH_AV);
}
return -1;
-- 
2.6.3



[dpdk-dev] [PATCH 2/3 v2] ixgbe: add more information to the error message

2016-02-26 Thread Bernard Iremonger
Add the nb_rx_q and nb_tx_q values to the error message
to give details about the error.

Fixes: 27b609cbd1c6 ("ethdev: move the multi-queue mode check to specific 
drivers")
Signed-off-by: Bernard Iremonger 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 0db7f51..759177a 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1835,7 +1835,9 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
if ((nb_rx_q > RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool) ||
(nb_tx_q > RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool)) {
PMD_INIT_LOG(ERR, "SRIOV is active,"
-   " queue number must less equal to %d.",
+   " nb_rx_q=%d nb_tx_q=%d queue number"
+   " must be less than or equal to %d.",
+   nb_rx_q, nb_tx_q,
RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool);
return -EINVAL;
}
-- 
2.6.3



[dpdk-dev] [PATCH 1/3 v2] ixgbe: cleanup eth_ixgbevf_dev_uninit

2016-02-26 Thread Bernard Iremonger
Releasing the rx and tx queues is already done in ixgbe_dev_close()
so it does not need to be done in eth_ixgbevf_dev_uninit().

Fixes: 2866c5f1b87e ("ixgbe: support port hotplug")
Signed-off-by: Bernard Iremonger 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 3e6fe86..0db7f51 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -1390,7 +1390,6 @@ static int
 eth_ixgbevf_dev_uninit(struct rte_eth_dev *eth_dev)
 {
struct ixgbe_hw *hw;
-   unsigned i;

PMD_INIT_FUNC_TRACE();

@@ -1409,18 +1408,6 @@ eth_ixgbevf_dev_uninit(struct rte_eth_dev *eth_dev)
/* Disable the interrupts for VF */
ixgbevf_intr_disable(hw);

-   for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
-   ixgbe_dev_rx_queue_release(eth_dev->data->rx_queues[i]);
-   eth_dev->data->rx_queues[i] = NULL;
-   }
-   eth_dev->data->nb_rx_queues = 0;
-
-   for (i = 0; i < eth_dev->data->nb_tx_queues; i++) {
-   ixgbe_dev_tx_queue_release(eth_dev->data->tx_queues[i]);
-   eth_dev->data->tx_queues[i] = NULL;
-   }
-   eth_dev->data->nb_tx_queues = 0;
-
rte_free(eth_dev->data->mac_addrs);
eth_dev->data->mac_addrs = NULL;

-- 
2.6.3



[dpdk-dev] [PATCH 0/3 v2] ixgbe fixes

2016-02-26 Thread Bernard Iremonger
This patch set implements the following:
Removes code which was duplicated in eth_ixgbevf_dev_init().
Adds more information to the error message in ixgbe_check_mq_mode().
Allows the MAC address of the VF to be set to zero.

Changes in v2:
Do not overwrite the VF perm_add with zero.

Bernard Iremonger (3):
  ixgbe: cleanup eth_ixgbevf_dev_uninit
  ixgbe: add more information to the error message
  ixgbe: fix setting of VF MAC address

 drivers/net/ixgbe/ixgbe_ethdev.c | 29 +
 drivers/net/ixgbe/ixgbe_pf.c |  7 ---
 2 files changed, 17 insertions(+), 19 deletions(-)

-- 
2.6.3



[dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding

2016-02-26 Thread Bruce Richardson
On Fri, Feb 26, 2016 at 09:24:06AM +, Wang, Xiao W wrote:
> Hi,
> 
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Friday, February 26, 2016 5:06 PM
> > To: Wang, Xiao W 
> > Cc: Richardson, Bruce ; Chen, Jing D
> > ; dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
> > 
> > 2016-02-26 04:31, Wang, Xiao W:
> > > From: Richardson, Bruce
> > > > On Thu, Feb 25, 2016 at 03:45:45PM +, Chen, Jing D wrote:
> > > > > From: Richardson, Bruce
> > > > > > On Thu, Feb 25, 2016 at 10:04:02AM +, Chen, Jing D wrote:
> > > > > > > This feature is trying to use FTAG (a unique tech in fm10k)
> > > > > > > instead of mac/vlan to forward packets. App need a way to tell
> > > > > > > PMD driver that which forwarding style it would like to use.
> > > > > >
> > > > > > Why not just specify this in the port configuration at setup time?
> > > > > >
> > > > >
> > > > > Please educate me. I think the port configuration flags are also
> > > > > common to all PMD Drivers. Is it possible to add a flag like
> > "RTE_USE_FTAG"
> > > > and pass to PMD driver?
> > > > >
> > > > They are.
> > > > For something PMD specific, like FTAG, it's always a challenge, and
> > > > I don't know off the top of my head if there is a simple option.
> > > > However, given the choice between an mbuf flag and a port config
> > > > flag, I'd always choose the former.
> > > > Other alternatives would be to have a fm10k specific API in the
> > > > fm10k driver alone.
> > > >
> > > > I'll let Thomas as ethdev maintainer comment if he has other
> > > > suggestions as to how to handle this case. I suspect this won't be
> > > > the first device-specific piece of functionality we need to deal with.
> > > >
> > > > /Bruce
> > >
> > > Whatever method we choose, we have to find a way for the user to
> > > express his need for FTAG, it maybe a build time config option, or a
> > > port config flag (no such flag now), or a fast path flag in mbuf (no
> > > such flag now) etc. For the customer Topsec's use case, they use FTAG
> > > for all the TX packets, so all the above methods (per build config,
> > > per port config, per mbuf config) can meet their need. Since the pmd
> > > frame work is for common, it's hard to add new fields only for one 
> > > specific
> > NIC, so I add a build time config and make an introduction in the doc.
> > >
> > > Thanks for the discussion, Thomas, do you have any suggestions?
> > 
> > I don't understand why you say this feature is specific to fm10k. Can we
> > imagine another NIC having this capability?
> 
> As you know, fm10k has a switch logic between the Mac and Phy, every packets
> Sent out from the host will be switched inside the NIC, other NICs don't have
> a switch inside, and the FTAG feature is related to the switch function.
> 
> As introduced in the second patch:
> The FM10K family of NICs support the addition of a Fabric Tag (FTAG) to carry
> special information. The FTAG is placed at the beginning of the frame, it 
> contains
> information such as where the packet comes from and goes, and the vlan tag. In
> FTAG based forwarding mode, the switch logic forwards packets according to
> glort (global resource tag) information, rather than the mac and vlan table.
> So this is a feature specific to fm10k.
> 
> Best Regards,
> Xiao

If it is fm10k specific, how about just adding a public function to the fm10k
driver to turn it on. The user app will be non-portable across NICs, but
that's the price of using nic-specific features.

/Bruce

> > I think it must be an port configuration, as Bruce suggested.
> > What about a field in struct rte_eth_conf?


[dpdk-dev] [PATCH v2] doc: Malicious Driver Detection not supported by ixgbe

2016-02-26 Thread Bruce Richardson
On Fri, Feb 26, 2016 at 12:48:37PM +0800, Wenzhuo Lu wrote:
> Announce that Malicious Driver Detection is not supported.
> 
> V2:
>  *Rework the words.
> 
> Signed-off-by: Wenzhuo Lu 

Hi Wenzhuo,

just for future reference, please put the V2,v3 etc. updates below the cut line
"---" so that they can be auto-stripped when applying the patch.

/Bruce

> ---
>  doc/guides/nics/ixgbe.rst  | 20 
>  doc/guides/rel_notes/release_16_04.rst | 23 +++
>  2 files changed, 43 insertions(+)
> 



[dpdk-dev] [PATCH v2] ixgbe: Fix disable interrupt twice

2016-02-26 Thread Bruce Richardson
On Tue, Feb 23, 2016 at 02:10:57AM +, Zhang, Helin wrote:
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Qiu
> > Sent: Friday, January 29, 2016 1:58 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH v2] ixgbe: Fix disable interrupt twice
> > 
> > Currently, ixgbe vf and pf will disable interrupt twice in stop stage and 
> > uninit
> > stage. It will cause an error:
> > 
> > testpmd> quit
> > 
> > Shutting down port 0...
> > Stopping ports...
> > Done
> > Closing ports...
> > EAL: Error disabling MSI-X interrupts for fd 26
> > Done
> > 
> > Becasue the interrupt already been disabled in stop stage.
> > Since it is enabled in init stage, better remove from stop stage.
> > 
> > Fixes: 0eb609239efd ("ixgbe: enable Rx queue interrupts for PF and VF")
> > 
> > Signed-off-by: Michael Qiu 
> Acked-by: Helin Zhang 
> 
applied to dpdk-next-net/rel_16_04

/Bruce


[dpdk-dev] virtio PMD is not working with master version

2016-02-26 Thread Santosh Shukla
On Fri, Feb 26, 2016 at 2:14 PM, Xie, Huawei  wrote:
> On 2/26/2016 4:29 PM, David Marchand wrote:
>> On Fri, Feb 26, 2016 at 3:23 AM, Yuanhan Liu
>>  wrote:
>>> Mauricio, thanks for the testing and report.
>>>
>>> On Thu, Feb 25, 2016 at 02:30:18PM +0100, David Marchand wrote:
 >From the logs, I would say I broke uio_pci_generic since we are in
 "uio" case, but uio portio sysfs does not exist.
 virtio pmd fell back to ioports discovery before my change.
>>> Maybe we can do same?
> We shouldn't, :). I am now rebasing the patch to fix the issue that
> virtio driver takes the virtio device blindly.
> With the patch:
>  if driver is VFIO/UIO, and errors happens, returns without falling back
> to IO port.

Nice, This will be useful for non-x86 arch case, IO port is NA for
non-x86 arch so falling back to IO port would always fail. so
defaulting to IO port case is incorrect. IMO, not arch agnostic.

>  if no any kernel driver is managing the device, try IO port; otherwise
> returns 1 to tell the layer we don't take over this device.
>


>> I suppose, but see below.
>>
>>> ---
>>> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
>>> b/lib/librte_eal/linuxapp/eal/eal_pci.c
>>> index 4346973..579731c 100644
>>> --- a/lib/librte_eal/linuxapp/eal/eal_pci.c
>>> +++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
>>> @@ -685,12 +685,11 @@ int
>>>  rte_eal_pci_ioport_map(struct rte_pci_device *dev, int bar,
>>>struct rte_pci_ioport *p)
>>>  {
>>> -   int ret;
>>> +   int ret = -1;
>>>
>>> switch (dev->kdrv) {
>>>  #ifdef VFIO_PRESENT
>>> case RTE_KDRV_VFIO:
>>> -   ret = -1;
>>> if (pci_vfio_is_enabled())
>>> ret = pci_vfio_ioport_map(dev, bar, p);
>>> break;
>>> @@ -700,14 +699,14 @@ rte_eal_pci_ioport_map(struct rte_pci_device *dev, 
>>> int bar,
>>> ret = pci_uio_ioport_map(dev, bar, p);
>>> break;
>>> default:
>>> +   break;
>>> +   }
>>> +
>>>  #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
>>> -   /* special case for x86 ... */
>>> +   /* special case for x86 ... */
>>> +   if (ret)
>>> ret = pci_ioport_map(dev, bar, p);
>>> -#else
>>> -   ret = -1;
>>>  #endif
>>> -   break;
>>> -   }
>> What if we are supposed to do vfio here, but for some reason init failed ?
>> Next thing, we will call ioport_read in vfio context, but init went
>> through the ioports parsing => boom ?
>>
>> Another issue is that when device is bound to a kernel driver (let's
>> say virtio-pci here), then init will succeed and pmd will kick in the
>> device registers.
>>
>> This special case should really be narrowed down to "uio" and "none"
>> driver cases.
>>
>>
>


[dpdk-dev] Virtio xstats problem

2016-02-26 Thread Van Haaren, Harry
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Igor Ryzhov
> I found some problem with virtio xstats counters.
> 
> Example:
> 
> rx_good_packets: 3
> rx_good_bytes: 180
> rx_errors: 0
> 
> rx_q0_good_packets: 3
> rx_q0_good_bytes: 180
> rx_q0_errors: 0
> 
> rx_q0_multicast_packets: 3
> rx_q0_broadcast_packets: 1
> rx_q0_undersize_packets: 3

> It means that undersize packets are counted as good packets instead of errors.

Are you sending 64 byte packets? There are no 4 bytes of CRC on virtual
interfaces, so 60 bytes per packet is OK.

> Or maybe
> size of packet is calculated wrong.
> I don't have time now to check it more deeply - I can do it sometime later, 
> but maybe
> someone want to help.

Are the packets multicast or broadcast?
It looks like one of the counters there is wrong.

> PS. Is it a common practice to count broadcast packets twice - in broadcast 
> and multicast
> counters?

No packet should be counted twice - it must be put into one bucket of mutli, 
broad or unicast.

-Harry


[dpdk-dev] [PATCH v4 12/12] examples/l3fwd: add option to parse ptype

2016-02-26 Thread Ananyev, Konstantin
> > Actually it is a good point:
> > for EM case should l3fwd process only TCP/UDP packets?
> > If yes, then it needs to check not only L3, but also L4 type too
> > Which means that for EM and LPM check_packet_type_ok() should also be 
> > different.
> > Or we can leave it as it is - in that case EM even for non UDP/TCP packet 
> > would still
> > do route  lookup using first 4B of L3 payload.
> 
> I'd like to follow the first approach, (if nobody strongly objects to
> it), because it's EM's real intention to use 5 tuples.

Ok with me.
Konstantin




[dpdk-dev] [PATCH v1] virtio: Use cpuflag for vector api

2016-02-26 Thread Santosh Shukla
Check cpuflag macro before using vectored api.
-virtio_recv_pkts_vec() uses _sse3__ simd instruction for now so added cpuflag.
- Also wrap other vectored freind api ie..
1) virtqueue_enqueue_recv_refill_simple
2) virtio_rxq_vec_setup

todo:
1) Move virtio_recv_pkts_vec() implementation to
   drivers/virtio/virtio_vec_.h file.
2) Remove use_simple_rxtx flag, so that virtio/virtio_vec_.h
   files to provide vectored/non-vectored rx/tx apis.

Signed-off-by: Santosh Shukla 
---
- v1: This is a rework of patch [1].
Note: This patch will let non-x86 arch to use virtio pmd.

[1] http://dpdk.org/dev/patchwork/patch/10429/

 drivers/net/virtio/virtio_rxtx.c|   16 +++-
 drivers/net/virtio/virtio_rxtx.h|2 ++
 drivers/net/virtio/virtio_rxtx_simple.c |   11 ++-
 3 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 41a1366..ec0b8de 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -67,7 +67,9 @@
 #define VIRTIO_SIMPLE_FLAGS ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
ETH_TXQ_FLAGS_NOOFFLOADS)

+#ifdef RTE_MACHINE_CPUFLAG_SSSE3
 static int use_simple_rxtx;
+#endif

 static void
 vq_ring_free_chain(struct virtqueue *vq, uint16_t desc_idx)
@@ -307,12 +309,13 @@ virtio_dev_vring_start(struct virtqueue *vq, int 
queue_type)
nbufs = 0;
error = ENOSPC;

+#ifdef RTE_MACHINE_CPUFLAG_SSSE3
if (use_simple_rxtx)
for (i = 0; i < vq->vq_nentries; i++) {
vq->vq_ring.avail->ring[i] = i;
vq->vq_ring.desc[i].flags = VRING_DESC_F_WRITE;
}
-
+#endif
memset(>fake_mbuf, 0, sizeof(vq->fake_mbuf));
for (i = 0; i < RTE_PMD_VIRTIO_RX_MAX_BURST; i++)
vq->sw_ring[vq->vq_nentries + i] = >fake_mbuf;
@@ -325,9 +328,11 @@ virtio_dev_vring_start(struct virtqueue *vq, int 
queue_type)
/**
* Enqueue allocated buffers*
***/
+#ifdef RTE_MACHINE_CPUFLAG_SSSE3
if (use_simple_rxtx)
error = 
virtqueue_enqueue_recv_refill_simple(vq, m);
else
+#endif
error = virtqueue_enqueue_recv_refill(vq, m);
if (error) {
rte_pktmbuf_free(m);
@@ -340,6 +345,7 @@ virtio_dev_vring_start(struct virtqueue *vq, int queue_type)

PMD_INIT_LOG(DEBUG, "Allocated %d bufs", nbufs);
} else if (queue_type == VTNET_TQ) {
+#ifdef RTE_MACHINE_CPUFLAG_SSSE3
if (use_simple_rxtx) {
int mid_idx  = vq->vq_nentries >> 1;
for (i = 0; i < mid_idx; i++) {
@@ -357,6 +363,7 @@ virtio_dev_vring_start(struct virtqueue *vq, int queue_type)
for (i = mid_idx; i < vq->vq_nentries; i++)
vq->vq_ring.avail->ring[i] = i;
}
+#endif
}
 }

@@ -423,7 +430,9 @@ virtio_dev_rx_queue_setup(struct rte_eth_dev *dev,

dev->data->rx_queues[queue_idx] = vq;

+#ifdef RTE_MACHINE_CPUFLAG_SSSE3
virtio_rxq_vec_setup(vq);
+#endif

return 0;
 }
@@ -449,7 +458,10 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
const struct rte_eth_txconf *tx_conf)
 {
uint8_t vtpci_queue_idx = 2 * queue_idx + VTNET_SQ_TQ_QUEUE_IDX;
+
+#ifdef RTE_MACHINE_CPUFLAG_SSSE3
struct virtio_hw *hw = dev->data->dev_private;
+#endif
struct virtqueue *vq;
uint16_t tx_free_thresh;
int ret;
@@ -462,6 +474,7 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
return -EINVAL;
}

+#ifdef RTE_MACHINE_CPUFLAG_SSSE3
/* Use simple rx/tx func if single segment and no offloads */
if ((tx_conf->txq_flags & VIRTIO_SIMPLE_FLAGS) == VIRTIO_SIMPLE_FLAGS &&
 !vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF)) {
@@ -470,6 +483,7 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
dev->rx_pkt_burst = virtio_recv_pkts_vec;
use_simple_rxtx = 1;
}
+#endif

ret = virtio_dev_queue_setup(dev, VTNET_TQ, queue_idx, vtpci_queue_idx,
nb_desc, socket_id, );
diff --git a/drivers/net/virtio/virtio_rxtx.h b/drivers/net/virtio/virtio_rxtx.h
index 831e492..a76c3e5 100644
--- a/drivers/net/virtio/virtio_rxtx.h
+++ b/drivers/net/virtio/virtio_rxtx.h
@@ -33,7 +33,9 @@

 #define RTE_PMD_VIRTIO_RX_MAX_BURST 64

+#ifdef RTE_MACHINE_CPUFLAG_SSSE3
 int virtio_rxq_vec_setup(struct virtqueue *rxq);

 int virtqueue_enqueue_recv_refill_simple(struct virtqueue *vq,
struct rte_mbuf *m);
+#endif
diff --git 

[dpdk-dev] [PATCH v3 4/4] examples/ethtool: add control interface support to the application

2016-02-26 Thread Ferruh Yigit
Control interface APIs added into the sample application.

To have the support corresponding kernel module (KCP) needs to be inserted.
If kernel module is not there, application will run as it is without
kernel control path support.

When KCP module inserted, running application creates a virtual Linux
network interface (dpdk$) per DPDK port. This interface can be used by
traditional Linux tools.

Signed-off-by: Ferruh Yigit 
---

v3:
* Use blocking mode control interface processing, instead of poll mode

v2:
* No update on sample app
---
 doc/guides/sample_app_ug/ethtool.rst | 41 
 examples/ethtool/main.c  | 31 +--
 2 files changed, 70 insertions(+), 2 deletions(-)

diff --git a/doc/guides/sample_app_ug/ethtool.rst 
b/doc/guides/sample_app_ug/ethtool.rst
index 65240ae..af591c2 100644
--- a/doc/guides/sample_app_ug/ethtool.rst
+++ b/doc/guides/sample_app_ug/ethtool.rst
@@ -130,3 +130,44 @@ interface that accepts commands as described in `using the
 application`_. Individual call-back functions handle the detail
 associated with each command, which make use of librte_ethtool
 library.
+
+Control Interface
+~
+
+If Kernel Control Path (KCP) kernel module (rte_kcp.ko) inserted,
+virtual interfaces created for each DPDK port for control purposes.
+
+Created interfaces are named as dpdk#, like:
+
+.. code-block:: console
+
+# ifconfig dpdk0; ifconfig dpdk1
+dpdk0: flags=4099  mtu 1500
+ether 90:e2:ba:0e:49:b9  txqueuelen 1000  (Ethernet)
+RX packets 0  bytes 0 (0.0 B)
+RX errors 0  dropped 0  overruns 0  frame 0
+TX packets 0  bytes 0 (0.0 B)
+TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
+
+dpdk1: flags=4099  mtu 1500
+ether 00:1b:21:76:fa:21  txqueuelen 1000  (Ethernet)
+RX packets 0  bytes 0 (0.0 B)
+RX errors 0  dropped 0  overruns 0  frame 0
+TX packets 0  bytes 0 (0.0 B)
+TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
+
+Regular Linux commands can be issued on interfaces:
+
+.. code-block:: console
+
+# ethtool -i dpdk0
+driver: rte_ixgbe_pmd
+version: RTE 2.3.0-rc0
+firmware-version:
+expansion-rom-version:
+bus-info: :08:00.1
+supports-statistics: yes
+supports-test: no
+supports-eeprom-access: yes
+supports-register-dump: yes
+supports-priv-flags: no
diff --git a/examples/ethtool/main.c b/examples/ethtool/main.c
index 2c655d8..72fbe4c 100644
--- a/examples/ethtool/main.c
+++ b/examples/ethtool/main.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2015-2016 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "ethapp.h"

@@ -54,7 +55,6 @@
 #define PKTPOOL_EXTRA_SIZE 512
 #define PKTPOOL_CACHE 32

-
 struct txq_port {
uint16_t cnt_unsent;
struct rte_mbuf *buf_frames[MAX_BURST_LENGTH];
@@ -259,11 +259,32 @@ static int slave_main(__attribute__((unused)) void 
*ptr_data)
return 0;
 }

+static void *
+control_function(__attribute__((unused)) void *arg)
+{
+   int port_id;
+
+   while (1) {
+   /* blocking call with 1 sec timeout */
+   port_id = rte_eth_control_interface_msg_exist(1);
+   if (port_id < 0)
+   continue;
+
+   lock_port(port_id);
+   rte_eth_control_interface_msg_process(
+   RTE_ETHTOOL_CTRL_IF_PROCESS_MSG);
+   unlock_port(port_id);
+   }
+
+   return 0;
+}
+
 int main(int argc, char **argv)
 {
int cnt_args_parsed;
uint32_t id_core;
uint32_t cnt_ports;
+   pthread_t control_thread;

/* Init runtime enviornment */
cnt_args_parsed = rte_eal_init(argc, argv);
@@ -293,6 +314,9 @@ int main(int argc, char **argv)
id_core = rte_get_next_lcore(id_core, 1, 1);
rte_eal_remote_launch(slave_main, NULL, id_core);

+   pthread_create(_thread, NULL, control_function, NULL);
+   rte_eth_control_interface_create();
+
ethapp_main();

app_cfg.exit_now = 1;
@@ -301,5 +325,8 @@ int main(int argc, char **argv)
return -1;
}

+   rte_eth_control_interface_destroy();
+   pthread_cancel(control_thread);
+
return 0;
 }
-- 
2.5.0



[dpdk-dev] [PATCH v3 3/4] rte_ctrl_if: add control interface library

2016-02-26 Thread Ferruh Yigit
This library gets control messages form kernelspace and forwards them to
librte_ether and returns response back to the kernelspace.

Library does:
1) Trigger Linux virtual interface creation
2) Initialize the netlink socket communication
3) Provides process() API to the application that does processing the
received messages

This library requires corresponding kernel module to be inserted.

Signed-off-by: Ferruh Yigit 
---

v3:
* Use librte_ethtool
* Don't create interfaces for virtual PMDs
* Add a new API ...msg_exist() to support port based locking
* Add enable/disable promisc, allmulti support

v2:
* User rtnetlink to create interfaces.
* Add more ethtool support: get/set ringparam, set pauseparam.
* return defined error instead of hardcoded value
---
 MAINTAINERS|   1 +
 config/common_linuxapp |   3 +-
 doc/api/doxy-api-index.md  |   1 +
 doc/api/doxy-api.conf  |   1 +
 doc/guides/prog_guide/ctrl_if_lib.rst  |  52 
 doc/guides/prog_guide/index.rst|   1 +
 doc/guides/rel_notes/release_16_04.rst |   9 +
 lib/Makefile   |   3 +-
 lib/librte_ctrl_if/Makefile|  58 +
 lib/librte_ctrl_if/rte_ctrl_ethtool.c  | 376 +++
 lib/librte_ctrl_if/rte_ctrl_ethtool.h  |  54 
 lib/librte_ctrl_if/rte_ctrl_if.c   | 395 +
 lib/librte_ctrl_if/rte_ctrl_if.h   | 129 ++
 lib/librte_ctrl_if/rte_ctrl_if_version.map |  10 +
 lib/librte_ctrl_if/rte_nl.c| 313 +++
 lib/librte_ctrl_if/rte_nl.h|  50 
 lib/librte_eal/common/include/rte_log.h|   3 +-
 mk/rte.app.mk  |   3 +-
 18 files changed, 1458 insertions(+), 4 deletions(-)
 create mode 100644 doc/guides/prog_guide/ctrl_if_lib.rst
 create mode 100644 lib/librte_ctrl_if/Makefile
 create mode 100644 lib/librte_ctrl_if/rte_ctrl_ethtool.c
 create mode 100644 lib/librte_ctrl_if/rte_ctrl_ethtool.h
 create mode 100644 lib/librte_ctrl_if/rte_ctrl_if.c
 create mode 100644 lib/librte_ctrl_if/rte_ctrl_if.h
 create mode 100644 lib/librte_ctrl_if/rte_ctrl_if_version.map
 create mode 100644 lib/librte_ctrl_if/rte_nl.c
 create mode 100644 lib/librte_ctrl_if/rte_nl.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 6a77728..24dbfa0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -260,6 +260,7 @@ F: doc/guides/sample_app_ug/kernel_nic_interface.rst
 Linux KCP
 M: Ferruh Yigit 
 F: lib/librte_eal/linuxapp/kcp/
+F: lib/librte_ctrl_if/

 Linux AF_PACKET
 M: John W. Linville 
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 0284fae..dc75653 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -1,6 +1,6 @@
 #   BSD LICENSE
 #
-#   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+#   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
 #   All rights reserved.
 #
 #   Redistribution and use in source and binary forms, with or without
@@ -506,6 +506,7 @@ CONFIG_RTE_LIBRTE_ETHTOOL=y
 #
 CONFIG_RTE_KCP_KMOD=y
 CONFIG_RTE_KCP_KO_DEBUG=n
+CONFIG_RTE_LIBRTE_CTRL_IF=y

 #
 # Compile vhost library
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 4cdd3f5..e34250d 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -151,3 +151,4 @@ There are many libraries, so their headers may be grouped 
by topics:
   [keepalive]  (@ref rte_keepalive.h),
   [version](@ref rte_version.h),
   [ethtool](@ref rte_ethtool.h),
+  [control interface]  (@ref rte_ctrl_if.h)
diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
index c5b8615..1a7999e 100644
--- a/doc/api/doxy-api.conf
+++ b/doc/api/doxy-api.conf
@@ -39,6 +39,7 @@ INPUT   = doc/api/doxy-api-index.md \
   lib/librte_cmdline \
   lib/librte_compat \
   lib/librte_cryptodev \
+  lib/librte_ctrl_if \
   lib/librte_distributor \
   lib/librte_ether \
   lib/librte_ethtool \
diff --git a/doc/guides/prog_guide/ctrl_if_lib.rst 
b/doc/guides/prog_guide/ctrl_if_lib.rst
new file mode 100644
index 000..36054b9
--- /dev/null
+++ b/doc/guides/prog_guide/ctrl_if_lib.rst
@@ -0,0 +1,52 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the 

[dpdk-dev] [PATCH v3 2/4] kcp: add kernel control path kernel module

2016-02-26 Thread Ferruh Yigit
This kernel module is based on KNI module, but this one is stripped
version of it and only for control messages, no data transfer
functionality provided.

This Linux kernel module helps userspace application create virtual
interfaces and when a control command issued into that virtual
interface, module pushes the command to the userspace and gets the
response back for the caller application.

The Linux tools like ethtool/ifconfig/ip can be used on virtual
interfaces but not ones for related data, like tcpdump.

In long term this patch intends to replace the KNI and KNI will be
depreciated.

Signed-off-by: Ferruh Yigit 
---

v3:
* Devices are not up by default
* Add enable/disable promisc, allmulti support
* Increase timeout to 500ms and print log when a command timedout

v2:
* Use rtnetlink to create interfaces
* Fix ethtool get/set eeprom
* Remove commented out code
---
 MAINTAINERS|   4 +
 config/common_linuxapp |   6 +
 lib/librte_eal/linuxapp/Makefile   |   5 +-
 lib/librte_eal/linuxapp/eal/Makefile   |   3 +-
 .../linuxapp/eal/include/exec-env/rte_kcp_common.h | 109 
 lib/librte_eal/linuxapp/kcp/Makefile   |  57 
 lib/librte_eal/linuxapp/kcp/kcp_dev.h  |  54 
 lib/librte_eal/linuxapp/kcp/kcp_ethtool.c  | 300 +
 lib/librte_eal/linuxapp/kcp/kcp_net.c  | 225 
 lib/librte_eal/linuxapp/kcp/kcp_nl.c   | 215 +++
 10 files changed, 976 insertions(+), 2 deletions(-)
 create mode 100644 
lib/librte_eal/linuxapp/eal/include/exec-env/rte_kcp_common.h
 create mode 100644 lib/librte_eal/linuxapp/kcp/Makefile
 create mode 100644 lib/librte_eal/linuxapp/kcp/kcp_dev.h
 create mode 100644 lib/librte_eal/linuxapp/kcp/kcp_ethtool.c
 create mode 100644 lib/librte_eal/linuxapp/kcp/kcp_net.c
 create mode 100644 lib/librte_eal/linuxapp/kcp/kcp_nl.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 628bc05..6a77728 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -257,6 +257,10 @@ F: app/test/test_kni.c
 F: examples/kni/
 F: doc/guides/sample_app_ug/kernel_nic_interface.rst

+Linux KCP
+M: Ferruh Yigit 
+F: lib/librte_eal/linuxapp/kcp/
+
 Linux AF_PACKET
 M: John W. Linville 
 F: drivers/net/af_packet/
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 960dde4..0284fae 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -502,6 +502,12 @@ CONFIG_RTE_KNI_VHOST_DEBUG_TX=n
 CONFIG_RTE_LIBRTE_ETHTOOL=y

 #
+# Compile librte_ctrl_if
+#
+CONFIG_RTE_KCP_KMOD=y
+CONFIG_RTE_KCP_KO_DEBUG=n
+
+#
 # Compile vhost library
 # fuse-devel is needed to run vhost-cuse.
 # fuse-devel enables user space char driver development
diff --git a/lib/librte_eal/linuxapp/Makefile b/lib/librte_eal/linuxapp/Makefile
index d9c5233..d1fa3a3 100644
--- a/lib/librte_eal/linuxapp/Makefile
+++ b/lib/librte_eal/linuxapp/Makefile
@@ -1,6 +1,6 @@
 #   BSD LICENSE
 #
-#   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+#   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
 #   All rights reserved.
 #
 #   Redistribution and use in source and binary forms, with or without
@@ -38,6 +38,9 @@ DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal
 ifeq ($(CONFIG_RTE_KNI_KMOD),y)
 DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += kni
 endif
+ifeq ($(CONFIG_RTE_KCP_KMOD),y)
+DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += kcp
+endif
 ifeq ($(CONFIG_RTE_LIBRTE_XEN_DOM0),y)
 DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += xen_dom0
 endif
diff --git a/lib/librte_eal/linuxapp/eal/Makefile 
b/lib/librte_eal/linuxapp/eal/Makefile
index 6e26250..f6a3a41 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -1,6 +1,6 @@
 #   BSD LICENSE
 #
-#   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+#   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
 #   All rights reserved.
 #
 #   Redistribution and use in source and binary forms, with or without
@@ -121,6 +121,7 @@ CFLAGS_eal_thread.o += -Wno-return-type
 endif

 INC := rte_interrupts.h rte_kni_common.h rte_dom0_common.h
+INC += rte_kcp_common.h

 SYMLINK-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP)-include/exec-env := \
$(addprefix include/exec-env/,$(INC))
diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kcp_common.h 
b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kcp_common.h
new file mode 100644
index 000..988713e
--- /dev/null
+++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kcp_common.h
@@ -0,0 +1,109 @@
+/*-
+ *   This file is provided under a dual BSD/LGPLv2 license.  When using or
+ *   redistributing this file, you may do so under either license.
+ *
+ *   GNU LESSER GENERAL PUBLIC LICENSE
+ *
+ *   Copyright(c) 2016 Intel Corporation. All rights reserved.
+ *
+ *   This program is free software; you can redistribute it and/or modify
+ *   it under the terms of version 2.1 of the GNU Lesser 

[dpdk-dev] [PATCH v3 1/4] lib/librte_ethtool: move librte_ethtool form examples to lib folder

2016-02-26 Thread Ferruh Yigit
With KCP, examples/ethtool/lib/ethtool has two users, to prevent code
dublication, moving library from examples folder into lib/ folder.

Signed-off-by: Ferruh Yigit 
---
 config/common_linuxapp |   5 +
 doc/api/doxy-api-index.md  |   3 +-
 doc/api/doxy-api.conf  |   1 +
 doc/api/examples.dox   |   5 +-
 doc/guides/prog_guide/ethtool_lib.rst  |  62 ++
 doc/guides/prog_guide/index.rst|   3 +-
 doc/guides/rel_notes/release_16_04.rst |   1 +
 doc/guides/sample_app_ug/ethtool.rst   |  36 +-
 examples/ethtool/Makefile  |  24 +-
 examples/ethtool/ethapp.c  | 873 +
 examples/ethtool/ethapp.h  |  41 ++
 examples/ethtool/ethtool-app/Makefile  |  54 --
 examples/ethtool/ethtool-app/ethapp.c  | 873 -
 examples/ethtool/ethtool-app/ethapp.h  |  41 --
 examples/ethtool/ethtool-app/main.c| 305 --
 examples/ethtool/lib/Makefile  |  57 --
 examples/ethtool/lib/rte_ethtool.c | 423 --
 examples/ethtool/lib/rte_ethtool.h | 410 --
 examples/ethtool/main.c| 305 ++
 lib/Makefile   |   1 +
 lib/librte_ethtool/Makefile|  57 ++
 lib/librte_ethtool/rte_ethtool.c   | 423 ++
 lib/librte_ethtool/rte_ethtool.h   | 413 ++
 lib/librte_ethtool/rte_ethtool_version.map |  28 +
 mk/rte.app.mk  |   1 +
 25 files changed, 2236 insertions(+), 2209 deletions(-)
 create mode 100644 doc/guides/prog_guide/ethtool_lib.rst
 create mode 100644 examples/ethtool/ethapp.c
 create mode 100644 examples/ethtool/ethapp.h
 delete mode 100644 examples/ethtool/ethtool-app/Makefile
 delete mode 100644 examples/ethtool/ethtool-app/ethapp.c
 delete mode 100644 examples/ethtool/ethtool-app/ethapp.h
 delete mode 100644 examples/ethtool/ethtool-app/main.c
 delete mode 100644 examples/ethtool/lib/Makefile
 delete mode 100644 examples/ethtool/lib/rte_ethtool.c
 delete mode 100644 examples/ethtool/lib/rte_ethtool.h
 create mode 100644 examples/ethtool/main.c
 create mode 100644 lib/librte_ethtool/Makefile
 create mode 100644 lib/librte_ethtool/rte_ethtool.c
 create mode 100644 lib/librte_ethtool/rte_ethtool.h
 create mode 100644 lib/librte_ethtool/rte_ethtool_version.map

diff --git a/config/common_linuxapp b/config/common_linuxapp
index f1638db..960dde4 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -497,6 +497,11 @@ CONFIG_RTE_KNI_VHOST_DEBUG_RX=n
 CONFIG_RTE_KNI_VHOST_DEBUG_TX=n

 #
+# Compile librte_ethtool
+#
+CONFIG_RTE_LIBRTE_ETHTOOL=y
+
+#
 # Compile vhost library
 # fuse-devel is needed to run vhost-cuse.
 # fuse-devel enables user space char driver development
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 7a91001..4cdd3f5 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -149,4 +149,5 @@ There are many libraries, so their headers may be grouped 
by topics:
   [common] (@ref rte_common.h),
   [ABI compat] (@ref rte_compat.h),
   [keepalive]  (@ref rte_keepalive.h),
-  [version](@ref rte_version.h)
+  [version](@ref rte_version.h),
+  [ethtool](@ref rte_ethtool.h),
diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
index 57e8b5d..c5b8615 100644
--- a/doc/api/doxy-api.conf
+++ b/doc/api/doxy-api.conf
@@ -41,6 +41,7 @@ INPUT   = doc/api/doxy-api-index.md \
   lib/librte_cryptodev \
   lib/librte_distributor \
   lib/librte_ether \
+  lib/librte_ethtool \
   lib/librte_hash \
   lib/librte_ip_frag \
   lib/librte_ivshmem \
diff --git a/doc/api/examples.dox b/doc/api/examples.dox
index 200af0b..8763d77 100644
--- a/doc/api/examples.dox
+++ b/doc/api/examples.dox
@@ -8,9 +8,8 @@
 @example distributor/main.c
 @example dpdk_qat/crypto.c
 @example dpdk_qat/main.c
- at example ethtool/ethtool-app/ethapp.c
- at example ethtool/ethtool-app/main.c
- at example ethtool/lib/rte_ethtool.c
+ at example ethtool/ethapp.c
+ at example ethtool/main.c
 @example exception_path/main.c
 @example helloworld/main.c
 @example ip_fragmentation/main.c
diff --git a/doc/guides/prog_guide/ethtool_lib.rst 
b/doc/guides/prog_guide/ethtool_lib.rst
new file mode 100644
index 000..e161cd0
--- /dev/null
+++ b/doc/guides/prog_guide/ethtool_lib.rst
@@ -0,0 +1,62 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source 

[dpdk-dev] [PATCH v3 0/4] Use common Linux tools to control DPDK ports

2016-02-26 Thread Ferruh Yigit
This work is to make DPDK ports more visible and to enable using common
Linux tools to configure DPDK ports.

Patch is based on KNI but contains only control functionality of it,
also this patch does not include any Linux kernel network driver as
part of it.

Basically with the help of a kernel module (KCP), virtual Linux network
interfaces named as "dpdk$" are created per DPDK port, control messages
sent to these virtual interfaces are forwarded to DPDK, and response
sent back to Linux application.

Virtual interfaces created when DPDK application started and destroyed
automatically when DPDK application terminated.

Communication between kernel-space and DPDK done using netlink socket.

Currently implementation is not complete, sample support added for the
RFC, more functionality can be added based on community response.

With this RFC Patch, supported: get/set mac address/mtu of DPDK devices,
getting stats from DPDK devices and some set of ethtool commands.

In long term this patch intends to replace the KNI and KNI will be
depreciated.

v3:
* Kernel side changes:
  * Devices are not up by default
  * Add enable/disable promisc, allmulti support
  * Increase timeout to 500ms and print log when a command timedout
* Control library changes:
  * Use librte_ethtool
  * Don't create interfaces for virtual PMDs
  * Add a new API ...msg_exist() to support port based locking
  * Add enable/disable promisc, allmulti support
* Example changes:
  * Use blocking mode control interface processing, instead of poll mode

v2:
* Use rtnetlink to create interfaces
* Add more ethtool support: get/set ringparam, set pauseparam.
* fix ethtool get/set eeprom
* lots of minor updates, enhancements in the code


Samples:

$ ifconfig
dpdk0: flags=4099  mtu 1500
ether 90:e2:ba:0e:49:b8  txqueuelen 1000  (Ethernet)
RX packets 33  bytes 2058 (2.0 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 33  bytes 2058 (2.0 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

dpdk1: flags=4099  mtu 1500
ether 00:1b:21:76:fa:21  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

After some traffic on port 0:

$ ifconfig
dpdk0: flags=4099  mtu 1500
ether 90:e2:ba:0e:49:77  txqueuelen 1000  (Ethernet)
RX packets 962  bytes 57798 (56.4 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 962  bytes 57798 (56.4 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


$ ethtool -i dpdk0
driver: rte_ixgbe_pmd
version: DPDK 16.04.0-rc0
firmware-version: 
expansion-rom-version: 
bus-info: :08:00.0
supports-statistics: no
supports-test: no
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no


$ ethtool -e dpdk0 offset 20 length 10
Offset  Values
--  --
0x0014: b7 01 bf 01 c7 01 cf 01 09 02 


$ ip l show dpdk0
25: dpdk0:  mtu 1500 qdisc noop state DOWN 
mode DEFAULT group default qlen 1000
link/ether 90:e2:ba:0e:49:b8 brd ff:ff:ff:ff:ff:ff

$ ip l set dpdk0 addr 90:e2:ba:0e:49:77

$ ip l show dpdk0
25: dpdk0:  mtu 1500 qdisc noop state DOWN 
mode DEFAULT group default qlen 1000
link/ether 90:e2:ba:0e:49:77 brd ff:ff:ff:ff:ff:ff

Ferruh Yigit (4):
  lib/librte_ethtool: move librte_ethtool form examples to lib folder
  kcp: add kernel control path kernel module
  rte_ctrl_if: add control interface library
  examples/ethtool: add control interface support to the application

 MAINTAINERS|   5 +
 config/common_linuxapp |  14 +-
 doc/api/doxy-api-index.md  |   4 +-
 doc/api/doxy-api.conf  |   2 +
 doc/api/examples.dox   |   5 +-
 doc/guides/prog_guide/ctrl_if_lib.rst  |  52 ++
 doc/guides/prog_guide/ethtool_lib.rst  |  62 ++
 doc/guides/prog_guide/index.rst|   4 +-
 doc/guides/rel_notes/release_16_04.rst |  10 +
 doc/guides/sample_app_ug/ethtool.rst   |  77 +-
 examples/ethtool/Makefile  |  24 +-
 examples/ethtool/ethapp.c  | 873 +
 examples/ethtool/ethapp.h  |  41 +
 examples/ethtool/ethtool-app/Makefile  |  54 --
 examples/ethtool/ethtool-app/ethapp.c  | 873 -
 examples/ethtool/ethtool-app/ethapp.h  |  41 -
 examples/ethtool/ethtool-app/main.c| 305 ---
 examples/ethtool/lib/Makefile  |  57 --
 examples/ethtool/lib/rte_ethtool.c | 423 

[dpdk-dev] [PATCH v3] doc: add Vector FM10K introductions

2016-02-26 Thread Chen Jing D(Mark)
From: "Chen Jing D(Mark)" 

Add introductions on how to enable Vector FM10K Rx/Tx functions,
the preconditions and assumptions on Rx/Tx configuration parameters.
The new content also lists the limitations of vector, so app/customer
can do better to select best Rx/Tx functions.

Signed-off-by: Chen Jing D(Mark) 
---
v3:
 - rebase to dpdk-next-16.04
 - Minor change to reword a few sentences.

v2:
 - rebase to latest repo
 - Reword a few sentences that not follow coding style.

 doc/guides/nics/fm10k.rst |   98 +
 1 files changed, 98 insertions(+), 0 deletions(-)

diff --git a/doc/guides/nics/fm10k.rst b/doc/guides/nics/fm10k.rst
index 4206b7f..b97f611 100644
--- a/doc/guides/nics/fm10k.rst
+++ b/doc/guides/nics/fm10k.rst
@@ -35,6 +35,104 @@ The FM10K poll mode driver library provides support for the 
Intel FM1
 (FM10K) family of 40GbE/100GbE adapters.


+Vector PMD for FM10K
+
+
+Vector PMD (vPMD) uses Intel? SIMD instructions to optimize packet I/O.
+It improves load/store bandwidth efficiency of L1 data cache by using a wider
+SSE/AVX ''register (1)''.
+The wider register gives space to hold multiple packet buffers so as to save
+on the number of instructions when bulk processing packets.
+
+There is no change to the PMD API. The RX/TX handlers are the only two entries 
for
+vPMD packet I/O. They are transparently registered at runtime RX/TX execution
+if all required conditions are met.
+
+1.  To date, only an SSE version of FM10K vPMD is available.
+To ensure that vPMD is in the binary code, set
+``CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y`` in the configure file.
+
+Some constraints apply as pre-conditions for specific optimizations on bulk
+packet transfers. The following sections explain RX and TX constraints in the
+vPMD.
+
+
+RX Constraints
+~~
+
+
+Prerequisites and Pre-conditions
+
+
+For Vector RX it is assumed that the number of descriptor rings will be a power
+of 2. With this pre-condition, the ring pointer can easily scroll back to the
+head after hitting the tail without a conditional check. In addition Vector RX
+can use this assumption to do a bit mask using ``ring_size - 1``.
+
+
+Features not Supported by Vector RX PMD
+^^^
+
+Some features are not supported when trying to increase the throughput in
+vPMD. They are:
+
+*   IEEE1588
+
+*   Flow director
+
+*   Header split
+
+*   RX checksum offload
+
+Other features are supported using optional MACRO configuration. They include:
+
+*   HW VLAN strip
+
+*   L3/L4 packet type
+
+To enable via ``RX_OLFLAGS`` use ``RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y``.
+
+To guarantee the constraint, the following configuration flags in 
``dev_conf.rxmode``
+will be checked:
+
+*   ``hw_vlan_extend``
+
+*   ``hw_ip_checksum``
+
+*   ``header_split``
+
+*   ``fdir_conf->mode``
+
+
+RX Burst Size
+^
+
+As vPMD is focused on high throughput, it processes 4 packets at a time. So it 
assumes
+that the RX burst should be greater than 4 packets per burst. It returns zero 
if using
+``nb_pkt`` < 4 in the receive handler. If ``nb_pkt`` is not a multiple of 4, a
+floor alignment will be applied.
+
+
+TX Constraint
+~
+
+Features not Supported by TX Vector PMD
+^^^
+
+TX vPMD only works when ``txq_flags`` is set to ``FM10K_SIMPLE_TX_FLAG``.
+This means that it does not support TX multi-segment, VLAN offload or TX csum
+offload. The following MACROs are used for these three features:
+
+*   ``ETH_TXQ_FLAGS_NOMULTSEGS``
+
+*   ``ETH_TXQ_FLAGS_NOVLANOFFL``
+
+*   ``ETH_TXQ_FLAGS_NOXSUMSCTP``
+
+*   ``ETH_TXQ_FLAGS_NOXSUMUDP``
+
+*   ``ETH_TXQ_FLAGS_NOXSUMTCP``
+
 Limitations
 ---

-- 
1.7.7.6



[dpdk-dev] [PATCH v9 0/2] Add VHOST PMD

2016-02-26 Thread Tetsuya Mukawa
On 2016/02/25 16:51, Qiu, Michael wrote:
> On 2/24/2016 1:10 PM, Tetsuya Mukawa wrote:
>> On 2016/02/24 11:45, Qiu, Michael wrote:
>>> Hi,  Tetsuya
>>>
>>> When I applied your v6 patch, I could reach 9.5Mpps with 64B packet.
>>>
>>> But when apply v9 only 8.4 Mpps, could you figure out why has
>>> performance drop?
>> Hi Michael,
>>
>> Thanks for checking it.
>> I tried to re-produce it, but I don't see the drop on my environment.
>> (My cpu is Xeon E5-2697-v2, and the performances of v6 and v9 patch are
>> almost 5.9Mpps)
>> Did you use totally same code except for vhost PMD?
> Yes, totally same code and same platform, only difference is versions of
> vhost PMD.
>
> BTW, I have set the frontend mergeable off.

I have checked below cases.
 - Case1: Disable mergeable feature in virtio-net PMD.
 - Case2: Disable mergeable feature in virtio-net PMD and use
'--txqflags=0xf01' option to use simple ring deploying.
Both cases,  I still cannot see the drop.

Anyway, I will send a few patch-series to determine the cause of drop.
So, could you please apply them and check the performance to determine
which cause the drop?

Thanks,
Tetsuya

> Thanks,
> Michael
>> Thanks,
>> Tetsuya
>>
>>> Thanks,
>>> Michael
>>> On 2/9/2016 5:38 PM, Tetsuya Mukawa wrote:
 The patch introduces a new PMD. This PMD is implemented as thin wrapper
 of librte_vhost.


 PATCH v9 changes:
  - Fix a null pointer access issue implemented in v8 patch.

 PATCH v8 changes:
  - Manage ether devices list instead of internal structures list.
  - Remove needless NULL checking.
  - Replace "pthread_exit" to "return NULL".
  - Replace rte_panic to RTE_LOG, also add error handling.
  - Remove duplicated lines.
  - Remove needless casting.
  - Follow coding style.
  - Remove needless parenthesis.

 PATCH v7 changes:
  - Remove needless parenthesis.
  - Add release note.
  - Remove needless line wraps.
  - Add null pointer check in vring_state_changed().
  - Free queue memory in eth_queue_release().
  - Fix wrong variable name.
  - Fix error handling code of eth_dev_vhost_create() and
rte_pmd_vhost_devuninit().
  - Remove needless null checking from rte_pmd_vhost_devinit/devuninit().
  - Use port id to create mac address.
  - Add doxygen style comments in "rte_eth_vhost.h".
  - Fix wrong comment in "mk/rte.app.mk".

 PATCH v6 changes:
  - Remove rte_vhost_driver_pmd_callback_registe().
  - Support link status interrupt.
  - Support queue state changed interrupt.
  - Add rte_eth_vhost_get_queue_event().
  - Support numa node detection when new device is connected.

 PATCH v5 changes:
  - Rebase on latest master.
  - Fix RX/TX routine to count RX/TX bytes.
  - Fix RX/TX routine not to count as error packets if enqueue/dequeue
cannot send all packets.
  - Fix if-condition checking for multiqueues.
  - Add "static" to pthread variable.
  - Fix format.
  - Change default behavior not to receive queueing event from driver.
  - Split the patch to separate rte_eth_vhost_portid2vdev().

 PATCH v4 changes:
  - Rebase on latest DPDK tree.
  - Fix cording style.
  - Fix code not to invoke multiple messaging handling threads.
  - Fix code to handle vdev parameters correctly.
  - Remove needless cast.
  - Remove needless if-condition before rt_free().

 PATCH v3 changes:
  - Rebase on latest matser
  - Specify correct queue_id in RX/TX function.

 PATCH v2 changes:
  - Remove a below patch that fixes vhost library.
The patch was applied as a separate patch.
- vhost: fix crash with multiqueue enabled
  - Fix typos.
(Thanks to Thomas, Monjalon)
  - Rebase on latest tree with above bernard's patches.

 PATCH v1 changes:
  - Support vhost multiple queues.
  - Rebase on "remove pci driver from vdevs".
  - Optimize RX/TX functions.
  - Fix resource leaks.
  - Fix compile issue.
  - Add patch to fix vhost library.

 RFC PATCH v3 changes:
  - Optimize performance.
In RX/TX functions, change code to access only per core data.
  - Add below API to allow user to use vhost library APIs for a port managed
by vhost PMD. There are a few limitations. See "rte_eth_vhost.h".
 - rte_eth_vhost_portid2vdev()
To support this functionality, vhost library is also changed.
Anyway, if users doesn't use vhost PMD, can fully use vhost library 
 APIs.
  - Add code to support vhost multiple queues.
Actually, multiple queues functionality is not enabled so far.

 RFC PATCH v2 changes:
  - Fix issues reported by checkpatch.pl
(Thanks to Stephen Hemminger)


 Tetsuya Mukawa (2):
   ethdev: Add a new event type to notify a queue state changed event
   vhost: Add VHOST PMD

[dpdk-dev] [PATCH v4 12/12] examples/l3fwd: add option to parse ptype

2016-02-26 Thread Ananyev, Konstantin
Hi Jianfeng,

> 
> +static int
> +check_packet_type_ok(int portid)
> +{
> + int i, ret;
> + int ptype_l3_ipv4 = 0, ptype_l3_ipv6 = 0;
> +
> + ret = rte_eth_dev_get_ptype_info(portid, RTE_PTYPE_L3_MASK, NULL, 0);
> + if (ret <= 0)
> + return 0;
> +
> + uint32_t ptypes[ret];
> +
> + ret = rte_eth_dev_get_ptype_info(portid, RTE_PTYPE_L3_MASK,
> +  ptypes, ret);
> + /* It is not a perfect pre-check, i.e., IP packets with extension and
> +  * IP packets which are not TCP/UDP, can pass this check, but cannot
> +  * work well at the mode of EXACT_MATCH.
> +  */
> + for (i = 0; i < ret; ++i) {
> + if (ptypes[i] & RTE_PTYPE_L3_IPV4)
> + ptype_l3_ipv4 = 1;
> + if (ptypes[i] & RTE_PTYPE_L3_IPV6)
> + ptype_l3_ipv6 = 1;
> + }
> +
> + if (ptype_l3_ipv4 == 0)
> + printf("port %d cannot parse RTE_PTYPE_L3_IPV4\n", portid);
> +
> + if (ptype_l3_ipv6 == 0)
> + printf("port %d cannot parse RTE_PTYPE_L3_IPV6\n", portid);
> +
> + if (ptype_l3_ipv4 && ptype_l3_ipv6)
> + return 1;
> +
> + return 0;
> +}
> +static inline void
> +parse_packet_type(struct rte_mbuf *m)
> +{
> + struct ether_hdr *eth_hdr;
> + uint32_t packet_type = 0;
> + uint16_t ethertype;
> +
> + eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
> + ethertype = rte_be_to_cpu_16(eth_hdr->ether_type);
> + switch (ethertype) {
> + case ETHER_TYPE_IPv4:
> +#if (APP_LOOKUP_METHOD == APP_LOOKUP_EXACT_MATCH)
> + {
> + int hdr_len;
> + struct ipv4_hdr *hdr;
> +
> + hdr = (struct ipv4_hdr *)((uint8_t *)eth_hdr +
> + sizeof(struct ether_hdr));
> + hdr_len = (hdr->version_ihl & IPV4_HDR_IHL_MASK)
> + * IPV4_IHL_MULTIPLIER;
> + /* Exact match uses 5 tuples to calculate hash, so
> +  * adequate packets should not only have no ip header
> +  * extension but also be TCP/UDP packet
> +  */
> + if (hdr_len == sizeof(struct ipv4_hdr) &&
> + (hdr->next_proto_id == 6 ||
> +  hdr->next_proto_id == 17))

Use IPPORTO_UDP, IPPORTO_TCP instead of hardcoded values.

> + packet_type |= RTE_PTYPE_L3_IPV4;
> + }

Actually it is a good point:
for EM case should l3fwd process only TCP/UDP packets?
If yes, then it needs to check not only L3, but also L4 type too
Which means that for EM and LPM check_packet_type_ok() should also be different.
Or we can leave it as it is - in that case EM even for non UDP/TCP packet would 
still
do route  lookup using first 4B of L3 payload.

If you choose first approach, then there is another thing to consider -
there are 2 patches in flight for l3fwd:
http://dpdk.org/dev/patchwork/patch/10800/
http://dpdk.org/dev/patchwork/patch/10782/

Which makes LPM/EM choice for l3fwd a runtime decision.
So  APP_LOOKUP_METHOD macro would not be available after it.
Probably need to take that into account for your changes.
Might be exclude l3fwd from this patch series, then rebase it
on these patches and submit as a separate one?

> +#elif (APP_LOOKUP_METHOD == APP_LOOKUP_LPM)
> + packet_type |= RTE_PTYPE_L3_IPV4_EXT_UNKNOWN;
> +#endif
> + break;
> + case ETHER_TYPE_IPv6:
> +#if (APP_LOOKUP_METHOD == APP_LOOKUP_EXACT_MATCH)
> + {
> + struct ipv6_hdr *hdr;
> +
> + hdr = (struct ipv6_hdr *)((uint8_t *)eth_hdr +
> +   sizeof(struct ether_hdr));
> + if (hdr->proto == 6 || hdr->proto == 17)
> + packet_type |= RTE_PTYPE_L3_IPV4;

s/ RTE_PTYPE_L3_IPV4/RTE_PTYPE_L3_IPV6/
?

Apart from that the series looks good to me.
Konstantin



[dpdk-dev] [PATCH v2] doc: Malicious Driver Detection not supported by ixgbe

2016-02-26 Thread Wenzhuo Lu
Announce that Malicious Driver Detection is not supported.

V2:
 *Rework the words.

Signed-off-by: Wenzhuo Lu 
---
 doc/guides/nics/ixgbe.rst  | 20 
 doc/guides/rel_notes/release_16_04.rst | 23 +++
 2 files changed, 43 insertions(+)

diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 8cae299..7218cdd 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -147,6 +147,26 @@ The following MACROs are used for these three features:

 *   ETH_TXQ_FLAGS_NOXSUMTCP

+Malicious Driver Detection not Supported by ixgbe
+^
+
+The Intel x550 series NICs support a feature called MDD (Malcicious
+Driver Detection) which checks the behavior of the VF driver.
+If this feature is enabled, the VF must use the advanced context descriptor
+correctly and set the CC (Check Context) bit.
+DPDK PF doesn't support MDD, but kernel PF does. We may hit problem in this
+scenario kernel PF + DPDK VF. If user enables MDD in kernel PF, DPDK VF will
+not work. Because kernel PF thinks the VF is malicious. But actually it's not.
+The only reason is the VF doesn't act as MDD required.
+There's significant performance impact to support MDD. DPDK should check if
+the advanced context descriptor should be set and set it. And DPDK has to ask
+the info about the header length from the upper layer, because parsing the
+packet itself is not acceptale. So, it's too expensive to support MDD.
+When using kernel PF + DPDK VF on x550, please make sure using the kernel
+driver that disables MDD or can disable MDD. (Some kernel driver can use
+this CLI 'insmod ixgbe.ko MDD=0,0' to disable MDD. Some kernel driver disables
+it by default.)
+

 Sample Application Notes
 
diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 5786f74..0647896 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -90,6 +90,29 @@ This section should contain new known issues in this 
release. Sample format:
   tense. Add information on any known workarounds.


+Restriction
+---
+
+* **Malicious Driver Detection is not supported by ixgbe**
+
+  The Intel x550 series NICs support a feature called MDD (Malcicious
+  Driver Detection) which checks the behavior of the VF driver.
+  If this feature is enabled, the VF must use the advanced context descriptor
+  correctly and set the CC (Check Context) bit.
+  DPDK PF doesn't support MDD, but kernel PF does. We may hit problem in this
+  scenario kernel PF + DPDK VF. If user enables MDD in kernel PF, DPDK VF will
+  not work. Because kernel PF thinks the VF is malicious. But actually it's 
not.
+  The only reason is the VF doesn't act as MDD required.
+  There's significant performance impact to support MDD. DPDK should check if
+  the advanced context descriptor should be set and set it. And DPDK has to ask
+  the info about the header length from the upper layer, because parsing the
+  packet itself is not acceptale. So, it's too expensive to support MDD.
+  When using kernel PF + DPDK VF on x550, please make sure using the kernel
+  driver that disables MDD or can disable MDD. (Some kernel driver can use
+  this CLI 'insmod ixgbe.ko MDD=0,0' to disable MDD. Some kernel driver 
disables
+  it by default.)
+
+
 API Changes
 ---

-- 
1.9.3



[dpdk-dev] ACL memory allocation failures

2016-02-26 Thread Ananyev, Konstantin


> 
> Thanks Konstantin.
> 
> Previous allocation error was coming with 1024 huge pages of 2 MB size.
> 
> After increasing the huge pages to 2048, I was able to add another ~140 rules 
> [IPv4 rule data--> with src, dst IP address & port, next
> header ] more, ie., 950 rules were added.

That's strange according to your log, all you need is ~13MB of hugepage memory:
ACL: allocation of 12966528 bytes on socket 0 for ipv4_acl_table1
Wonder what consumed rest of 4GB?
Again do you re-build your table after every rule you add?
If so, then it seems a bit strange approach (and definitely not the fastest 
one).
What you can do instead: create context; add all your rules into it; build; 

> 
> Logically it did not increase number of rules [expected 2*817, but only 950 
> were added]. Is it really using huge pages memory only?
> 
> From the code it looks like heap memory. [ ret = 
> malloc_heap_alloc(>malloc_heaps[i], type, size, 0, align == 0 ? 1 : 
> align, 0) ]

As I can see from the log it fails at GEN phase, when trying to allocate 
hugepages for RT table.
At lib/librte_acl/acl_gen.c:509

rte_acl_gen(struct rte_acl_ctx *ctx, struct rte_acl_trie *trie,
struct rte_acl_bld_trie *node_bld_trie, uint32_t num_tries,
uint32_t num_categories, uint32_t data_index_sz, size_t max_size)
{
...
mem = rte_zmalloc_socket(ctx->name, total_size, RTE_CACHE_LINE_SIZE,
ctx->socket_id);
if (mem == NULL) {
RTE_LOG(ERR, ACL,
"allocation of %zu bytes on socket %d for %s failed\n",
total_size, ctx->socket_id, ctx->name);
return -ENOMEM;
}

Konstantin

> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Rapelly, Varun
> > Sent: Friday, February 26, 2016 10:28 AM
> > To: dev at dpdk.org
> > Subject: Re: [dpdk-dev] ACL memory allocation failures
> >
> > Hi All,
> >
> > When I'm trying to configure some 5000+ ACL rules with different
> > source IP addresses, getting ACL memory allocation failure. I'm using DPDK 
> > 2.1.
> >
> > [root at ACLISSUE log_2015_10_26_08_19_42]# vim np.log match nodes/bytes
> > used: 816/104448
> > total: 12940832 bytes
> > ACL: Build phase for ACL "ipv4_acl_table2":
> > memory consumed: 947913495
> > ACL: trie 0: number of rules: 816
> > ACL: allocation of 12966528 bytes on socket 0 for ipv4_acl_table1
> > failed
> > ACL: Build phase for ACL "ipv4_acl_table1":
> > memory consumed: 947913495
> > ACL: trie 0: number of rules: 817
> > EAL: Error - exiting with code: 1
> >   Cause: Failed to build ACL trie
> >
> > Again sourced the ACL config file. After adding around 77 again the same 
> > error came.
> >
> > total: 14912784 bytes
> > ACL: Build phase for ACL "ipv4_acl_table1":
> > memory consumed: 1040188260
> > ACL: trie 0: number of rules: 893
> > ACL: allocation of 14938480 bytes on socket 0 for ipv4_acl_table2
> > failed
> 
> You are running out of hugepages memory.
> 
> > ACL: Build phase for ACL "ipv4_acl_table2":
> > memory consumed: 1040188260
> > ACL: trie 0: number of rules: 894
> > EAL: Error - exiting with code: 1
> >   Cause: Failed to build ACL trie
> >
> > Where to increase the memory to avoid this issue?
> 
>  Refer to:
> http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html#running-dpdk-applications
> Section 2.3.2
> 
> Konstantin



[dpdk-dev] ACL memory allocation failures

2016-02-26 Thread Rapelly, Varun
Thanks Konstantin.

Previous allocation error was coming with 1024 huge pages of 2 MB size. 

After increasing the huge pages to 2048, I was able to add another ~140 rules 
[IPv4 rule data--> with src, dst IP address & port, next header ] more, ie., 
950 rules were added.

Logically it did not increase number of rules [expected 2*817, but only 950 
were added]. Is it really using huge pages memory only? 

>From the code it looks like heap memory. [ ret = 
>malloc_heap_alloc(>malloc_heaps[i], type, size, 0, align == 0 ? 1 : 
>align, 0) ]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Rapelly, Varun
> Sent: Friday, February 26, 2016 10:28 AM
> To: dev at dpdk.org
> Subject: Re: [dpdk-dev] ACL memory allocation failures
> 
> Hi All,
> 
> When I'm trying to configure some 5000+ ACL rules with different 
> source IP addresses, getting ACL memory allocation failure. I'm using DPDK 
> 2.1.
> 
> [root at ACLISSUE log_2015_10_26_08_19_42]# vim np.log match nodes/bytes 
> used: 816/104448
> total: 12940832 bytes
> ACL: Build phase for ACL "ipv4_acl_table2":
> memory consumed: 947913495
> ACL: trie 0: number of rules: 816
> ACL: allocation of 12966528 bytes on socket 0 for ipv4_acl_table1 
> failed
> ACL: Build phase for ACL "ipv4_acl_table1":
> memory consumed: 947913495
> ACL: trie 0: number of rules: 817
> EAL: Error - exiting with code: 1
>   Cause: Failed to build ACL trie
> 
> Again sourced the ACL config file. After adding around 77 again the same 
> error came.
> 
> total: 14912784 bytes
> ACL: Build phase for ACL "ipv4_acl_table1":
> memory consumed: 1040188260
> ACL: trie 0: number of rules: 893
> ACL: allocation of 14938480 bytes on socket 0 for ipv4_acl_table2 
> failed

You are running out of hugepages memory.

> ACL: Build phase for ACL "ipv4_acl_table2":
> memory consumed: 1040188260
> ACL: trie 0: number of rules: 894
> EAL: Error - exiting with code: 1
>   Cause: Failed to build ACL trie
> 
> Where to increase the memory to avoid this issue?

 Refer to:
http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html#running-dpdk-applications
Section 2.3.2 

Konstantin



[dpdk-dev] [PATCH v3] ixgbe: support link speed auto-neg on x550em_x

2016-02-26 Thread Wenzhuo Lu
Normally the auto-negotiation is supported by FW. SW need not care about
that. But on x550em_x, FW doesn't support auto-neg. As the ports of x550em_x
are 10G, if we connect the port will a peer which is 1G, the link will always
be down.
We need support auto-neg by SW to avoid this link down issue. As we already
have the code to handle the link speed setting, what we need is a trigger.
When the advertised link speed changes, a PHY interruption will be triggered.
So, we should handle this interruption and call ixgbe_handle_lasi to set the
link speed correctly.

Please be aware it's working when auto-neg is on. If the auto-neg of the peer
port is turned off and its speed is indicated manually, we should also set
the speed of our own port manually.

V2:
 *Fix the wrong signoff name.

V3:
 *Change the tittle and add the explanation of the implementation in commit log.

Signed-off-by: Wenzhuo Lu 
Acked-by: Shaopeng He 
---
 doc/guides/rel_notes/release_16_04.rst |  8 +++
 drivers/net/ixgbe/ixgbe_ethdev.c   | 38 ++
 drivers/net/ixgbe/ixgbe_ethdev.h   |  1 +
 3 files changed, 47 insertions(+)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 8273817..fbdf286 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -46,6 +46,14 @@ This section should contain new features added in this 
release. Sample format:

 * **Added vhost-user live migration support.**

+* **Supported link speed auto-negotiation on X550EM_X**
+
+  Normally the auto-negotiation is supported by FW. SW need not care about
+  that. But on x550em_x, FW doesn't support auto-neg. As the ports of x550em_x
+  are 10G, if we connect the port will a peer which is 1G, the link will always
+  be down.
+  We added the support of auto-neg by SW to avoid this link down issue.
+

 Resolved Issues
 ---
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 3e6fe86..2384ba7 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1961,6 +1961,25 @@ ixgbe_dev_configure(struct rte_eth_dev *dev)
return 0;
 }

+static void
+ixgbe_dev_phy_intr_setup(struct rte_eth_dev *dev)
+{
+   struct ixgbe_hw *hw =
+   IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct ixgbe_interrupt *intr =
+   IXGBE_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
+   uint32_t gpie;
+
+   /* only set up it on X550EM_X */
+   if (hw->mac.type == ixgbe_mac_X550EM_x) {
+   gpie = IXGBE_READ_REG(hw, IXGBE_GPIE);
+   gpie |= IXGBE_SDP0_GPIEN_X550EM_x;
+   IXGBE_WRITE_REG(hw, IXGBE_GPIE, gpie);
+   if (hw->phy.type == ixgbe_phy_x550em_ext_t)
+   intr->mask |= IXGBE_EICR_GPI_SDP0_X550EM_x;
+   }
+}
+
 /*
  * Configure device link speed and setup link.
  * It returns 0 on success.
@@ -2009,6 +2028,8 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
/* configure PF module if SRIOV enabled */
ixgbe_pf_host_configure(dev);

+   ixgbe_dev_phy_intr_setup(dev);
+
/* check and configure queue intr-vector mapping */
if ((rte_intr_cap_multiple(intr_handle) ||
 !RTE_ETH_DEV_SRIOV(dev).active) &&
@@ -3082,6 +3103,11 @@ ixgbe_dev_interrupt_get_status(struct rte_eth_dev *dev)
if (eicr & IXGBE_EICR_MAILBOX)
intr->flags |= IXGBE_FLAG_MAILBOX;

+   if (hw->mac.type ==  ixgbe_mac_X550EM_x &&
+   hw->phy.type == ixgbe_phy_x550em_ext_t &&
+   (eicr & IXGBE_EICR_GPI_SDP0_X550EM_x))
+   intr->flags |= IXGBE_FLAG_PHY_INTERRUPT;
+
return 0;
 }

@@ -3137,6 +3163,8 @@ ixgbe_dev_interrupt_action(struct rte_eth_dev *dev)
int64_t timeout;
struct rte_eth_link link;
int intr_enable_delay = false;
+   struct ixgbe_hw *hw =
+   IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);

PMD_DRV_LOG(DEBUG, "intr action type %d", intr->flags);

@@ -3145,6 +3173,11 @@ ixgbe_dev_interrupt_action(struct rte_eth_dev *dev)
intr->flags &= ~IXGBE_FLAG_MAILBOX;
}

+   if (intr->flags & IXGBE_FLAG_PHY_INTERRUPT) {
+   ixgbe_handle_lasi(hw);
+   intr->flags &= ~IXGBE_FLAG_PHY_INTERRUPT;
+   }
+
if (intr->flags & IXGBE_FLAG_NEED_LINK_UPDATE) {
/* get the link status before link update, for predicting later 
*/
memset(, 0, sizeof(link));
@@ -3208,6 +3241,11 @@ ixgbe_dev_interrupt_delayed_handler(void *param)
if (eicr & IXGBE_EICR_MAILBOX)
ixgbe_pf_mbx_process(dev);

+   if (intr->flags & IXGBE_FLAG_PHY_INTERRUPT) {
+   ixgbe_handle_lasi(hw);
+   intr->flags &= ~IXGBE_FLAG_PHY_INTERRUPT;
+   }
+
if (intr->flags & IXGBE_FLAG_NEED_LINK_UPDATE) {
ixgbe_dev_link_update(dev, 0);

[dpdk-dev] ACL memory allocation failures

2016-02-26 Thread Ananyev, Konstantin


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Rapelly, Varun
> Sent: Friday, February 26, 2016 10:28 AM
> To: dev at dpdk.org
> Subject: Re: [dpdk-dev] ACL memory allocation failures
> 
> Hi All,
> 
> When I'm trying to configure some 5000+ ACL rules with different source IP 
> addresses, getting ACL memory allocation failure. I'm using
> DPDK 2.1.
> 
> [root at ACLISSUE log_2015_10_26_08_19_42]# vim np.log
> match nodes/bytes used: 816/104448
> total: 12940832 bytes
> ACL: Build phase for ACL "ipv4_acl_table2":
> memory consumed: 947913495
> ACL: trie 0: number of rules: 816
> ACL: allocation of 12966528 bytes on socket 0 for ipv4_acl_table1 failed
> ACL: Build phase for ACL "ipv4_acl_table1":
> memory consumed: 947913495
> ACL: trie 0: number of rules: 817
> EAL: Error - exiting with code: 1
>   Cause: Failed to build ACL trie
> 
> Again sourced the ACL config file. After adding around 77 again the same 
> error came.
> 
> total: 14912784 bytes
> ACL: Build phase for ACL "ipv4_acl_table1":
> memory consumed: 1040188260
> ACL: trie 0: number of rules: 893
> ACL: allocation of 14938480 bytes on socket 0 for ipv4_acl_table2 failed

You are running out of hugepages memory.

> ACL: Build phase for ACL "ipv4_acl_table2":
> memory consumed: 1040188260
> ACL: trie 0: number of rules: 894
> EAL: Error - exiting with code: 1
>   Cause: Failed to build ACL trie
> 
> Where to increase the memory to avoid this issue?

 Refer to:
http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html#running-dpdk-applications
Section 2.3.2 

Konstantin



[dpdk-dev] ACL memory allocation failures

2016-02-26 Thread Rapelly, Varun
Hi All,

When I'm trying to configure some 5000+ ACL rules with different source IP 
addresses, getting ACL memory allocation failure. I'm using DPDK 2.1.

[root at ACLISSUE log_2015_10_26_08_19_42]# vim np.log
match nodes/bytes used: 816/104448
total: 12940832 bytes
ACL: Build phase for ACL "ipv4_acl_table2":
memory consumed: 947913495
ACL: trie 0: number of rules: 816
ACL: allocation of 12966528 bytes on socket 0 for ipv4_acl_table1 failed
ACL: Build phase for ACL "ipv4_acl_table1":
memory consumed: 947913495
ACL: trie 0: number of rules: 817
EAL: Error - exiting with code: 1
  Cause: Failed to build ACL trie

Again sourced the ACL config file. After adding around 77 again the same error 
came.

total: 14912784 bytes
ACL: Build phase for ACL "ipv4_acl_table1":
memory consumed: 1040188260
ACL: trie 0: number of rules: 893
ACL: allocation of 14938480 bytes on socket 0 for ipv4_acl_table2 failed
ACL: Build phase for ACL "ipv4_acl_table2":
memory consumed: 1040188260
ACL: trie 0: number of rules: 894
EAL: Error - exiting with code: 1
  Cause: Failed to build ACL trie

Where to increase the memory to avoid this issue?

Regards,
Varun



[dpdk-dev] ACL memory allocation failures

2016-02-26 Thread Rapelly, Varun
Hi All,

When I'm trying to configure some 5000+ ACL rules with different source IP 
addresses, getting ACL memory allocation failure.\

[root at ACLISSUE log_2015_10_26_08_19_42]# vim np.log
match nodes/bytes used: 816/104448
total: 12940832 bytes
ACL: Build phase for ACL "ipv4_acl_table2":
memory consumed: 947913495
ACL: trie 0: number of rules: 816
ACL: allocation of 12966528 bytes on socket 0 for ipv4_acl_table1 failed
ACL: Build phase for ACL "ipv4_acl_table1":
memory consumed: 947913495
ACL: trie 0: number of rules: 817
EAL: Error - exiting with code: 1
  Cause: Failed to build ACL trie

Again sourced the ACL config file. After adding around 77 again the same error 
came.

total: 14912784 bytes
ACL: Build phase for ACL "ipv4_acl_table1":
memory consumed: 1040188260
ACL: trie 0: number of rules: 893
ACL: allocation of 14938480 bytes on socket 0 for ipv4_acl_table2 failed
ACL: Build phase for ACL "ipv4_acl_table2":
memory consumed: 1040188260
ACL: trie 0: number of rules: 894
EAL: Error - exiting with code: 1
  Cause: Failed to build ACL trie

Where to increase the memory to avoid this issue?

Regards,
Varun



[dpdk-dev] virtio PMD is not working with master version

2016-02-26 Thread Yuanhan Liu
Mauricio, thanks for the testing and report.

On Thu, Feb 25, 2016 at 02:30:18PM +0100, David Marchand wrote:
> On Thu, Feb 25, 2016 at 12:30 PM, Mauricio V?squez
>  wrote:
> > ...
> > EAL: PCI device :00:04.0 on NUMA socket -1
> > EAL:   probe driver: 1af4:1000 rte_virtio_pmd
> > EAL:   PCI memory mapped at 0x7f892dc0
> > PMD: virtio_read_caps(): [40] skipping non VNDR cap id: 11
> > PMD: virtio_read_caps(): no modern virtio pci device found.
> > PMD: vtpci_init(): trying with legacy virtio pci.
> > EAL: eal_parse_sysfs_value(): cannot open sysfs value
> > /sys/bus/pci/devices/:00:04.0/uio/uio0/portio/port0/start
> > EAL: pci_uio_ioport_map(): cannot parse portio start
> > EAL: Error - exiting with code: 1
> >   Cause: Requested device :00:04.0 cannot be used
> > ...
> 
> [snip]
> 
> > ...
> > PMD: parse_sysfs_value(): parse_sysfs_value(): cannot open sysfs value
> > /sys/bus/pci/devices/:00:04.0/uio/uio0/portio/port0/size
> > PMD: virtio_resource_init_by_uio(): virtio_resource_init_by_uio(): cannot
> > parse size
> > PMD: virtio_resource_init_by_ioports(): PCI Port IO found start=0xc100 with
> > size=0x20
> 
> [snip]
> 
> >
> > According to git bisect it appears to be that it does not work anymore after
> > the b8f04520ad71 ("virtio: use PCI ioport API") commit.
> 
> >From the logs, I would say I broke uio_pci_generic since we are in
> "uio" case, but uio portio sysfs does not exist.
> virtio pmd fell back to ioports discovery before my change.

Maybe we can do same?

---
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 4346973..579731c 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -685,12 +685,11 @@ int
 rte_eal_pci_ioport_map(struct rte_pci_device *dev, int bar,
   struct rte_pci_ioport *p)
 {
-   int ret;
+   int ret = -1;

switch (dev->kdrv) {
 #ifdef VFIO_PRESENT
case RTE_KDRV_VFIO:
-   ret = -1;
if (pci_vfio_is_enabled())
ret = pci_vfio_ioport_map(dev, bar, p);
break;
@@ -700,14 +699,14 @@ rte_eal_pci_ioport_map(struct rte_pci_device *dev, int 
bar,
ret = pci_uio_ioport_map(dev, bar, p);
break;
default:
+   break;
+   }
+
 #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
-   /* special case for x86 ... */
+   /* special case for x86 ... */
+   if (ret)
ret = pci_ioport_map(dev, bar, p);
-#else
-   ret = -1;
 #endif
-   break;
-   }

if (!ret)
p->dev = dev;
---


If that looks okay to you, I could send a formal patch.

--yliu

> Problem can be workaround for now by unbinding your device from
> uio_pci_generic or on the contrary bind to igb_uio.
> 
> I've been sick at home, all this week.
> Will see next week for a fix unless someone sends one.
> 
> 
> -- 
> David Marchand


[dpdk-dev] Virtio xstats problem

2016-02-26 Thread Kyle Larose
On Fri, Feb 26, 2016 at 9:35 AM, Igor Ryzhov  wrote:
> Hello, Harry.
>
> Understood about size of packets. It's a bit confusing, because in all other 
> drivers undersized packet is an error. Maybe we should add another one size 
> bin for virtio - 60 to 63 bytes?
>

I'm not sure we need to add a new bucket. According to the rmon MIB
(which defines histogram counters) the undersize bucket doesn't
necessarily mean that there was an error. It just means that the
packet was less than 64 bytes:

 "The total number of packets received that were
 less than 64 octets long (excluding framing bits,
 but including FCS octets) and were otherwise well
 formed."

This is from https://tools.ietf.org/html/rfc2819

Now, whether we want to align with the standard is up for debate, but
I think we should try to as much as possible. I guess we could add the
60-63 bucket, and then count those packets in undersized as well.
There's a similar problem when mapping large packets to the rmon mib.
It has an "oversized" bucket, which is everything above 1518. A packet
incrementing that bucket isn't an error; it's just the "everything
else" bucket in the histogram.

We could also talk about the bit about it "including FCS octets", but
things get a little tricky there. Do we want to assume that all
packets received on a virtio interface had a 4-byte FCS at some point,
and add 4 bytes to each packet? That will be true for anything coming
from the wire, but for inter-VM communication over a vswitch, it may
not be.

> I already checked about multicast/broadcast counters - broadcast packets are 
> counted twice:
>
> vq->multicast += is_multicast_ether_addr(ea);
> vq->broadcast += is_broadcast_ether_addr(ea);
>
> I think it should be something like:
>
> if (is_multicast_ether_addr(ea)) {
> if (is_broadcast_ether_addr(ea)) {
> vq->broadcast++;
> } else {
> vq->multicast++;
> }
> }
>
> Best regards,
> Igor
>
>> 26 . 2016 ?., ? 17:29, Van Haaren, Harry  
>> ???(?):
>>
>>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Igor Ryzhov
>>> I found some problem with virtio xstats counters.
>>>
>>> Example:
>>>
>>> rx_good_packets: 3
>>> rx_good_bytes: 180
>>> rx_errors: 0
>>>
>>> rx_q0_good_packets: 3
>>> rx_q0_good_bytes: 180
>>> rx_q0_errors: 0
>>>
>>> rx_q0_multicast_packets: 3
>>> rx_q0_broadcast_packets: 1
>>> rx_q0_undersize_packets: 3
>>
>>> It means that undersize packets are counted as good packets instead of 
>>> errors.
>>
>> Are you sending 64 byte packets? There are no 4 bytes of CRC on virtual
>> interfaces, so 60 bytes per packet is OK.
>>
>>> Or maybe
>>> size of packet is calculated wrong.
>>> I don't have time now to check it more deeply - I can do it sometime later, 
>>> but maybe
>>> someone want to help.
>>
>> Are the packets multicast or broadcast?
>> It looks like one of the counters there is wrong.
>>
>>> PS. Is it a common practice to count broadcast packets twice - in broadcast 
>>> and multicast
>>> counters?
>>
>> No packet should be counted twice - it must be put into one bucket of mutli, 
>> broad or unicast.
>>
>> -Harry


Kyle


[dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API

2016-02-26 Thread Olivier MATZ
Hi Huawei,

On 02/26/2016 10:07 AM, Xie, Huawei wrote:
> On 2/26/2016 4:56 PM, Olivier MATZ wrote:
>> test_one_pktmbuf(struct rte_mbuf *m)
>> {
>>  /* same as before without the allocation/free */
>> }
>>
>> test_pkt_mbuf(void)
>> {
>>  m = rte_pktmbuf_alloc(pool);
>>  test_one_pktmbuf(m);
>>  rte_pktmbuf_free(m);
>>
>>  ret = rte_pktmbuf_alloc_bulk(pool, mtab, BULK_CNT)
>>  for (i = 0; i < BULK_CNT; i++) {
>>  m = mtab[i];
>>  test_one_pktmbuf(m);
>>  rte_pktmbuf_free(m);
>>  }
>> }
> 
> This is to test the functionality.
> Let us also have the case like the following?
> cycles_start = rte_get_timer_cycles();
> while(rounds--) {
> 
>   ret = rte_pktmbuf_alloc_bulk(pool, mtab, BULK_CNT)
>   for (i = 0; i < BULK_CNT; i++) {
>   m = mtab[i];
>   /* some work if needed */
>   rte_pktmbuf_free(m);
>   }
> }
>   cycles_end = rte_get_timer_cycles();
> 
> to compare with
>cycles_start = rte_get_timer_cycles();
>while(rounds--) {
> for (i = 0; i < BULK_CNT; i++)
> mtab[i] = rte_pktmbuf_alloc(...);
> 
>   ret = rte_pktmbuf_alloc_bulk(pool, mtab, BULK_CNT)
>   for (i = 0; i < BULK_CNT; i++) {
>   m = mtab[i];
>   /* some work if needed */
>   rte_pktmbuf_free(m);
>   }
> }
>   cycles_end = rte_get_timer_cycles();

In my opinion, it's already quite obvious that the bulk allocation
will be faster than the non-bulk (and we already have some mempool
benchmarks showing it). So I would say that functional testing is
enough.

On the other hand, it would be good to see if some examples
applications could be updated to take advantage of the new API (as
you did for the librte_vhost).

What do you think?


[dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding

2016-02-26 Thread Thomas Monjalon
2016-02-26 04:31, Wang, Xiao W:
> From: Richardson, Bruce
> > On Thu, Feb 25, 2016 at 03:45:45PM +, Chen, Jing D wrote:
> > > From: Richardson, Bruce
> > > > On Thu, Feb 25, 2016 at 10:04:02AM +, Chen, Jing D wrote:
> > > > > This feature is trying to use FTAG (a unique tech in fm10k)
> > > > > instead of mac/vlan to forward packets. App need a way to tell PMD
> > > > > driver that which forwarding style it would like to use.
> > > >
> > > > Why not just specify this in the port configuration at setup time?
> > > >
> > >
> > > Please educate me. I think the port configuration flags are also
> > > common to all PMD Drivers. Is it possible to add a flag like 
> > > "RTE_USE_FTAG"
> > and pass to PMD driver?
> > >
> > They are.
> > For something PMD specific, like FTAG, it's always a challenge, and I don't
> > know off the top of my head if there is a simple option. However, given the
> > choice between an mbuf flag and a port config flag, I'd always choose the
> > former.
> > Other alternatives would be to have a fm10k specific API in the fm10k driver
> > alone.
> > 
> > I'll let Thomas as ethdev maintainer comment if he has other suggestions as 
> > to
> > how to handle this case. I suspect this won't be the first device-specific 
> > piece of
> > functionality we need to deal with.
> > 
> > /Bruce
> 
> Whatever method we choose, we have to find a way for the user to express his 
> need
> for FTAG, it maybe a build time config option, or a port config flag (no such 
> flag now),
> or a fast path flag in mbuf (no such flag now) etc. For the customer Topsec's 
> use case,
> they use FTAG for all the TX packets, so all the above methods (per build 
> config, per
> port config, per mbuf config) can meet their need. Since the pmd frame work 
> is for
> common, it's hard to add new fields only for one specific NIC, so I add a 
> build time
> config and make an introduction in the doc.
> 
> Thanks for the discussion, Thomas, do you have any suggestions?

I don't understand why you say this feature is specific to fm10k. Can we
imagine another NIC having this capability?
I think it must be an port configuration, as Bruce suggested.
What about a field in struct rte_eth_conf?


[dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API

2016-02-26 Thread Olivier MATZ


On 02/23/2016 06:35 AM, Xie, Huawei wrote:
>>> Also, it would be nice to have a simple test function in
>>> app/test/test_mbuf.c. For instance, you could update
>>> test_one_pktmbuf() to take a mbuf pointer as a parameter and remove
>>> the mbuf allocation from the function. Then it could be called with
>>> a mbuf allocated with rte_pktmbuf_alloc() (like before) and with
>>> all the mbufs of rte_pktmbuf_alloc_bulk().
> 
> Don't quite get you. Is it that we write two cases, one case allocate
> mbuf through rte_pktmbuf_alloc_bulk and one use rte_pktmbuf_alloc? It is
> good to have. 

Yes, something like:

test_one_pktmbuf(struct rte_mbuf *m)
{
/* same as before without the allocation/free */
}

test_pkt_mbuf(void)
{
m = rte_pktmbuf_alloc(pool);
test_one_pktmbuf(m);
rte_pktmbuf_free(m);

ret = rte_pktmbuf_alloc_bulk(pool, mtab, BULK_CNT)
for (i = 0; i < BULK_CNT; i++) {
m = mtab[i];
test_one_pktmbuf(m);
rte_pktmbuf_free(m);
}
}

> I could do this after this patch.

Yes, please.


Thanks,
Olivier


[dpdk-dev] [PATCH v4 2/4] eal: set kdrv to RTE_KDRV_NONE if kernel driver isn't managing the device

2016-02-26 Thread Huawei Xie
v4 changes:
 reword the commit message. When we mention kernel driver, emphasizes
that it includes UIO/VFIO.

Use RTE_KDRV_NONE to indicate that kernel driver(including UIO/VFIO)
isn't manipulating the device.

Signed-off-by: Huawei Xie 
Acked-by: Yuanhan Liu 
---
 lib/librte_eal/linuxapp/eal/eal_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 4346973..b44fa32 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -362,7 +362,7 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t 
bus,
else
dev->kdrv = RTE_KDRV_UNKNOWN;
} else
-   dev->kdrv = RTE_KDRV_UNKNOWN;
+   dev->kdrv = RTE_KDRV_NONE;

/* device is valid, add in list (sorted) */
if (TAILQ_EMPTY(_device_list)) {
-- 
1.8.1.4



[dpdk-dev] [PATCH v4 1/4] eal: make the comment more accurate

2016-02-26 Thread Huawei Xie
positive return of rte_eal_pci_probe_one_driver means the driver doesn't support
the device.

Signed-off-by: Huawei Xie 
Acked-by: Yuanhan Liu 
---
 lib/librte_eal/common/eal_common_pci.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_pci.c 
b/lib/librte_eal/common/eal_common_pci.c
index 96d5113..797e7e3 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -204,7 +204,7 @@ rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr, 
struct rte_pci_device *d
/* call the driver devinit() function */
return dr->devinit(dr, dev);
}
-   /* return positive value if driver is not found */
+   /* return positive value if driver doesn't support this device */
return 1;
 }

@@ -259,7 +259,7 @@ rte_eal_pci_detach_dev(struct rte_pci_driver *dr,
return 0;
}

-   /* return positive value if driver is not found */
+   /* return positive value if driver doesn't support this device */
return 1;
 }

@@ -283,7 +283,7 @@ pci_probe_all_drivers(struct rte_pci_device *dev)
/* negative value is an error */
return -1;
if (rc > 0)
-   /* positive value means driver not found */
+   /* positive value means driver doesn't support it */
continue;
return 0;
}
@@ -310,7 +310,7 @@ pci_detach_all_drivers(struct rte_pci_device *dev)
/* negative value is an error */
return -1;
if (rc > 0)
-   /* positive value means driver not found */
+   /* positive value means driver doesn't support it */
continue;
return 0;
}
-- 
1.8.1.4



[dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API

2016-02-26 Thread Olivier MATZ


On 02/26/2016 08:39 AM, Xie, Huawei wrote:
 With 8 mbufs allocated, there is about 6% performance increase using 
 inline.
 With 16 mbufs allocated, we could still observe obvious performance
 difference, though only 1%-2%
> 

> On 2/24/2016 9:23 PM, Ananyev, Konstantin wrote:
>> As you can see right now we have all mbuf alloc/free routines as static 
>> inline.
>> And I think we would like to keep it like that.
>> So why that particular function should be different?
>> After all that function is nothing more than a wrapper 
>> around rte_mempool_get_bulk()  unrolled by 4 loop {rte_pktmbuf_reset()}
>> So unless mempool get/put API would change, I can hardly see there could be 
>> any ABI
>> breakages in future. 
>> About 'real world' performance gain - it was a 'real world' performance 
>> problem,
>> that we tried to solve by introducing that function:
>> http://dpdk.org/ml/archives/dev/2015-May/017633.html
>>
>> And according to the user feedback, it does help:  
>> http://dpdk.org/ml/archives/dev/2016-February/033203.html

For me, there's no doubt this function will help in real world use
cases. That's also true that today most (oh no, all) datapath mbuf
functions are inline. Although I understand Panu's point of view
about the use of inline functions, trying to de-inline some functions
of the mbuf API (and others APIs like mempool or ring) would require
a deep analysis first to check the performance impact. And I think there
would be an impact for most of them.

In this particular case, as the function does bulk allocations, it
probably tempers the cost of the function call, and that's why I
was curious of any comparison with/without inlining. But I'm not
sure having this only function as non-inline makes a lot of sense.

So:
Acked-by: Olivier Matz 



[dpdk-dev] [PATCH v3 01/12] ethdev: add API to query packet type filling info

2016-02-26 Thread Tan, Jianfeng
Hi Konstantin,

On 2/26/2016 1:16 AM, Ananyev, Konstantin wrote:
>
>> -Original Message-
>> From: Tan, Jianfeng
>> Sent: Thursday, February 25, 2016 4:36 PM
>> To: Ananyev, Konstantin; dev at dpdk.org
>> Cc: Zhang, Helin; nelio.laranjeiro at 6wind.com; adrien.mazarguil at 
>> 6wind.com; rahul.lakkireddy at chelsio.com
>> Subject: Re: [PATCH v3 01/12] ethdev: add API to query packet type filling 
>> info
>>
>> Hi Konstantin,
>>
>> On 2/25/2016 11:46 PM, Ananyev, Konstantin wrote:
>>> Hi Jainfeng,
>>>
 Add a new API rte_eth_dev_get_ptype_info to query whether/what packet
 type can be filled by given pmd rx burst function.

 Signed-off-by: Jianfeng Tan 
 ---
lib/librte_ether/rte_ethdev.c | 32 
lib/librte_ether/rte_ethdev.h | 23 +++
2 files changed, 55 insertions(+)

 diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
 index 1257965..b52555b 100644
 --- a/lib/librte_ether/rte_ethdev.c
 +++ b/lib/librte_ether/rte_ethdev.c
 @@ -1576,6 +1576,38 @@ rte_eth_dev_info_get(uint8_t port_id, struct 
 rte_eth_dev_info *dev_info)
dev_info->driver_name = dev->data->drv_name;
}

 +int
 +rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptype_mask,
 + uint32_t **p_ptypes)
 +{
 +  int i, j, ret;
 +  struct rte_eth_dev *dev;
 +  const uint32_t *all_ptypes;
 +
 +  RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
 +  dev = _eth_devices[port_id];
 +  RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_ptype_info_get, -ENOTSUP);
 +  all_ptypes = (*dev->dev_ops->dev_ptype_info_get)(dev);
 +
 +  if (!all_ptypes)
 +  return 0;
 +
 +  for (i = 0, ret = 0; all_ptypes[i] != RTE_PTYPE_UNKNOWN; ++i)
 +  if (all_ptypes[i] & ptype_mask)
 +  ret++;
 +  if (ret == 0)
 +  return 0;
 +
 +  *p_ptypes = (uint32_t *)malloc(sizeof(uint32_t) * ret);
 +  if (*p_ptypes == NULL)
 +  return -ENOMEM;
>>> I thought we all agreed to follow snprintf()-like logic and avoid any 
>>> memory allocations inside that function.
>>> So why malloc() again?
>>> Konstantin
>>>
>> Sorry for the setback. I still have concerns that snprintf()-like needs
>> to be called twice by an application to get the ptype info. So I write
>> this implementation for you to comment.
>>
>> So what's the reason why we should avoid memory allocations inside that
>> function?
> By the same reason none of other rte_ethdev get_info() style functions
> (rte_eth_dev_info_get, rte_eth_rx_queue_info_get, rte_eth_xstats_get,
> rte_eth_dev_rss_reta_query, etc) allocate space themselves.
> It is a good practice to let user to decide himself how/where to 
> allocate/free a space for that date:
> on a stack, inside a data segment (global variable), on heap (malloc),
> at hugepages via rte_malloc, somewhere else.
>
> BTW, if you had concerns about that approach, why didn't you provide any 
> arguments
> when it was discussed/agreed?
> Instead you came up a month later with same old approach that voids my and 
> other
> reviewers comments and even v2 of your own patch.
> Do you have any good reason for that?
>
> Konstantin
>

That makes sense for me now. Thanks for explanation. Will send out v4 as 
previous discussion result.

I'd like to say sorry for this delayed and wrong way to raise concern. 
Sorry for waste of your time.

Appreciate your comments on this.

Thanks,
Jianfeng


[dpdk-dev] [PATCH v3 0/4] fix the issue that DPDK takes over virtio device blindly

2016-02-26 Thread David Marchand
On Fri, Feb 26, 2016 at 7:09 AM, Xie, Huawei  wrote:
> On 2/24/2016 8:45 PM, Thomas Monjalon wrote:
>>> Huawei Xie (4):
>>>   eal: make the comment more accurate
>>>   eal: set kdrv to RTE_KDRV_NONE if kernel driver isn't manipulating the 
>>> device.
>>>   virtio: return 1 to tell the kernel we don't take over this device
>>>   virtio: check if kernel driver is manipulating the virtio device
>> The virtio PCI code has been refactored.
>> Please Huawei, would it be possible to rebase on master?
>
> OK. Since IO port map is moved to EAL layer, it is not straightforward
> like before for virtio PMD to distinguish the reason why port map fails.
> We have two choices. Return 1 to the upper layer to say that we don't
> take over the device for all the map failures or we check the driver
> type, return -1 for UIO/VFIO driver error, return 1 for kernel driver,
> which is a bit overelaborate.

The important thing is to have eal report "none" driver first (your
2nd patch) , then in ioport_map, "none" driver will trigger the x86
special case (see other discussion [1]).
For "uio" drivers, code (when fixed for uio_pci_generic) already does
the right stuff.
"vfio" is handled.
Anything else should fail once we have the "none" driver correctly reported.


What did I miss ?


[1] http://dpdk.org/ml/archives/dev/2016-February/034035.html

-- 
David Marchand


[dpdk-dev] virtio PMD is not working with master version

2016-02-26 Thread David Marchand
On Fri, Feb 26, 2016 at 3:23 AM, Yuanhan Liu
 wrote:
> Mauricio, thanks for the testing and report.
>
> On Thu, Feb 25, 2016 at 02:30:18PM +0100, David Marchand wrote:
>> >From the logs, I would say I broke uio_pci_generic since we are in
>> "uio" case, but uio portio sysfs does not exist.
>> virtio pmd fell back to ioports discovery before my change.
>
> Maybe we can do same?

I suppose, but see below.

>
> ---
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
> b/lib/librte_eal/linuxapp/eal/eal_pci.c
> index 4346973..579731c 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
> @@ -685,12 +685,11 @@ int
>  rte_eal_pci_ioport_map(struct rte_pci_device *dev, int bar,
>struct rte_pci_ioport *p)
>  {
> -   int ret;
> +   int ret = -1;
>
> switch (dev->kdrv) {
>  #ifdef VFIO_PRESENT
> case RTE_KDRV_VFIO:
> -   ret = -1;
> if (pci_vfio_is_enabled())
> ret = pci_vfio_ioport_map(dev, bar, p);
> break;
> @@ -700,14 +699,14 @@ rte_eal_pci_ioport_map(struct rte_pci_device *dev, int 
> bar,
> ret = pci_uio_ioport_map(dev, bar, p);
> break;
> default:
> +   break;
> +   }
> +
>  #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
> -   /* special case for x86 ... */
> +   /* special case for x86 ... */
> +   if (ret)
> ret = pci_ioport_map(dev, bar, p);
> -#else
> -   ret = -1;
>  #endif
> -   break;
> -   }

What if we are supposed to do vfio here, but for some reason init failed ?
Next thing, we will call ioport_read in vfio context, but init went
through the ioports parsing => boom ?

Another issue is that when device is bound to a kernel driver (let's
say virtio-pci here), then init will succeed and pmd will kick in the
device registers.

This special case should really be narrowed down to "uio" and "none"
driver cases.


-- 
David Marchand


[dpdk-dev] [PATCH v4 09/12] pmd/mlx5: add dev_ptype_info_get implementation

2016-02-26 Thread Adrien Mazarguil
Hi Jianfeng,

On Fri, Feb 26, 2016 at 08:09:28AM +0800, Jianfeng Tan wrote:
> Signed-off-by: Jianfeng Tan 
> ---
>  drivers/net/mlx4/mlx4.c|  2 +-
>  drivers/net/mlx5/mlx5.c|  1 +
>  drivers/net/mlx5/mlx5.h|  1 +
>  drivers/net/mlx5/mlx5_ethdev.c | 20 
>  drivers/net/mlx5/mlx5_rxtx.c   |  2 ++
>  5 files changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
> index 85fdebf..58f4e1a 100644
> --- a/drivers/net/mlx4/mlx4.c
> +++ b/drivers/net/mlx4/mlx4.c
> @@ -4269,7 +4269,7 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct 
> rte_eth_dev_info *info)
>   priv_unlock(priv);
>  }
>  
> -static uint32_t *
> +static const uint32_t *
>  mlx4_dev_ptype_info_get(struct rte_eth_dev *dev)
>  {
>   static const uint32_t ptypes[] = {

I'm probably nitpicking here but this change should be merged in the mlx4
patch. Otherwise both mlx4 and mlx5 patches look fine to me.

-- 
Adrien Mazarguil
6WIND


[dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding

2016-02-26 Thread Wang, Xiao W
Hi,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, February 26, 2016 5:06 PM
> To: Wang, Xiao W 
> Cc: Richardson, Bruce ; Chen, Jing D
> ; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
> 
> 2016-02-26 04:31, Wang, Xiao W:
> > From: Richardson, Bruce
> > > On Thu, Feb 25, 2016 at 03:45:45PM +, Chen, Jing D wrote:
> > > > From: Richardson, Bruce
> > > > > On Thu, Feb 25, 2016 at 10:04:02AM +, Chen, Jing D wrote:
> > > > > > This feature is trying to use FTAG (a unique tech in fm10k)
> > > > > > instead of mac/vlan to forward packets. App need a way to tell
> > > > > > PMD driver that which forwarding style it would like to use.
> > > > >
> > > > > Why not just specify this in the port configuration at setup time?
> > > > >
> > > >
> > > > Please educate me. I think the port configuration flags are also
> > > > common to all PMD Drivers. Is it possible to add a flag like
> "RTE_USE_FTAG"
> > > and pass to PMD driver?
> > > >
> > > They are.
> > > For something PMD specific, like FTAG, it's always a challenge, and
> > > I don't know off the top of my head if there is a simple option.
> > > However, given the choice between an mbuf flag and a port config
> > > flag, I'd always choose the former.
> > > Other alternatives would be to have a fm10k specific API in the
> > > fm10k driver alone.
> > >
> > > I'll let Thomas as ethdev maintainer comment if he has other
> > > suggestions as to how to handle this case. I suspect this won't be
> > > the first device-specific piece of functionality we need to deal with.
> > >
> > > /Bruce
> >
> > Whatever method we choose, we have to find a way for the user to
> > express his need for FTAG, it maybe a build time config option, or a
> > port config flag (no such flag now), or a fast path flag in mbuf (no
> > such flag now) etc. For the customer Topsec's use case, they use FTAG
> > for all the TX packets, so all the above methods (per build config,
> > per port config, per mbuf config) can meet their need. Since the pmd
> > frame work is for common, it's hard to add new fields only for one specific
> NIC, so I add a build time config and make an introduction in the doc.
> >
> > Thanks for the discussion, Thomas, do you have any suggestions?
> 
> I don't understand why you say this feature is specific to fm10k. Can we
> imagine another NIC having this capability?

As you know, fm10k has a switch logic between the Mac and Phy, every packets
Sent out from the host will be switched inside the NIC, other NICs don't have
a switch inside, and the FTAG feature is related to the switch function.

As introduced in the second patch:
The FM10K family of NICs support the addition of a Fabric Tag (FTAG) to carry
special information. The FTAG is placed at the beginning of the frame, it 
contains
information such as where the packet comes from and goes, and the vlan tag. In
FTAG based forwarding mode, the switch logic forwards packets according to
glort (global resource tag) information, rather than the mac and vlan table.
So this is a feature specific to fm10k.

Best Regards,
Xiao
> I think it must be an port configuration, as Bruce suggested.
> What about a field in struct rte_eth_conf?


[dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API

2016-02-26 Thread Xie, Huawei
On 2/26/2016 4:56 PM, Olivier MATZ wrote:
>
> On 02/23/2016 06:35 AM, Xie, Huawei wrote:
 Also, it would be nice to have a simple test function in
 app/test/test_mbuf.c. For instance, you could update
 test_one_pktmbuf() to take a mbuf pointer as a parameter and remove
 the mbuf allocation from the function. Then it could be called with
 a mbuf allocated with rte_pktmbuf_alloc() (like before) and with
 all the mbufs of rte_pktmbuf_alloc_bulk().
>> Don't quite get you. Is it that we write two cases, one case allocate
>> mbuf through rte_pktmbuf_alloc_bulk and one use rte_pktmbuf_alloc? It is
>> good to have. 
> Yes, something like:
>
> test_one_pktmbuf(struct rte_mbuf *m)
> {
>   /* same as before without the allocation/free */
> }
>
> test_pkt_mbuf(void)
> {
>   m = rte_pktmbuf_alloc(pool);
>   test_one_pktmbuf(m);
>   rte_pktmbuf_free(m);
>
>   ret = rte_pktmbuf_alloc_bulk(pool, mtab, BULK_CNT)
>   for (i = 0; i < BULK_CNT; i++) {
>   m = mtab[i];
>   test_one_pktmbuf(m);
>   rte_pktmbuf_free(m);
>   }
> }

This is to test the functionality.
Let us also have the case like the following?
cycles_start = rte_get_timer_cycles();
while(rounds--) {

ret = rte_pktmbuf_alloc_bulk(pool, mtab, BULK_CNT)
for (i = 0; i < BULK_CNT; i++) {
m = mtab[i];
/* some work if needed */
rte_pktmbuf_free(m);
}
}
cycles_end = rte_get_timer_cycles();

to compare with
   cycles_start = rte_get_timer_cycles();
   while(rounds--) {
for (i = 0; i < BULK_CNT; i++)
mtab[i] = rte_pktmbuf_alloc(...);

ret = rte_pktmbuf_alloc_bulk(pool, mtab, BULK_CNT)
for (i = 0; i < BULK_CNT; i++) {
m = mtab[i];
/* some work if needed */
rte_pktmbuf_free(m);
}
}
cycles_end = rte_get_timer_cycles();


>> I could do this after this patch.
> Yes, please.
>
>
> Thanks,
> Olivier
>



[dpdk-dev] [PATCH v3 0/4] fix the issue that DPDK takes over virtio device blindly

2016-02-26 Thread Xie, Huawei
On 2/26/2016 4:41 PM, David Marchand wrote:
> On Fri, Feb 26, 2016 at 7:09 AM, Xie, Huawei  wrote:
>> On 2/24/2016 8:45 PM, Thomas Monjalon wrote:
 Huawei Xie (4):
   eal: make the comment more accurate
   eal: set kdrv to RTE_KDRV_NONE if kernel driver isn't manipulating the 
 device.
   virtio: return 1 to tell the kernel we don't take over this device
   virtio: check if kernel driver is manipulating the virtio device
>>> The virtio PCI code has been refactored.
>>> Please Huawei, would it be possible to rebase on master?
>> OK. Since IO port map is moved to EAL layer, it is not straightforward
>> like before for virtio PMD to distinguish the reason why port map fails.
>> We have two choices. Return 1 to the upper layer to say that we don't
>> take over the device for all the map failures or we check the driver
>> type, return -1 for UIO/VFIO driver error, return 1 for kernel driver,
>> which is a bit overelaborate.
> The important thing is to have eal report "none" driver first (your
> 2nd patch) , then in ioport_map, "none" driver will trigger the x86
> special case (see other discussion [1]).
> For "uio" drivers, code (when fixed for uio_pci_generic) already does
> the right stuff.
> "vfio" is handled.
> Anything else should fail once we have the "none" driver correctly reported.
>

in rte_eal_pci_map_device:
case RTE_KDRV_NONE:
#if defined(RTE_ARCH_X86)
ret = pci_ioport_map(dev, bar, p);
#endif
break;
}


in vtpci_init:
if (legacy_virtio_resource_init(dev, hw) < 0) {
if (dev->kdrv == RTE_KDRV_UNKNOWN) {
PMD_INIT_LOG(INFO,
"skip kernel managed virtio device.");
return 1;
}
return -1;
}


in dev_init
ret = vt_pci_init
if (ret)
return ret
> What did I miss ?
>
>
> [1] http://dpdk.org/ml/archives/dev/2016-February/034035.html
>



[dpdk-dev] virtio PMD is not working with master version

2016-02-26 Thread Xie, Huawei
On 2/26/2016 4:29 PM, David Marchand wrote:
> On Fri, Feb 26, 2016 at 3:23 AM, Yuanhan Liu
>  wrote:
>> Mauricio, thanks for the testing and report.
>>
>> On Thu, Feb 25, 2016 at 02:30:18PM +0100, David Marchand wrote:
>>> >From the logs, I would say I broke uio_pci_generic since we are in
>>> "uio" case, but uio portio sysfs does not exist.
>>> virtio pmd fell back to ioports discovery before my change.
>> Maybe we can do same?
We shouldn't, :). I am now rebasing the patch to fix the issue that
virtio driver takes the virtio device blindly.
With the patch:
 if driver is VFIO/UIO, and errors happens, returns without falling back
to IO port.
 if no any kernel driver is managing the device, try IO port; otherwise
returns 1 to tell the layer we don't take over this device.

> I suppose, but see below.
>
>> ---
>> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
>> b/lib/librte_eal/linuxapp/eal/eal_pci.c
>> index 4346973..579731c 100644
>> --- a/lib/librte_eal/linuxapp/eal/eal_pci.c
>> +++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
>> @@ -685,12 +685,11 @@ int
>>  rte_eal_pci_ioport_map(struct rte_pci_device *dev, int bar,
>>struct rte_pci_ioport *p)
>>  {
>> -   int ret;
>> +   int ret = -1;
>>
>> switch (dev->kdrv) {
>>  #ifdef VFIO_PRESENT
>> case RTE_KDRV_VFIO:
>> -   ret = -1;
>> if (pci_vfio_is_enabled())
>> ret = pci_vfio_ioport_map(dev, bar, p);
>> break;
>> @@ -700,14 +699,14 @@ rte_eal_pci_ioport_map(struct rte_pci_device *dev, int 
>> bar,
>> ret = pci_uio_ioport_map(dev, bar, p);
>> break;
>> default:
>> +   break;
>> +   }
>> +
>>  #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
>> -   /* special case for x86 ... */
>> +   /* special case for x86 ... */
>> +   if (ret)
>> ret = pci_ioport_map(dev, bar, p);
>> -#else
>> -   ret = -1;
>>  #endif
>> -   break;
>> -   }
> What if we are supposed to do vfio here, but for some reason init failed ?
> Next thing, we will call ioport_read in vfio context, but init went
> through the ioports parsing => boom ?
>
> Another issue is that when device is bound to a kernel driver (let's
> say virtio-pci here), then init will succeed and pmd will kick in the
> device registers.
>
> This special case should really be narrowed down to "uio" and "none"
> driver cases.
>
>



[dpdk-dev] [PATCH 0/3] support setting i40e VF MAC address from DPDK host side

2016-02-26 Thread Pei, Yulong
Tested-by: yulong.pei at intel.com

-Original Message-
From: Zhang, Helin 
Sent: Thursday, January 28, 2016 4:40 PM
To: dev at dpdk.org
Cc: Pei, Yulong ; Wu, Jingjing ; Tao, Zhe ; Xu, Qian Q ; Zhang, Helin 
Subject: [PATCH 0/3] support setting i40e VF MAC address from DPDK host side

It adds pre-setting i40e VF MAC addresses from DPDK PF host side, during host 
port initialization, by introduing a new port configuration element. It then 
can pre-set VF MAC addresses before any launching VFs, and the VF MAC addresses 
will not be random each time launching a VF.
There should be no ABI broken, as ABI changes in 'struct rte_eth_conf' has 
already been announced in R2.2.

Helin Zhang (3):
  i40e: add setting VF MAC address in DPDK PF host
  i40evf: use ether interface for validating MAC address
  app/testpmd: set default MAC addresses for each VF

 app/test-pmd/testpmd.c   | 19 +++
 doc/guides/rel_notes/release_2_3.rst |  9 +
 drivers/net/i40e/i40e_ethdev.c   | 21 +
 drivers/net/i40e/i40e_ethdev.h   |  1 +
 drivers/net/i40e/i40e_ethdev_vf.c| 14 +++---
 drivers/net/i40e/i40e_pf.c   |  2 ++
 lib/librte_ether/rte_ethdev.h| 10 ++
 7 files changed, 69 insertions(+), 7 deletions(-)

--
2.5.0



[dpdk-dev] [PATCH 3/8] drivers/net/e1000: Fix missing brackets

2016-02-26 Thread Aaron Conole
Hi Wenzhou,

"Lu, Wenzhuo"  writes:

> Hi Aaron,
>
>
>> -Original Message-
>> From: Aaron Conole [mailto:aconole at redhat.com]
>> Sent: Friday, February 26, 2016 2:49 AM
>> To: dev at dpdk.org
>> Cc: Lu, Wenzhuo; Zhang, Helin; Ananyev, Konstantin; Richardson, Bruce
>> Subject: [PATCH 3/8] drivers/net/e1000: Fix missing brackets
>> 
>> The register read/write mphy functions have misleading whitespace around the
>> locked check. This cleanup merely preserves the existing functionality while
>> improving the ready check.
>> 
>> Signed-off-by: Aaron Conole 
>> ---
>>  drivers/net/e1000/base/e1000_phy.c | 12 ++--
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>> 
>> diff --git a/drivers/net/e1000/base/e1000_phy.c
>> b/drivers/net/e1000/base/e1000_phy.c
>> index d43b7ce..8642d38 100644
>> --- a/drivers/net/e1000/base/e1000_phy.c
>> +++ b/drivers/net/e1000/base/e1000_phy.c
>> @@ -4153,13 +4153,13 @@ s32 e1000_read_phy_reg_mphy(struct e1000_hw
>> *hw, u32 address, u32 *data)
>>  *data = E1000_READ_REG(hw, E1000_MPHY_DATA);
>> 
>>  /* Disable access to mPHY if it was originally disabled */
>> -if (locked)
>> +if (locked) {
>>  ready = e1000_is_mphy_ready(hw);
>>  if (!ready)
>>  return -E1000_ERR_PHY;
>> -E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
>> -E1000_MPHY_DIS_ACCESS);
>> +}
>> 
>> +E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
>> E1000_MPHY_DIS_ACCESS);
>>  return E1000_SUCCESS;
>>  }
>> 
>> @@ -4218,13 +4218,13 @@ s32 e1000_write_phy_reg_mphy(struct e1000_hw
>> *hw, u32 address, u32 data,
>>  E1000_WRITE_REG(hw, E1000_MPHY_DATA, data);
>> 
>>  /* Disable access to mPHY if it was originally disabled */
>> -if (locked)
>> +if (locked) {
>>  ready = e1000_is_mphy_ready(hw);
>>  if (!ready)
>>  return -E1000_ERR_PHY;
>> -E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
>> -E1000_MPHY_DIS_ACCESS);
>> +}
>> 
>> +E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
>> E1000_MPHY_DIS_ACCESS);
>>  return E1000_SUCCESS;
>>  }
>> 
>> --
>> 2.5.0
> Normally we will not maintain the base code. It's just taken from kernel 
> driver.
> Agree with you that the whitespace is misleading. But as it's no real
> impact. I'd like to say not a big deal, better not change it. :)

Thanks for this hint. It turns out my patch is wrong. It should actually
be this (and I've confirmed by looking at the drivers):

diff --git a/drivers/net/e1000/base/e1000_phy.c 
b/drivers/net/e1000/base/e1000_phy.c
index d43b7ce..ad3fd58 100644
--- a/drivers/net/e1000/base/e1000_phy.c
+++ b/drivers/net/e1000/base/e1000_phy.c
@@ -4153,12 +4153,12 @@ s32 e1000_read_phy_reg_mphy(struct e1000_hw *hw, u32 
address, u32 *data)
*data = E1000_READ_REG(hw, E1000_MPHY_DATA);

/* Disable access to mPHY if it was originally disabled */
-   if (locked)
+   if (locked) {
ready = e1000_is_mphy_ready(hw);
if (!ready)
return -E1000_ERR_PHY;
-   E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
-   E1000_MPHY_DIS_ACCESS);
+   E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL, 
E1000_MPHY_DIS_ACCESS);
+   }

return E1000_SUCCESS;
 }
@@ -4218,12 +4218,12 @@ s32 e1000_write_phy_reg_mphy(struct e1000_hw *hw, u32 
address, u32 data,
E1000_WRITE_REG(hw, E1000_MPHY_DATA, data);

/* Disable access to mPHY if it was originally disabled */
-   if (locked)
+   if (locked) {
ready = e1000_is_mphy_ready(hw);
if (!ready)
return -E1000_ERR_PHY;
-   E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
-   E1000_MPHY_DIS_ACCESS);
+   E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL, 
E1000_MPHY_DIS_ACCESS);
+   }

return E1000_SUCCESS;
 }

I will cook up a v2 of this patch if it makes sense. It is a real bug,
so should be fixed.

-Aaron


[dpdk-dev] [PATCH v3 2/2] i40evf: support to report pf reset event

2016-02-26 Thread Zhang, Helin


> -Original Message-
> From: Wu, Jingjing
> Sent: Friday, February 26, 2016 2:52 PM
> To: Richardson, Bruce
> Cc: dev at dpdk.org; Wu, Jingjing; Zhang, Helin; Tao, Zhe
> Subject: [PATCH v3 2/2] i40evf: support to report pf reset event
> 
> When Linux PF and DPDK VF are used for i40e PMD, In case of PF reset,
> interrupt will go via adminq event, VF need be informed the event, a callback
> mechanism is introduced by VF. This will allow VF to invoke callback when 
> reset
> happens.
> Users can register a callback for this interrupt event like:
>   rte_eth_dev_callback_register(portid,
>   RTE_ETH_EVENT_INTR_RESET,
>   reset_event_callback,
>   arg);
> 
> Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 


[dpdk-dev] [PATCH v3 1/2] i40evf: allocate virtchnl cmd buffer for each vf

2016-02-26 Thread Zhang, Helin


> -Original Message-
> From: Wu, Jingjing
> Sent: Friday, February 26, 2016 2:52 PM
> To: Richardson, Bruce
> Cc: dev at dpdk.org; Wu, Jingjing; Zhang, Helin; Tao, Zhe
> Subject: [PATCH v3 1/2] i40evf: allocate virtchnl cmd buffer for each vf
> 
> Currently, i40evf PMD uses a global static buffer to send virtchnl command to
> host driver. It is shared by multi VFs.
> This patch changed to allocate virtchnl cmd buffer for each VF.
> 
> Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 


[dpdk-dev] [PATCH v4 12/12] examples/l3fwd: add option to parse ptype

2016-02-26 Thread Jianfeng Tan
As a example to use ptype info, l3fwd needs firstly to use
rte_eth_dev_get_ptype_info() API to check if device and/or PMD driver will
parse and fill the needed packet type; if not, use the newly added option,
--parse-ptype, to analyze it in the callback softly.

Under the mode of EXACT_MATCH, ip packets with extensions or ip packets
which are neither tcp nor udp cannot work well because it needs the 5
tuples to caculate hash.

Signed-off-by: Jianfeng Tan 
---
 doc/guides/sample_app_ug/l3_forward.rst |   6 +-
 examples/l3fwd/main.c   | 128 
 2 files changed, 133 insertions(+), 1 deletion(-)

diff --git a/doc/guides/sample_app_ug/l3_forward.rst 
b/doc/guides/sample_app_ug/l3_forward.rst
index 4ce734b..e0c22e3 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -93,7 +93,7 @@ The application has a number of command line options:

 .. code-block:: console

-./build/l3fwd [EAL options] -- -p PORTMASK [-P]  
--config(port,queue,lcore)[,(port,queue,lcore)] [--enable-jumbo [--max-pkt-len 
PKTLEN]]  [--no-numa][--hash-entry-num][--ipv6]
+./build/l3fwd [EAL options] -- -p PORTMASK [-P]  
--config(port,queue,lcore)[,(port,queue,lcore)] [--enable-jumbo [--max-pkt-len 
PKTLEN]]  [--no-numa][--hash-entry-num][--ipv6] [--parse-ptype]

 where,

@@ -114,6 +114,8 @@ where,

 *   --ipv6: optional, set it if running ipv6 packets

+*   --parse-ptype: optional, set it if use software way to analyze packet type
+
 For example, consider a dual processor socket platform where cores 0-7 and 
16-23 appear on socket 0, while cores 8-15 and 24-31 appear on socket 1.
 Let's say that the programmer wants to use memory from both NUMA nodes, the 
platform has only two ports, one connected to each NUMA node,
 and the programmer wants to use two cores from each processor socket to do the 
packet processing.
@@ -334,6 +336,8 @@ The key code snippet of simple_ipv4_fwd_4pkts() is shown 
below:

 The simple_ipv6_fwd_4pkts() function is similar to the simple_ipv4_fwd_4pkts() 
function.

+Known issue: IP packets with extensions or IP packets which are not TCP/UDP 
cannot work well with this mode.
+
 Packet Forwarding for LPM-based Lookups
 ~~~

diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 410f72d..738b94a 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -178,6 +178,8 @@ static __m128i val_eth[RTE_MAX_ETHPORTS];
 static uint32_t enabled_port_mask = 0;
 static int promiscuous_on = 0; /**< Ports set in promiscuous mode off by 
default. */
 static int numa_on = 1; /**< NUMA is enabled by default. */
+static int parse_ptype; /**< Parse packet type using rx callback, and */
+   /**< disabled by default */

 #if (APP_LOOKUP_METHOD == APP_LOOKUP_EXACT_MATCH)
 static int ipv6 = 0; /**< ipv6 is false by default. */
@@ -2029,6 +2031,7 @@ parse_eth_dest(const char *optarg)
 #define CMD_LINE_OPT_IPV6 "ipv6"
 #define CMD_LINE_OPT_ENABLE_JUMBO "enable-jumbo"
 #define CMD_LINE_OPT_HASH_ENTRY_NUM "hash-entry-num"
+#define CMD_LINE_OPT_PARSE_PTYPE "parse-ptype"

 /* Parse the argument given in the command line of the application */
 static int
@@ -2045,6 +2048,7 @@ parse_args(int argc, char **argv)
{CMD_LINE_OPT_IPV6, 0, 0, 0},
{CMD_LINE_OPT_ENABLE_JUMBO, 0, 0, 0},
{CMD_LINE_OPT_HASH_ENTRY_NUM, 1, 0, 0},
+   {CMD_LINE_OPT_PARSE_PTYPE, 0, 0, 0},
{NULL, 0, 0, 0}
};

@@ -2132,6 +2136,13 @@ parse_args(int argc, char **argv)
}
}
 #endif
+   if (!strncmp(lgopts[option_index].name,
+CMD_LINE_OPT_PARSE_PTYPE,
+sizeof(CMD_LINE_OPT_PARSE_PTYPE))) {
+   printf("soft parse-ptype is enabled\n");
+   parse_ptype = 1;
+   }
+
break;

default:
@@ -2580,6 +2591,111 @@ signal_handler(int signum)
}
 }

+static int
+check_packet_type_ok(int portid)
+{
+   int i, ret;
+   int ptype_l3_ipv4 = 0, ptype_l3_ipv6 = 0;
+
+   ret = rte_eth_dev_get_ptype_info(portid, RTE_PTYPE_L3_MASK, NULL, 0);
+   if (ret <= 0)
+   return 0;
+
+   uint32_t ptypes[ret];
+   
+   ret = rte_eth_dev_get_ptype_info(portid, RTE_PTYPE_L3_MASK,
+ptypes, ret);
+   /* It is not a perfect pre-check, i.e., IP packets with extension and
+* IP packets which are not TCP/UDP, can pass this check, but cannot
+* work well at the mode of EXACT_MATCH.
+*/
+   for (i = 0; i < ret; ++i) {
+   if (ptypes[i] & RTE_PTYPE_L3_IPV4)
+   ptype_l3_ipv4 = 1;
+   if (ptypes[i] & RTE_PTYPE_L3_IPV6)
+   ptype_l3_ipv6 = 1;

[dpdk-dev] [PATCH v4 11/12] pmd/vmxnet3: add dev_ptype_info_get implementation

2016-02-26 Thread Jianfeng Tan
Signed-off-by: Jianfeng Tan 
---
 drivers/net/vmxnet3/vmxnet3_ethdev.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c 
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index c363bf6..ac120a1 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -86,6 +86,7 @@ static void vmxnet3_dev_stats_get(struct rte_eth_dev *dev,
struct rte_eth_stats *stats);
 static void vmxnet3_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
+static const uint32_t *vmxnet3_dev_ptype_info_get(struct rte_eth_dev *dev);
 static int vmxnet3_dev_vlan_filter_set(struct rte_eth_dev *dev,
   uint16_t vid, int on);
 static void vmxnet3_dev_vlan_offload_set(struct rte_eth_dev *dev, int mask);
@@ -118,6 +119,7 @@ static const struct eth_dev_ops vmxnet3_eth_dev_ops = {
.link_update  = vmxnet3_dev_link_update,
.stats_get= vmxnet3_dev_stats_get,
.dev_infos_get= vmxnet3_dev_info_get,
+   .dev_ptype_info_get   = vmxnet3_dev_ptype_info_get,
.vlan_filter_set  = vmxnet3_dev_vlan_filter_set,
.vlan_offload_set = vmxnet3_dev_vlan_offload_set,
.rx_queue_setup   = vmxnet3_dev_rx_queue_setup,
@@ -718,6 +720,20 @@ vmxnet3_dev_info_get(__attribute__((unused))struct 
rte_eth_dev *dev, struct rte_
};
 }

+static const uint32_t *
+vmxnet3_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+   static const uint32_t ptypes[] = {
+   RTE_PTYPE_L3_IPV4_EXT,
+   RTE_PTYPE_L3_IPV4,
+   RTE_PTYPE_UNKNOWN
+   };
+
+   if (dev->rx_pkt_burst == vmxnet3_recv_pkts)
+   return ptypes;
+   return NULL;
+}
+
 /* return 0 means link status changed, -1 means not changed */
 static int
 vmxnet3_dev_link_update(struct rte_eth_dev *dev, __attribute__((unused)) int 
wait_to_complete)
-- 
2.1.4



[dpdk-dev] [PATCH v4 10/12] pmd/nfp: add dev_ptype_info_get implementation

2016-02-26 Thread Jianfeng Tan
Signed-off-by: Jianfeng Tan 
---
 drivers/net/nfp/nfp_net.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index fd4dd39..5894a9d 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -1073,6 +1073,24 @@ nfp_net_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->hash_key_size = NFP_NET_CFG_RSS_KEY_SZ;
 }

+static const uint32_t *
+nfp_net_ptype_info_get(struct rte_eth_dev *dev)
+{
+   static const uint32_t ptypes[] = {
+   /* refers to nfp_net_set_hash() */
+   RTE_PTYPE_INNER_L3_IPV4,
+   RTE_PTYPE_INNER_L3_IPV6,
+   RTE_PTYPE_INNER_L3_IPV6_EXT,
+   RTE_PTYPE_INNER_L4_MASK,
+   RTE_PTYPE_UNKNOWN
+   };
+
+
+   if (dev->rx_pkt_burst == nfp_net_recv_pkts)
+   return ptypes;
+   return num;
+}
+
 static uint32_t
 nfp_net_rx_queue_count(struct rte_eth_dev *dev, uint16_t queue_idx)
 {
@@ -2292,6 +2310,7 @@ static struct eth_dev_ops nfp_net_eth_dev_ops = {
.stats_get  = nfp_net_stats_get,
.stats_reset= nfp_net_stats_reset,
.dev_infos_get  = nfp_net_infos_get,
+   .dev_ptype_info_get = nfp_net_ptype_info_get,
.mtu_set= nfp_net_dev_mtu_set,
.vlan_offload_set   = nfp_net_vlan_offload_set,
.reta_update= nfp_net_reta_update,
-- 
2.1.4



[dpdk-dev] [PATCH v4 09/12] pmd/mlx5: add dev_ptype_info_get implementation

2016-02-26 Thread Jianfeng Tan
Signed-off-by: Jianfeng Tan 
---
 drivers/net/mlx4/mlx4.c|  2 +-
 drivers/net/mlx5/mlx5.c|  1 +
 drivers/net/mlx5/mlx5.h|  1 +
 drivers/net/mlx5/mlx5_ethdev.c | 20 
 drivers/net/mlx5/mlx5_rxtx.c   |  2 ++
 5 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 85fdebf..58f4e1a 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -4269,7 +4269,7 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
priv_unlock(priv);
 }

-static uint32_t *
+static const uint32_t *
 mlx4_dev_ptype_info_get(struct rte_eth_dev *dev)
 {
static const uint32_t ptypes[] = {
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 821ee0f..e18b1e9 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -153,6 +153,7 @@ static const struct eth_dev_ops mlx5_dev_ops = {
.stats_get = mlx5_stats_get,
.stats_reset = mlx5_stats_reset,
.dev_infos_get = mlx5_dev_infos_get,
+   .dev_ptype_info_get = mlx5_dev_ptype_info_get,
.vlan_filter_set = mlx5_vlan_filter_set,
.rx_queue_setup = mlx5_rx_queue_setup,
.tx_queue_setup = mlx5_tx_queue_setup,
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index b84d31d..196435d 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -156,6 +156,7 @@ int priv_get_mtu(struct priv *, uint16_t *);
 int priv_set_flags(struct priv *, unsigned int, unsigned int);
 int mlx5_dev_configure(struct rte_eth_dev *);
 void mlx5_dev_infos_get(struct rte_eth_dev *, struct rte_eth_dev_info *);
+const uint32_t *mlx5_dev_ptype_info_get(struct rte_eth_dev *dev);
 int mlx5_link_update(struct rte_eth_dev *, int);
 int mlx5_dev_set_mtu(struct rte_eth_dev *, uint16_t);
 int mlx5_dev_get_flow_ctrl(struct rte_eth_dev *, struct rte_eth_fc_conf *);
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 1159fa3..406f8dc 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -526,6 +526,26 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
priv_unlock(priv);
 }

+const uint32_t *
+mlx5_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+   static const uint32_t ptypes[] = {
+   /* refers to rxq_cq_to_pkt_type() */
+   RTE_PTYPE_L3_IPV4,
+   RTE_PTYPE_L3_IPV6,
+   RTE_PTYPE_INNER_L3_IPV4,
+   RTE_PTYPE_INNER_L3_IPV6,
+   RTE_PTYPE_UNKNOWN
+
+   };
+
+   if (dev->rx_pkt_burst == mlx5_rx_burst ||
+   dev->rx_pkt_burst == mlx5_rx_burst_sp)
+   return ptypes;
+   return NULL;
+
+}
+
 /**
  * DPDK callback to retrieve physical link information (unlocked version).
  *
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index fa5e648..79bdf8d 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -603,6 +603,8 @@ stop:
  * @param flags
  *   RX completion flags returned by poll_length_flags().
  *
+ * @note: fix mlx5_dev_ptype_info_get() if any change here.
+ *
  * @return
  *   Packet type for struct rte_mbuf.
  */
-- 
2.1.4



  1   2   >