[dpdk-dev] Memory Pinning.

[Alex Markuze]

On Mon, Jun 30, 2014 at 7:55 PM, Richardson, Bruce <
bruce.richardson at intel.com> wrote:

> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alex Markuze
> > Sent: Monday, June 30, 2014 3:01 AM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] Memory Pinning.
> >
> > Hi, Guys.
> > I have several newbie questions about the DPDK design I was hoping some
> one
> > could answer.
> >
> > Both in the RX and TX flow, the Buffer Memory must be pinned and not
> > swappable.
> > In RDMA, memory is explicitly registered and made pinned (to the limit
> > defined @ /etc/security/limits.conf) .With regular sockets/kernel driver
> > the NIC DMA's the buffer from/to the kernel which are by definition un
> > swappable.
> >
> > So I'm guessing that at least the TX/RX buffers are mapped to kernel
> space.
> >
> > My questions are 1. How are the buffers made unswappable ? Are they
> shared
> > with the kernel 2. When and Which buffers are mapped/unmapped to the
> kernel
> > space. 3. When are the buffers DMA mapped and by whom?
>
> The memory used is all hugepage memory and as such is not swappable by the
> kernel, so remains in place for the duration of the application. At
> initialization time, we query from the kernel via /proc the physical
> address of the pages being used, and when sending buffers to the NIC we use
> those physical addresses directly.
>
>Thanks for the clarification, the actual physical memory can be used in
the write descriptor only when the iova is the same as the physical
address.  When IOMMU is enabled which AFAIK is enabled with deferred
protection by default (intel_iommu=on) , each device will have its own
notion of the iova (which can actually used for the DMA op) for the same
physical address.

So how does DPDK handle IOMMU currently?

> >
> > And another "bonus" Question. On TX flow I didn't find a way to receive a
> > send completion.
> > So how Can I know when its safe to modify the sent buffers (besides of
> > waiting for the ring buffer to complete a full circle)?
>
> This will depend upon the configuration of the NIC on TX. By default when
> using the fast-path we have the NIC only write-back confirmation of a
> packet being sent every 32 packets. You can poll the ring for this
> notification and which point you know all previous packets have been sent.
> If you want to know on a per-packet basis as soon as the packet is sent,
> you'll need to change the write-back threshold to write back every packet.
> That will impact performance, though. Note, too, that there are no APIs
> right now to query if a particular packet is sent, so you will have to
> write the code to scan the TX rings directly yourself.
>
> /Bruce
>

[dpdk-dev] [PATCH] app/test: Removed vdev test in EAL flags unit test

[Olivier MATZ]

Hi Pablo,

On 06/30/2014 04:42 PM, Pablo de Lara wrote:
> From: Pablo de Lara 
>
> In whitelist test, within EAL flags unit test, vdev flag
> was being tested, but test fails, as a secondary process
> cannot allocate memzones, so it cannot create the device
> and application exits. Also, this can be tested in ring
> pmd test, which needs vdev and not in whitelist, which
> should only test --pci-whitelist.
>
> Patch "app/test: fix build switches to enable cmdline tests"
> from Thomas Monjalon is needed for this patch.
>
> Signed-off-by: Pablo de Lara 

If the test cannot success because it is started from a secondary
process, do you think it is possible to do it with a primary process?

I did a quick test and it works (see my patch in the same thread), but
as I'm not really familiar with this part of the code, I may have
forgotten something.

Regards,
Olivier

[dpdk-dev] [PATCH] app/test: fix vdev test in test_eal_flags

[Olivier Matz]

In whitelist test, within EAL flags unit test, the vdev flag test fails
because it is started in a secondary process, which is not able to
allocate memzones and this is required to instanciate a pmd_ring.

This patch changes the vdev flag test to run it in a primary process.

Patch "app/test: fix build switches to enable cmdline tests"
from Thomas Monjalon is needed for this patch.

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

diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
index 1b80b80..ca47bb2 100644
--- a/app/test/test_eal_flags.c
+++ b/app/test/test_eal_flags.c
@@ -59,6 +59,7 @@
 #define no_shconf "--no-shconf"
 #define pci_whitelist "--pci-whitelist"
 #define vdev "--vdev"
+#define whitelist_prefix "whitelist"
 #define memtest "memtest"
 #define memtest1 "memtest1"
 #define memtest2 "memtest2"
@@ -314,7 +315,8 @@ test_whitelist_flag(void)
pci_whitelist, "00FF:09:0B.3"};
const char *wlval2[] = {prgname, prefix, mp_flag, "-n", "1", "-c", "1",
pci_whitelist, "09:0B.3", pci_whitelist, "0a:0b.1"};
-   const char *wlval3[] = {prgname, prefix, mp_flag, "-n", "1", "-c", "1",
+   const char *wlval3[] = {prgname, "--prefix=" whitelist_prefix,
+   "-n", "1", "-c", "1",
pci_whitelist, "09:0B.3,type=test",
pci_whitelist, "08:00.1,type=normal",
 #ifdef RTE_LIBRTE_PMD_RING
-- 
1.9.2

[dpdk-dev] [PATCH] test: Remove NULL snprintf tests in cmdline unit test

[Cao, Waterman]

Tested-by: Waterman Cao 

This patch updated Cmdline unit test, and is ready to integrate into DPDK.org.

[dpdk-dev] Ability to/impact of running with smaller page sizes

[Liu, Jijiang]

Hi Matt,

On Mon, Jun 30, 2014 at 05:43:39PM -0500, Matt Laswell wrote:
> Hey Folks,
> 
> In my application, I'm seeing some design considerations in a project 
> I'm working on that push me towards the use of smaller memory page 
> sizes.  I'm curious - is it possible in practical terms to run DPDK without 
> hugepages?

>  If so, does anybody have any practical experience (or a 
> back-of-the-envelop estimate) of how badly such a configuration would 
> hurt performance?  For sake of argument, assume that virtually all of 
> the memory being used is in pre-allocated mempools (e.g lots of 
> rte_mempool_create(), very little rte_malloc().
> 

There is an case to run DPDK without hugepages in DPDK source codes, which is 
DPDK supports Xen Dom0. for this, we developed a dom0_mm driver. 
Except for Xen Dom0, it is impossible to run DPDK without hugepages without any 
changes at memory initialization phase, but current 
rte_memzone_reserve_bounded() and 
rte_mempool_xmem_create()  implemention have already support non-hugepage usage 
in DPDK.



Thanks,
Jeff

[dpdk-dev] [PATCH] app/test: Removed vdev test in EAL flags unit test

[De Lara Guarch, Pablo]

Hi Olivier,

> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Tuesday, July 01, 2014 9:31 AM
> To: De Lara Guarch, Pablo; dev at dpdk.org
> Cc: Olivier MATZ
> Subject: Re: [dpdk-dev] [PATCH] app/test: Removed vdev test in EAL flags
> unit test
> 
> Hi Pablo,
> 
> On 06/30/2014 04:42 PM, Pablo de Lara wrote:
> > From: Pablo de Lara 
> >
> > In whitelist test, within EAL flags unit test, vdev flag
> > was being tested, but test fails, as a secondary process
> > cannot allocate memzones, so it cannot create the device
> > and application exits. Also, this can be tested in ring
> > pmd test, which needs vdev and not in whitelist, which
> > should only test --pci-whitelist.
> >
> > Patch "app/test: fix build switches to enable cmdline tests"
> > from Thomas Monjalon is needed for this patch.
> >
> > Signed-off-by: Pablo de Lara 
> 
> If the test cannot success because it is started from a secondary
> process, do you think it is possible to do it with a primary process?
> 
> I did a quick test and it works (see my patch in the same thread), but
> as I'm not really familiar with this part of the code, I may have
> forgotten something.
> 
> Regards,
> Olivier

I checked your patch, and I got this:

...

EAL: Detected lcore 38 as core 11 on socket 1
EAL: Detected lcore 39 as core 12 on socket 1
EAL: Support maximum 64 logical core(s) by configuration.
EAL: Detected 40 lcore(s)
./x86_64-native-linuxapp-gcc/app/test: unrecognized option '--prefix=whitelist'

Also, I thought we could not run two primary process at the same time 
(considering that the test app is a primary process).

Thanks,
Pablo

[dpdk-dev] [PATCH] app/test: Removed vdev test in EAL flags unit test

[Olivier MATZ]

Hi Pablo,

On 07/01/2014 10:59 AM, De Lara Guarch, Pablo wrote:
> I checked your patch, and I got this:
>
> ...
>
> EAL: Detected lcore 38 as core 11 on socket 1
> EAL: Detected lcore 39 as core 12 on socket 1
> EAL: Support maximum 64 logical core(s) by configuration.
> EAL: Detected 40 lcore(s)
> ./x86_64-native-linuxapp-gcc/app/test: unrecognized option 
> '--prefix=whitelist'

I'm sorry, I cleaned the patch without retesting it, and I
introduced a bug in it (--prefix instead of --file-prefix).

Please find the new one as a reply to this mail.
When I test it, I get:

[...]
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x2aaba4c0 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x2aaba4e0 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x2aaba500 (size = 0x20)
EAL: Requesting 984 pages of size 2MB from socket 0
EAL: Requesting 1000 pages of size 2MB from socket 1
EAL: TSC frequency is ~293 KHz
EAL: Master core 0 is ready (tid=ab9044e0)
PMD: Initializing pmd_ring for eth_ring
PMD: Error parsing device, invalid key 
PMD: Ignoring unsupported parameters when creating rings-backed ethernet 
device
PMD: Creating rings-backed ethdev on numa socket 0

> Also, I thought we could not run two primary process at the same time
> (considering that the test app is a primary process).

Some other tests in the same file launch a primary process,
I suppose it should work if the prefix for huge-pages is different.

Regards,
Olivier

[dpdk-dev] [PATCH v2] app/test: fix vdev test in test_eal_flags

[Olivier Matz]

In whitelist test, within EAL flags unit test, the vdev flag test fails
because it is started in a secondary process, which is not able to
allocate memzones and this is required to instanciate a pmd_ring.

This patch changes the vdev flag test to run it in a primary process.

Patch "app/test: fix build switches to enable cmdline tests"
from Thomas Monjalon is needed for this patch.

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

diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
index 1b80b80..4a50d37 100644
--- a/app/test/test_eal_flags.c
+++ b/app/test/test_eal_flags.c
@@ -59,6 +59,7 @@
 #define no_shconf "--no-shconf"
 #define pci_whitelist "--pci-whitelist"
 #define vdev "--vdev"
+#define whitelist_prefix "whitelist"
 #define memtest "memtest"
 #define memtest1 "memtest1"
 #define memtest2 "memtest2"
@@ -314,7 +315,8 @@ test_whitelist_flag(void)
pci_whitelist, "00FF:09:0B.3"};
const char *wlval2[] = {prgname, prefix, mp_flag, "-n", "1", "-c", "1",
pci_whitelist, "09:0B.3", pci_whitelist, "0a:0b.1"};
-   const char *wlval3[] = {prgname, prefix, mp_flag, "-n", "1", "-c", "1",
+   const char *wlval3[] = {prgname, "--file-prefix=" whitelist_prefix,
+   "-n", "1", "-c", "1",
pci_whitelist, "09:0B.3,type=test",
pci_whitelist, "08:00.1,type=normal",
 #ifdef RTE_LIBRTE_PMD_RING
-- 
1.9.2

[dpdk-dev] Ability to/impact of running with smaller page sizes

[Ananyev, Konstantin]

Hi,

> Hi Matt,
> 
> On Mon, Jun 30, 2014 at 05:43:39PM -0500, Matt Laswell wrote:
> > Hey Folks,
> >
> > In my application, I'm seeing some design considerations in a project
> > I'm working on that push me towards the use of smaller memory page
> > sizes.  I'm curious - is it possible in practical terms to run DPDK without 
> > hugepages?
> 
> >  If so, does anybody have any practical experience (or a
> > back-of-the-envelop estimate) of how badly such a configuration would
> > hurt performance?  For sake of argument, assume that virtually all of
> > the memory being used is in pre-allocated mempools (e.g lots of
> > rte_mempool_create(), very little rte_malloc().
> >
> 
> There is an case to run DPDK without hugepages in DPDK source codes, which is 
> DPDK supports Xen Dom0. for this, we developed a
> dom0_mm driver.
> Except for Xen Dom0, it is impossible to run DPDK without hugepages without 
> any changes at memory initialization phase, but current
> rte_memzone_reserve_bounded() and
> rte_mempool_xmem_create()  implemention have already support non-hugepage 
> usage in DPDK.
> 

On linux testpmd can run with mempool on 4K pages (though RX/TX HW rings are 
still on hugepages).
To try it add "--mp-anon" to your testpmd command-line.
Also to get a more 'real' picture you can disable MP caching: "--mbcache=0".   

Konstantin

[dpdk-dev] [PATCH v2] app/test: fix vdev test in test_eal_flags

[De Lara Guarch, Pablo]

Hi Olivier,

> -Original Message-
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Tuesday, July 01, 2014 10:21 AM
> To: dev at dpdk.org; De Lara Guarch, Pablo
> Cc: olivier.matz at 6wind.com
> Subject: [PATCH v2] app/test: fix vdev test in test_eal_flags
> 
> In whitelist test, within EAL flags unit test, the vdev flag test fails
> because it is started in a secondary process, which is not able to
> allocate memzones and this is required to instanciate a pmd_ring.
> 
> This patch changes the vdev flag test to run it in a primary process.
> 
> Patch "app/test: fix build switches to enable cmdline tests"
> from Thomas Monjalon is needed for this patch.
> 
> Signed-off-by: Olivier Matz 
> ---
>  app/test/test_eal_flags.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
> index 1b80b80..4a50d37 100644
> --- a/app/test/test_eal_flags.c
> +++ b/app/test/test_eal_flags.c
> @@ -59,6 +59,7 @@
>  #define no_shconf "--no-shconf"
>  #define pci_whitelist "--pci-whitelist"
>  #define vdev "--vdev"
> +#define whitelist_prefix "whitelist"
>  #define memtest "memtest"
>  #define memtest1 "memtest1"
>  #define memtest2 "memtest2"
> @@ -314,7 +315,8 @@ test_whitelist_flag(void)
>   pci_whitelist, "00FF:09:0B.3"};
>   const char *wlval2[] = {prgname, prefix, mp_flag, "-n", "1", "-c", "1",
>   pci_whitelist, "09:0B.3", pci_whitelist, "0a:0b.1"};
> - const char *wlval3[] = {prgname, prefix, mp_flag, "-n", "1", "-c", "1",
> + const char *wlval3[] = {prgname, "--file-prefix=" whitelist_prefix,
> + "-n", "1", "-c", "1",
>   pci_whitelist, "09:0B.3,type=test",
>   pci_whitelist, "08:00.1,type=normal",
>  #ifdef RTE_LIBRTE_PMD_RING
> --
> 1.9.2

Thanks for this. It works fine :) Actually, I am thinking of creating a 
separate test
for vdev, out of whitelist test, as it has no relation with it. Do you agree on 
this?
Thanks,
Pablo

[dpdk-dev] Ability to/impact of running with smaller page sizes

[Burakov, Anatoly]

Hi Matt,

> I'm curious - is it possible in practical terms to run DPDK without hugepages?

Starting with release 1.7.0, support for VFIO was added, which allows using  
DPDK without hugepages at al (including RX/TX rings) via the --no-huge 
command-line parameter. Bear in mind though that you'll have to have IOMMU/VT-d 
enabled (i.e. no VM support, only host-based) and also have supported kernel 
version (3.6+) as well to use VFIO, the memory size will be limited to 1G, and 
it won't work with multiprocess. I don't have any performance figures on that 
unfortunately.

Best regards,
Anatoly Burakov
DPDK SW Engineer

[dpdk-dev] [PATCH v2] app/test: fix vdev test in test_eal_flags

[Olivier MATZ]

Hi Pablo,

On 07/01/2014 01:44 PM, De Lara Guarch, Pablo wrote:
> Thanks for this. It works fine :)

Thanks for testing!

> Actually, I am thinking of creating a separate test
> for vdev, out of whitelist test, as it has no relation with it. Do you agree 
> on this?

I have no problem with that, it makes sense. Just to confirm: it means
that Thomas should not apply our previous patches from this thread and
wait for your next one, right?

Regards,
Olivier

[dpdk-dev] [PATCH v2] app/test: fix vdev test in test_eal_flags

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> Sent: Tuesday, July 01, 2014 1:01 PM
> To: De Lara Guarch, Pablo; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] app/test: fix vdev test in test_eal_flags
> 
> Hi Pablo,
> 
> On 07/01/2014 01:44 PM, De Lara Guarch, Pablo wrote:
> > Thanks for this. It works fine :)
> 
> Thanks for testing!
> 
> > Actually, I am thinking of creating a separate test
> > for vdev, out of whitelist test, as it has no relation with it. Do you 
> > agree on
> this?
> 
> I have no problem with that, it makes sense. Just to confirm: it means
> that Thomas should not apply our previous patches from this thread and
> wait for your next one, right?

That's it :)

> 
> Regards,
> Olivier

Thanks,
Pablo

[dpdk-dev] Ability to/impact of running with smaller page sizes

[Matt Laswell]

Thanks everybody,

It sounds as though what I'm looking for may be possible, especially with
1.7, but will require some tweaking and there will most definitely be a
performance hit.  That's great information.  This is still just an
experiment for us, and it's not at all guaranteed that I'm going to move
towards smaller pages, but I very much appreciate the insights.

--
Matt Laswell


On Tue, Jul 1, 2014 at 6:51 AM, Burakov, Anatoly 
wrote:

> Hi Matt,
>
> > I'm curious - is it possible in practical terms to run DPDK without
> hugepages?
>
> Starting with release 1.7.0, support for VFIO was added, which allows
> using  DPDK without hugepages at al (including RX/TX rings) via the
> --no-huge command-line parameter. Bear in mind though that you'll have to
> have IOMMU/VT-d enabled (i.e. no VM support, only host-based) and also have
> supported kernel version (3.6+) as well to use VFIO, the memory size will
> be limited to 1G, and it won't work with multiprocess. I don't have any
> performance figures on that unfortunately.
>
> Best regards,
> Anatoly Burakov
> DPDK SW Engineer
>

[dpdk-dev] [PATCH] kni: allow setting KNI device MAC address

[Padam Jeet Singh]

Added relevant callback function to change a KNI device's MAC address

Signed-off-by: Padam Jeet Singh 
---
 lib/librte_eal/linuxapp/kni/kni_net.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/lib/librte_eal/linuxapp/kni/kni_net.c 
b/lib/librte_eal/linuxapp/kni/kni_net.c
index d3c0190..15e81c1 100644
--- a/lib/librte_eal/linuxapp/kni/kni_net.c
+++ b/lib/librte_eal/linuxapp/kni/kni_net.c
@@ -612,6 +612,21 @@ kni_net_rebuild_header(struct sk_buff *skb)
return 0;
 }

+/**
+ * kni_net_set_mac - Change the Ethernet Address of the KNI NIC
+ * @netdev: network interface device structure
+ * @p: pointer to an address structure
+ *
+ * Returns 0 on success, negative on failure
+ **/
+static int kni_net_set_mac(struct net_device *netdev, void *p)
+{
+   struct sockaddr *addr = p;
+   if (!is_valid_ether_addr((unsigned char *)(addr->sa_data)))
+   return -EADDRNOTAVAIL;
+   memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
+   return 0;
+}

 static const struct header_ops kni_net_header_ops = {
.create  = kni_net_header,
@@ -628,6 +643,7 @@ static const struct net_device_ops kni_net_netdev_ops = {
.ndo_do_ioctl = kni_net_ioctl,
.ndo_get_stats = kni_net_stats,
.ndo_tx_timeout = kni_net_tx_timeout,
+   .ndo_set_mac_address = kni_net_set_mac,
 };

 void
-- 
1.8.5.2 (Apple Git-48)

[dpdk-dev] [PATCH v11 1/5] bond: new link bonding library

[Thomas Monjalon]

Hi Declan,

Do you confirm we should merge the Robert's patch in rc3?

2014-06-30 18:29, Robert Sanford:
> I see a potential problem with bond_ethdev_rx_burst( ).
> We could receive more packets than the caller asked for, and overrun the
> caller's rte_mbuf * array.
> The fix could be something like this:
> 
> --- a/lib/librte_pmd_bond/rte_eth_bond_pmd.c
> +++ b/lib/librte_pmd_bond/rte_eth_bond_pmd.c
> @@ -73,13 +73,15 @@ bond_ethdev_rx_burst(void *queue, struct rte_mbuf
> **bufs, uint16_t nb_pkts)
> case BONDING_MODE_ROUND_ROBIN:
> case BONDING_MODE_BROADCAST:
> case BONDING_MODE_BALANCE:
> -   for (i = 0; i < internals->active_slave_count; i++) {
> +   for (i = 0; i < internals->active_slave_count && nb_pkts;
> i++) {
> /* Offset of pointer to *bufs increases as packets
> are received
>  * from other slaves */
> num_rx_slave =
> rte_eth_rx_burst(internals->active_slaves[i],
> bd_rx_q->queue_id, bufs +
> num_rx_total, nb_pkts);
> -   if (num_rx_slave)
> +   if (num_rx_slave) {
> num_rx_total += num_rx_slave;
> +   nb_pkts -= num_rx_slave;
> +   }
> }
> break;
> case BONDING_MODE_ACTIVE_BACKUP:

[dpdk-dev] [PATCH v11 1/5] bond: new link bonding library

[Doherty, Declan]

From: Robert Sanford [mailto:rsanfo...@gmail.com]
Sent: Monday, June 30, 2014 11:30 PM
To: Doherty, Declan
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v11 1/5] bond: new link bonding library

Hi Declan,

On Sun, Jun 29, 2014 at 1:49 PM, Declan Doherty mailto:declan.doherty at intel.com>> wrote:
Initial release with support for
 Mode 0 - Round Robin
 Mode 1 - Active Backup
 Mode 2 - Balance -> Supports 3 transmit polices (layer 2, layer 2+3, layer 3+4)
 Mode 3 - Broadcast

Signed-off-by: Declan Doherty mailto:declan.doherty at intel.com>>
---
 config/common_bsdapp   |5 +
 config/common_linuxapp |5 +
 doc/doxy-api-index.md  |1 +
 doc/doxy-api.conf  |1 +
 lib/Makefile   |1 +
 lib/librte_pmd_bond/Makefile   |   61 ++
 lib/librte_pmd_bond/rte_eth_bond.h |  255 ++
 lib/librte_pmd_bond/rte_eth_bond_api.c |  662 +++
 lib/librte_pmd_bond/rte_eth_bond_args.c|  252 ++
 lib/librte_pmd_bond/rte_eth_bond_pmd.c | 1212 
 lib/librte_pmd_bond/rte_eth_bond_private.h |  215 +
 mk/rte.app.mk  |4 +
 12 files changed, 2674 insertions(+), 0 deletions(-)
 create mode 100644 lib/librte_pmd_bond/Makefile
 create mode 100644 lib/librte_pmd_bond/rte_eth_bond.h
 create mode 100644 lib/librte_pmd_bond/rte_eth_bond_api.c
 create mode 100644 lib/librte_pmd_bond/rte_eth_bond_args.c
 create mode 100644 lib/librte_pmd_bond/rte_eth_bond_pmd.c
 create mode 100644 lib/librte_pmd_bond/rte_eth_bond_private.h


I see a potential problem with bond_ethdev_rx_burst( ).
We could receive more packets than the caller asked for, and overrun the 
caller's rte_mbuf * array.
The fix could be something like this:

--- a/lib/librte_pmd_bond/rte_eth_bond_pmd.c
+++ b/lib/librte_pmd_bond/rte_eth_bond_pmd.c
@@ -73,13 +73,15 @@ bond_ethdev_rx_burst(void *queue, struct rte_mbuf **bufs, 
uint16_t nb_pkts)
case BONDING_MODE_ROUND_ROBIN:
case BONDING_MODE_BROADCAST:
case BONDING_MODE_BALANCE:
-   for (i = 0; i < internals->active_slave_count; i++) {
+   for (i = 0; i < internals->active_slave_count && nb_pkts; i++) {
/* Offset of pointer to *bufs increases as packets are 
received
 * from other slaves */
num_rx_slave = 
rte_eth_rx_burst(internals->active_slaves[i],
bd_rx_q->queue_id, bufs + num_rx_total, 
nb_pkts);
-   if (num_rx_slave)
+   if (num_rx_slave) {
num_rx_total += num_rx_slave;
+   nb_pkts -= num_rx_slave;
+   }
}
break;
case BONDING_MODE_ACTIVE_BACKUP:

--
Regards,
Robert


Hi Robert, yes I see this could be an issue, although this currently shouldn?t 
cause an issue, as
the currently supported bonding modes only expected to receive data on one 
slave at any time, if they
are being used as part of a ether channel but when we add further bonding modes 
are which receive
data on multiple slaves this would definitely be a problem.

Thomas, I?ve tested the above changes, is it possible to integrate this patch 
with the patchset for link
bonding for the rc3.

Thanks
Declan

[dpdk-dev] [PATCH v11 1/5] bond: new link bonding library

[Thomas Monjalon]

2014-07-01 14:19, Doherty, Declan:
> Hi Robert, yes I see this could be an issue, although this currently
> shouldn?t cause an issue, as the currently supported bonding modes only
> expected to receive data on one slave at any time, if they are being used
> as part of a ether channel but when we add further bonding modes are which
> receive data on multiple slaves this would definitely be a problem.
> 
> Thomas, I?ve tested the above changes, is it possible to integrate this
> patch with the patchset for link bonding for the rc3.

No problem.
It will be in.

Thanks Declan & Robert
-- 
Thomas

[dpdk-dev] [PATCH] app/test: fix and separate vdev test in test_eal_flags

[Pablo de Lara]

From: Pablo de Lara 

In EAL flags unit test, vdev test was being included
(and broken) in whitelist test. It has been separated
in different test and fixed, by calling another
primary process, instead of a secondary one.

Patch "app/test: fix build switches to enable cmdline tests"
from Thomas Monjalon is needed for this patch.

Signed-off-by: Pablo de Lara 
---
 app/test/test.c   |1 +
 app/test/test_eal_flags.c |   57 ++--
 2 files changed, 55 insertions(+), 3 deletions(-)

diff --git a/app/test/test.c b/app/test/test.c
index 516829d..a41e43d 100644
--- a/app/test/test.c
+++ b/app/test/test.c
@@ -86,6 +86,7 @@ do_recursive_call(void)
{ "test_no_hpet_flag", no_action },
{ "test_whitelist_flag", no_action },
{ "test_invalid_b_flag", no_action },
+   { "test_invalid_vdev_flag", no_action },
{ "test_invalid_r_flag", no_action },
 #ifdef RTE_LIBRTE_XEN_DOM0
{ "test_dom0_misc_flags", no_action },
diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
index 1b80b80..729d4ee 100644
--- a/app/test/test_eal_flags.c
+++ b/app/test/test_eal_flags.c
@@ -317,9 +317,6 @@ test_whitelist_flag(void)
const char *wlval3[] = {prgname, prefix, mp_flag, "-n", "1", "-c", "1",
pci_whitelist, "09:0B.3,type=test",
pci_whitelist, "08:00.1,type=normal",
-#ifdef RTE_LIBRTE_PMD_RING
-   vdev, "eth_ring,arg=test",
-#endif
};

for (i = 0; i < sizeof(wlinval) / sizeof(wlinval[0]); i++) {
@@ -391,6 +388,53 @@ test_invalid_b_flag(void)
return 0;
 }

+/*
+ *  Test that the app doesn't run with invalid vdev option.
+ *  Final test ensures it does run with valid options as sanity check
+ */
+#ifdef RTE_LIBRTE_PMD_RING
+static int
+test_invalid_vdev_flag(void)
+{
+   /* Test with invalid vdev option */
+   const char *vdevinval[] = {prgname, "--file-prefix=vdev","-n", "1",
+   "-c", "1", vdev, "eth_dummy"};
+
+   /* Test with valid vdev option */
+   const char *vdevval1[] = {prgname, "--file-prefix=vdev", "-n", "1",
+   "-c", "1", vdev, "eth_ring0"};
+
+   const char *vdevval2[] = {prgname, "--file-prefix=vdev", "-n", "1",
+   "-c", "1", vdev, "eth_ring0,args=test"};
+
+   const char *vdevval3[] = {prgname, "--file-prefix=vdev", "-n", "1",
+   "-c", "1", vdev, "eth_ring0,nodeaction=r1:0:CREATE"};
+
+   if (launch_proc(vdevinval) == 0) {
+   printf("Error - process did run ok with invalid "
+   "vdev parameter\n");
+   return -1;
+   }
+
+   if (launch_proc(vdevval1) != 0) {
+   printf("Error - process did not run ok with valid vdev 
value\n");
+   return -1;
+   }
+
+   if (launch_proc(vdevval2) != 0) {
+   printf("Error - process did not run ok with valid vdev value,"
+   "with dummy args\n");
+   return -1;
+   }
+
+   if (launch_proc(vdevval3) != 0) {
+   printf("Error - process did not run ok with valid vdev value,"
+   "with valid args\n");
+   return -1;
+   }
+   return 0;
+}
+#endif

 /*
  * Test that the app doesn't run with invalid -r option.
@@ -1201,6 +1245,13 @@ test_eal_flags(void)
return ret;
}

+#ifdef RTE_LIBRTE_PMD_RING
+   ret = test_invalid_vdev_flag();
+   if (ret < 0) {
+   printf("Error in test_invalid_vdev_flag()\n");
+   return ret;
+   }
+#endif
ret = test_invalid_r_flag();
if (ret < 0) {
printf("Error in test_invalid_r_flag()\n");
-- 
1.7.0.7

[dpdk-dev] [PATCH] net: get rid of SET_ETHTOOL_OPS

[Flavio Leitner]

The SET_ETHTOOL_OPS has been removed from upstream, so it
breaks the dpdk build with recent kernels.

Signed-off-by: Flavio Leitner 
---
 lib/librte_eal/linuxapp/kni/ethtool/igb/igb_ethtool.c | 4 ++--
 lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe.h | 1 -
 lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_ethtool.c | 2 +-
 lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c| 2 +-
 lib/librte_eal/linuxapp/kni/kni_ethtool.c | 2 +-
 5 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_ethtool.c 
b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_ethtool.c
index f3c48b2..9a1a177 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_ethtool.c
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_ethtool.c
@@ -2844,14 +2844,14 @@ static const struct ethtool_ops_ext igb_ethtool_ops_ext 
= {

 void igb_set_ethtool_ops(struct net_device *netdev)
 {
-   SET_ETHTOOL_OPS(netdev, &igb_ethtool_ops);
+   netdev->ethtool_ops = &igb_ethtool_ops;
set_ethtool_ops_ext(netdev, &igb_ethtool_ops_ext);
 }
 #else
 void igb_set_ethtool_ops(struct net_device *netdev)
 {
/* have to "undeclare" const on this struct to remove warnings */
-   SET_ETHTOOL_OPS(netdev, (struct ethtool_ops *)&igb_ethtool_ops);
+   netdev->ethtool_ops = (struct ethtool_ops *)&igb_ethtool_ops;
 }
 #endif /* HAVE_RHEL6_ETHTOOL_OPS_EXT_STRUCT */
 #endif /* SIOCETHTOOL */
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe.h 
b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe.h
index 222c2c7..23e2899 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe.h
+++ b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe.h
@@ -818,7 +818,6 @@ extern u8 ixgbe_dcb_txq_to_tc(struct ixgbe_adapter 
*adapter, u8 index);
 /* needed by ixgbe_main.c */
 extern int ixgbe_validate_mac_addr(u8 *mc_addr);
 extern void ixgbe_check_options(struct ixgbe_adapter *adapter);
-extern void ixgbe_assign_netdev_ops(struct net_device *netdev);

 /* needed by ixgbe_ethtool.c */
 extern char ixgbe_driver_name[];
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_ethtool.c 
b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_ethtool.c
index 11472bd..e0802c1 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_ethtool.c
+++ b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_ethtool.c
@@ -2896,6 +2896,6 @@ struct ethtool_ops ixgbe_ethtool_ops = {

 void ixgbe_set_ethtool_ops(struct net_device *netdev)
 {
-   SET_ETHTOOL_OPS(netdev, &ixgbe_ethtool_ops);
+   netdev->ethtool_ops = &ixgbe_ethtool_ops;
 }
 #endif /* SIOCETHTOOL */
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c 
b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
index cb56906..ba2aedb 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
+++ b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
@@ -2454,7 +2454,7 @@ int ixgbe_kni_probe(struct pci_dev *pdev,
err = -EIO;
goto err_ioremap;
}
-   //ixgbe_assign_netdev_ops(netdev);
+
ixgbe_set_ethtool_ops(netdev);

strlcpy(netdev->name, pci_name(pdev), sizeof(netdev->name));
diff --git a/lib/librte_eal/linuxapp/kni/kni_ethtool.c 
b/lib/librte_eal/linuxapp/kni/kni_ethtool.c
index d0673e5..06b6d46 100644
--- a/lib/librte_eal/linuxapp/kni/kni_ethtool.c
+++ b/lib/librte_eal/linuxapp/kni/kni_ethtool.c
@@ -213,5 +213,5 @@ struct ethtool_ops kni_ethtool_ops = {
 void
 kni_set_ethtool_ops(struct net_device *netdev)
 {
-   SET_ETHTOOL_OPS(netdev, &kni_ethtool_ops);
+   netdev->ethtool_ops = &kni_ethtool_ops;
 }
-- 
2.0.0

[dpdk-dev] [dpdk-announce] release candidate 1.7.0-rc3

[Thomas Monjalon]

The third release candidate of version 1.7.0 can be downloaded here:
http://dpdk.org/browse/dpdk/tag/?id=v1.7.0-rc3
Please test it.
It should be the latest release candidate before 1.7.0.

You can check the log here:
http://dpdk.org/browse/dpdk/log
A short changelog will be provided with the release.

Remaining pending patches should go into 1.7.1 or 1.8.0.

Thank you to everyone,
-- 
Thomas