[dpdk-dev] [PATCH] lib/librte_vhost: fix build errors

[Ouyang, Changchun]

On 3/19/2015 6:43 PM, Huawei Xie wrote:
> fix the error "missing initializer" and "cast to pointer from integer of 
> different size".
>
> For the pointer to integer cast issue, need to investigate changing the 
> typeof mapped_address.
>
> Signed-off-by: Huawei Xie 
>
Acted-by: Changchun Ouyang 

[dpdk-dev] [PATCH 2/6] eal: Close file descriptor of uio configuration

[Tetsuya Mukawa]

On 2015/03/19 0:19, David Marchand wrote:
> On Tue, Mar 17, 2015 at 10:30 AM, Tetsuya Mukawa  > wrote:
>
> When pci_uio_unmap_resource() is called, a file descriptor that is
> used
> for uio configuration should be closed.
>
> Signed-off-by: Tetsuya Mukawa  >
> ---
>  lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> index 9cdf24f..b971ec9 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> @@ -459,8 +459,14 @@ pci_uio_unmap_resource(struct rte_pci_device
> *dev)
>
> /* close fd if in primary process */
> close(dev->intr_handle.fd);
> -
> dev->intr_handle.fd = -1;
> +
> +   /* close cfg_fd if in primary process */
>
> +   if (dev->intr_handle.uio_cfg_fd >= 0) {
> +   close(dev->intr_handle.uio_cfg_fd);
> +   dev->intr_handle.uio_cfg_fd = -1;
> +   }
> +
> dev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN;
>  }
>  #endif /* RTE_LIBRTE_EAL_HOTPLUG */
>
>
> Hum, why check for < 0 value ?
> There is no such check for intr_handle.fd and I can see no reason why
> we should behave differently.
>

Hi David,

There is a reason, but 'if-condition' should move to later patch.

When we move this function to eal common, bsdapp will not use cfg_fd at all.
(Nic uio of BSD will not use this file descriptor.)
So I added the 'if-condition' like above.
But, I will move this fixing in later patch that actually consolidate
this function.

Thanks,
Tetsuya


>
> -- 
> David Marchand

[dpdk-dev] [PATCH 3/6] eal: Fix memory leaks and needless incrementation of pci uio implementation

[Tetsuya Mukawa]

On 2015/03/19 0:39, David Marchand wrote:
> On Tue, Mar 17, 2015 at 10:30 AM, Tetsuya Mukawa  > wrote:
>
> When pci_map_resource() is failed but path is allocated correctly,
> path won't be freed. Also, when open() is failed, uio_res won't be
> freed.
> This patch fixes these memory leaks.
> When pci_map_resource() is failed, mapaddr will be MAP_FAILED.
> In this case, pci_map_addr should not be incremented.
>
> Also, the patch fixes belows.
>  - To shrink code, move close().
>  - Remove fail variable.
>
> Signed-off-by: Tetsuya Mukawa  >
> ---
>  lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 28
> ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> index b971ec9..5044884 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> @@ -333,7 +333,6 @@ pci_uio_map_resource(struct rte_pci_device *dev)
> maps = uio_res->maps;
> for (i = 0, map_idx = 0; i != PCI_MAX_RESOURCE; i++) {
> int fd;
> -   int fail = 0;
>
> /* skip empty BAR */
> phaddr = dev->mem_resource[i].phys_addr;
> @@ -347,6 +346,11 @@ pci_uio_map_resource(struct rte_pci_device *dev)
> loc->domain, loc->bus, loc->devid,
> loc->function,
> i);
>
> +   /* allocate memory to keep path */
> +   maps[map_idx].path = rte_malloc(NULL,
> strlen(devname) + 1, 0);
> +   if (maps[map_idx].path == NULL)
> +   goto fail0;
> +
>
>
>  [snip]
>
> Neither fail0 nor fail1 labels seem to free previous allocations.
> Did I miss something ?

Hi David,


Ah, you are right. I will free all 'maps[i].path' allocated in this
function.

Thanks,
Tetsuya


>
> [snip]
>
> +
> +fail1:
> +   rte_free(maps[map_idx].path);
> +fail0:
> +   rte_free(uio_res);
> +   return -1;
>  }
>
>
>  
>
> -- 
> David Marchand

[dpdk-dev] [PATCH 2/6] eal: Close file descriptor of uio configuration

[Tetsuya Mukawa]

On 2015/03/20 1:04, Iremonger, Bernard wrote:
>> -Original Message-
>> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
>> Sent: Tuesday, March 17, 2015 9:31 AM
>> To: dev at dpdk.org
>> Cc: Iremonger, Bernard; Richardson, Bruce; Tetsuya Mukawa
>> Subject: [PATCH 2/6] eal: Close file descriptor of uio configuration
>>
>> When pci_uio_unmap_resource() is called, a file descriptor that is used for 
>> uio configuration should be
>> closed.
>>
>> Signed-off-by: Tetsuya Mukawa 
>> ---
>>  lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c 
>> b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
>> index 9cdf24f..b971ec9 100644
>> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
>> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
>> @@ -459,8 +459,14 @@ pci_uio_unmap_resource(struct rte_pci_device *dev)
>>
>>  /* close fd if in primary process */
> Hi Tetsuya,
>
> Should there be a check for the primary process before closing both of the 
> these files?

Hi Bernard,

Yes, the check is done like below.
(But it doesn't appear in this patch.)

void
pci_uio_unmap_resource(struct rte_pci_device *dev)
{
struct mapped_pci_resource *uio_res;
struct mapped_pci_res_list *uio_res_list =
RTE_TAILQ_CAST(rte_uio_tailq.head,
mapped_pci_res_list);

if (dev == NULL)
return;

/* find an entry for the device */
uio_res = pci_uio_find_resource(dev);
if (uio_res == NULL)
return;

/* secondary processes - just free maps */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return pci_uio_unmap(uio_res);

TAILQ_REMOVE(uio_res_list, uio_res, next);

(snip)

/* close fd if in primary process */
close(dev->intr_handle.fd);
dev->intr_handle.fd = -1;

(snip)
}

Regards,
Tetsuya

> Regards,
>
> Bernard.
>
>>  close(dev->intr_handle.fd);
>> -
>>  dev->intr_handle.fd = -1;
>> +
>> +/* close cfg_fd if in primary process */
>> +if (dev->intr_handle.uio_cfg_fd >= 0) {
>> +close(dev->intr_handle.uio_cfg_fd);
>> +dev->intr_handle.uio_cfg_fd = -1;
>> +}
>> +
>>  dev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN;  }  #endif /*
>> RTE_LIBRTE_EAL_HOTPLUG */
>> --
>> 1.9.1

[dpdk-dev] [PATCH 3/6] eal: Fix memory leaks and needless incrementation of pci uio implementation

[Tetsuya Mukawa]

On 2015/03/20 1:20, Iremonger, Bernard wrote:
>
>> -Original Message-
>> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
>> Sent: Tuesday, March 17, 2015 9:31 AM
>> To: dev at dpdk.org
>> Cc: Iremonger, Bernard; Richardson, Bruce; Tetsuya Mukawa
>> Subject: [PATCH 3/6] eal: Fix memory leaks and needless incrementation of 
>> pci uio implementation
> Hi Tetsuya,
>
> It would be better to reword "needless incrementation of pci uio 
> implementation" to "needless increment of pci_map_addr" in commit line.
>
>> When pci_map_resource() is failed but path is allocated correctly, path 
>> won't be freed. Also, when
>> open() is failed, uio_res won't be freed.
>> This patch fixes these memory leaks.
>> When pci_map_resource() is failed, mapaddr will be MAP_FAILED.
>> In this case, pci_map_addr should not be incremented.
>>
>> Also, the patch fixes belows.
> Typo "belows" should be "below".

Hi Bernard,

I appreciate for your checking. I will fix it.

Regards,
Tetsuya

> Regards,
>
> Bernard.
>
>>  - To shrink code, move close().
>>  - Remove fail variable.
>>
>> Signed-off-by: Tetsuya Mukawa 
>> ---
>>  lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 28 ++--
>>  1 file changed, 14 insertions(+), 14 deletions(-)
>>
>> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c 
>> b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
>> index b971ec9..5044884 100644
>> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
>> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
>> @@ -333,7 +333,6 @@ pci_uio_map_resource(struct rte_pci_device *dev)
>>  maps = uio_res->maps;
>>  for (i = 0, map_idx = 0; i != PCI_MAX_RESOURCE; i++) {
>>  int fd;
>> -int fail = 0;
>>
>>  /* skip empty BAR */
>>  phaddr = dev->mem_resource[i].phys_addr; @@ -347,6 +346,11 @@
>> pci_uio_map_resource(struct rte_pci_device *dev)
>>  loc->domain, loc->bus, loc->devid, 
>> loc->function,
>>  i);
>>
>> +/* allocate memory to keep path */
>> +maps[map_idx].path = rte_malloc(NULL, strlen(devname) + 1, 0);
>> +if (maps[map_idx].path == NULL)
>> +goto fail0;
>> +
>>  /*
>>   * open resource file, to mmap it
>>   */
>> @@ -354,7 +358,7 @@ pci_uio_map_resource(struct rte_pci_device *dev)
>>  if (fd < 0) {
>>  RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
>>  devname, strerror(errno));
>> -return -1;
>> +goto fail1;
>>  }
>>
>>  /* try mapping somewhere close to the end of hugepages */ @@ 
>> -363,23 +367,13 @@
>> pci_uio_map_resource(struct rte_pci_device *dev)
>>
>>  mapaddr = pci_map_resource(pci_map_addr, fd, 0,
>>  (size_t)dev->mem_resource[i].len, 0);
>> +close(fd);
>>  if (mapaddr == MAP_FAILED)
>> -fail = 1;
>> +goto fail1;
>>
>>  pci_map_addr = RTE_PTR_ADD(mapaddr,
>>  (size_t)dev->mem_resource[i].len);
>>
>> -maps[map_idx].path = rte_malloc(NULL, strlen(devname) + 1, 0);
>> -if (maps[map_idx].path == NULL)
>> -fail = 1;
>> -
>> -if (fail) {
>> -rte_free(uio_res);
>> -close(fd);
>> -return -1;
>> -}
>> -close(fd);
>> -
>>  maps[map_idx].phaddr = dev->mem_resource[i].phys_addr;
>>  maps[map_idx].size = dev->mem_resource[i].len;
>>  maps[map_idx].addr = mapaddr;
>> @@ -394,6 +388,12 @@ pci_uio_map_resource(struct rte_pci_device *dev)
>>  TAILQ_INSERT_TAIL(uio_res_list, uio_res, next);
>>
>>  return 0;
>> +
>> +fail1:
>> +rte_free(maps[map_idx].path);
>> +fail0:
>> +rte_free(uio_res);
>> +return -1;
>>  }
>>
>>  #ifdef RTE_LIBRTE_EAL_HOTPLUG
>> --
>> 1.9.1

[dpdk-dev] [PATCH] hash: fix breaking strict-aliasing rules

[Yerden Zhumabekov]

Hi Bruce,

Answers below.

19.03.2015 22:25, Bruce Richardson ?:
> On Wed, Mar 18, 2015 at 10:51:12PM +0600, Yerden Zhumabekov wrote:
>> Fix rte_hash_crc() function. Casting uint64_t pointer to uin32_t
>> may trigger a compiler warning about breaking strict-aliasing rules.
>> To avoid that, introduce a lookup table which is used to mask out
>> a remainder of data.
>>
>> See issue #1, http://dpdk.org/ml/archives/dev/2015-March/015174.html
>>
>> Signed-off-by: Yerden Zhumabekov 
> Looks ok to me. Couple of minor suggestions below.
>
> /Bruce
>
>> ---
>>  lib/librte_hash/rte_hash_crc.h |   31 +++
>>  1 file changed, 15 insertions(+), 16 deletions(-)
>>
>> diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h
>> index 3dcd362..e81920f 100644
>> --- a/lib/librte_hash/rte_hash_crc.h
>> +++ b/lib/librte_hash/rte_hash_crc.h
>> @@ -323,6 +323,16 @@ static const uint32_t crc32c_tables[8][256] = {{
>>   0xE54C35A1, 0xAC704886, 0x7734CFEF, 0x3E08B2C8, 0xC451B7CC, 0x8D6DCAEB, 
>> 0x56294D82, 0x1F1530A5
>>  }};
>>  
>> +static const uint64_t odd_8byte_mask[] = {
> Where does the name of this variable come from, it seems unclear to me?

If the number of bytes in data for CRC hashing cannot be evenly divided
by 8, the remainder is extracted with these masks. Hence, we have 'odd'
bytes to mask out. Maybe my poor english. :) Suggestions are welcome.
What about remainder_8byte_mask?

>> +0x00FF,
>> +0x,
>> +0x00FF,
>> +0x,
>> +0x00FF,
>> +0x,
>> +0x00FF,
>> +};
>> +
>>  #define CRC32_UPD(crc, n) \
>>  (crc32c_tables[(n)][(crc) & 0xFF] ^ \
>>   crc32c_tables[(n)-1][((crc) >> 8) & 0xFF])
>> @@ -535,38 +545,27 @@ static inline uint32_t
>>  rte_hash_crc(const void *data, uint32_t data_len, uint32_t init_val)
>>  {
>>  unsigned i;
>> -uint64_t temp = 0;
>> +uint64_t temp;
> It is worth keeping variable "temp" at all, it looks to me like it could be 
> done
> away with without seriously affecting readability.

Noted.

>>  const uint64_t *p64 = (const uint64_t *)data;
>>  
>>  for (i = 0; i < data_len / 8; i++) {
>>  init_val = rte_hash_crc_8byte(*p64++, init_val);
>>  }
>>  
>> -switch (7 - (data_len & 0x07)) {
>> +i = 7 - (data_len & 0x07);
> i is not a terribly meaningful variable name, perhaps a slightly longer, more
> meaningful name might improve readability.

Noted, I'll declare a new one.

-- 
Sincerely,

Yerden Zhumabekov
State Technical Service
Astana, KZ

[dpdk-dev] [PATCH] lib/librte_vhost:fix can't send packet anymore after mempool is full again

[linhaifeng]

From: Linhaifeng 

When failed to malloc buffer from mempool we just update last_used_idx but
not used->idx so after many times vhost thought have handle all packets
but virtio_net thought vhost have not handle all packets and will not
update avail->idx.

Signed-off-by: Linhaifeng 
---
 lib/librte_vhost/vhost_rxtx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index 535c7a1..93a8fff 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -609,7 +609,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t 
queue_id,
if (unlikely(m == NULL)) {
RTE_LOG(ERR, VHOST_DATA,
"Failed to allocate memory for mbuf.\n");
-   return entry_success;
+   goto finish;
}
seg_offset = 0;
seg_avail = m->buf_len - RTE_PKTMBUF_HEADROOM;
@@ -721,6 +721,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t 
queue_id,
entry_success++;
}

+finish:
rte_compiler_barrier();
vq->used->idx += entry_success;
/* Kick guest if required. */
-- 
1.8.5.2.msysgit.0

[dpdk-dev] Testpmd application failing with Cause: No probed ethernet device

[Rapelly, Varun]

Hi All,

I'm facing the following issue when testing testpmd application.

EAL: PCI device :03:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   :03:00.0 not managed by UIO driver, skipping
EAL: PCI device :0b:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   :0b:00.0 not managed by UIO driver, skipping
EAL: PCI device :13:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   :13:00.0 not managed by UIO driver, skipping
EAL: PCI device :1b:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   :1b:00.0 not managed by UIO driver, skipping
EAL: Error - exiting with code: 1
  Cause: No probed ethernet device

Please let me know, what could be the issue.

FYI:
Igb_uio and rte_kni ko modules are inserted successfully.


Regards,
Varun

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: test_pmd_log.txt
URL: 
<http://dpdk.org/ml/archives/dev/attachments/20150320/8b90a792/attachment.txt>

[dpdk-dev] [PATCH] lib/librte_vhost:fix can't send packet anymore after mempool is full again

[Linhaifeng]

On 2015/3/20 11:54, linhaifeng wrote:
> From: Linhaifeng 
> 
> When failed to malloc buffer from mempool we just update last_used_idx but
> not used->idx so after many times vhost thought have handle all packets
> but virtio_net thought vhost have not handle all packets and will not
> update avail->idx.
> 
> Signed-off-by: Linhaifeng 
> ---
>  lib/librte_vhost/vhost_rxtx.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
> index 535c7a1..93a8fff 100644
> --- a/lib/librte_vhost/vhost_rxtx.c
> +++ b/lib/librte_vhost/vhost_rxtx.c
> @@ -609,7 +609,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t 
> queue_id,
>   if (unlikely(m == NULL)) {
>   RTE_LOG(ERR, VHOST_DATA,
>   "Failed to allocate memory for mbuf.\n");
> - return entry_success;
> + goto finish;

or use 'break' replace of 'goto' ?

>   }
>   seg_offset = 0;
>   seg_avail = m->buf_len - RTE_PKTMBUF_HEADROOM;
> @@ -721,6 +721,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t 
> queue_id,
>   entry_success++;
>   }
>  
> +finish:
>   rte_compiler_barrier();
>   vq->used->idx += entry_success;
>   /* Kick guest if required. */
> 

-- 
Regards,
Haifeng

[dpdk-dev] [PATCH] ixgbe: fix buffer overrun bug in non-bulk alloc mode setup

[Jiajia, SunX]

Tested-by: Jiajia, SunX 
- Tested Commit: fe4810a01e57645ad92577d628f562791408ce21
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc version 4.8.3
- CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
- NIC: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection 
[8086:10fb]
- Target x86_64-native-linuxapp-gcc
- Total 22 cases, 22 passed, 0 failed

TOPO:
* Connections ports between tester/ixia and DUT
  - TESTER(Or IXIA)---DUT
  - portA--port0
  - portB--port1
  - portC--port2
  - portD--port3

Test Setup#1 for Functional test


Tester has 4 ports(portA--portD), and DUT has 4 ports(port0--port3), then 
connect portA to port0, portB to port1, portC to port2, portD to port3. 



- Case: Basic bonding--Create bonded devices and slaves
  Description: 
Use Setup#1.
Create bonded device and add some ports as salve of bonded 
device,
Then removed slaves or added slaves or change the bonding primary 
slave
Or change bonding mode and so on.
  Expected test result:
Verify the basic functions are normal.

- Case: Basic bonding--MAC Address Test
  Description: 
Use Setup#1.
Create bonded device and add some ports as slaves of bonded 
device,
Check that the changes of  the bonded device and slave MAC
  Expected test result:
Verify the behavior of bonded device and slave according to the 
mode.

- Case: Basic bonding--Device Promiscuous Mode Test
  Description: 
Use Setup#1.
Create bonded device and add some ports as slaves of bonded 
device,
Set promiscuous mode on or off, then send packets to the bonded 
device
Or slaves.
  Expected test result:
Verify the RX/TX status of bonded device and slaves according to 
the mode.

- Case: Mode 0(Round Robin) TX/RX test
  Description: 
Use Setup#1.
Create bonded device with mode 0 and add 3 ports as slaves of 
bonded device,
Forward packets between bonded device and unbounded device, start 
to forward,
And send packets to unbound device or slaves.
  Expected test result:
Verify the RX/TX status of bonded device and slaves in mode 0.

- Case: Mode 0(Round Robin) Bring one slave link down
  Description: 
Use Setup#1.
Create bonded device with mode 0 and add 3 ports as slaves of 
bonded device,
Forward packets between bonded device and unbounded device, start 
to forward,
Bring the link on either port 0, 1 or 2 down. And send packets to 
unbound 
device or slaves.
  Expected test result:
Verify the RX/TX status of bonded device and slaves in mode 0.

- Case: Mode 0(Round Robin) Bring all slave links down
  Description: 
Use Setup#1.
Create bonded device with mode 0 and add 3 ports as slaves of 
bonded device,
Forward packets between bonded device and unbounded device, start 
to forward,
Bring the links down on all bonded ports. And send packets to 
unbound 
device or slaves.
  Expected test result:
Verify the RX/TX status of bonded device and slaves in mode 0.

- Case: Mode 1(Active Backup) TX/RX Test
  Description: 
Use Setup#1.
Create bonded device with mode 1 and add 3 ports as slaves of 
bonded device,
Forward packets between bonded device and unbounded device, start 
to forward,
And send packets to unbound device or slaves.
  Expected test result:
Verify the RX/TX status of bonded device and slaves in mode 1.

- Case: Mode 1(Active Backup) Change active slave, RX/TX test
  Description: 
Use Setup#1.
Continuing from previous test case.Change the active slave port 
from port0 
to port1.Verify that the bonded device's MAC has changed to 
slave1's MAC.

testpmd> set bonding primary 1 4 

   Repeat the transmission and reception(TX/RX) test verify that data 
is now 
   transmitted and received through the new active slave and no longer 
through
   port0
  Expected test result:
Verify the RX/TX status of bonded device and slaves in mode 1.

- Case: Mode 1(Active Backup) Link up/down active eth dev
  Description: 
Use Setup#1.

   Bring link between port A and port0 down. If tester is ixia, can use 
   IxExplorer to set the "Simulate Cable Disconnect" at the port 
property.  
   Verify that the active slave has been changed from port0. Repeat the 
   transmission and reception test verify that data is now transmitted 
and
   received through the new active slave and no longer through port0

   Bring port0 to link down at the remote end.Verify the ac

[dpdk-dev] Testpmd application failing with Cause: No probed ethernet device with DPDK-1.8.0

[Rapelly, Varun]

Hi All,

I'm facing the following issue when testing testpmd application with DPDK-1.8.0.

EAL: PCI device :03:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   :03:00.0 not managed by UIO driver, skipping
EAL: PCI device :0b:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   :0b:00.0 not managed by UIO driver, skipping
EAL: PCI device :13:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   :13:00.0 not managed by UIO driver, skipping
EAL: PCI device :1b:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   :1b:00.0 not managed by UIO driver, skipping
EAL: Error - exiting with code: 1
  Cause: No probed ethernet device

Please let me know, what could be the issue.

FYI:
Igb_uio and rte_kni ko modules are inserted successfully.


Regards,
Varun

[dpdk-dev] [PATCH] lib/librte_vhost:fix can't send packet anymore after mempool is full again

[Ouyang, Changchun]

> -Original Message-
> From: Linhaifeng [mailto:haifeng.lin at huawei.com]
> Sent: Friday, March 20, 2015 2:36 PM
> To: dev at dpdk.org
> Cc: Ouyang, Changchun; Xie, Huawei
> Subject: Re: [PATCH] lib/librte_vhost:fix can't send packet anymore after
> mempool is full again
> 
> 
> 
> On 2015/3/20 11:54, linhaifeng wrote:
> > From: Linhaifeng 
> >
> > When failed to malloc buffer from mempool we just update last_used_idx
> > but not used->idx so after many times vhost thought have handle all
> > packets but virtio_net thought vhost have not handle all packets and
> > will not update avail->idx.
> >
> > Signed-off-by: Linhaifeng 
> > ---
> >  lib/librte_vhost/vhost_rxtx.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_vhost/vhost_rxtx.c
> > b/lib/librte_vhost/vhost_rxtx.c index 535c7a1..93a8fff 100644
> > --- a/lib/librte_vhost/vhost_rxtx.c
> > +++ b/lib/librte_vhost/vhost_rxtx.c
> > @@ -609,7 +609,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev,
> uint16_t queue_id,
> > if (unlikely(m == NULL)) {
> > RTE_LOG(ERR, VHOST_DATA,
> > "Failed to allocate memory for mbuf.\n");
> > -   return entry_success;
> > +   goto finish;
> 
> or use 'break' replace of 'goto' ?

Make sense, I can review if you make a v2 patch
Thanks
Changchun

[dpdk-dev] [PATCH] i40e: remove ALLOW_LB flag on SRIOV vsi

[Jingjing Wu]

Disable VEB switching by removing ALLOW_LB on SRIOV vsi.

If the source mac address of packet sent from VF is not listed in the
VEB's mac table, the VEB will switch the packet back to the VF.
It's a hardware issue. Enabling ALLOW_LB flag will block VF functions.

Signed-off-by: Jingjing Wu 
---
 lib/librte_pmd_i40e/i40e_ethdev.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
b/lib/librte_pmd_i40e/i40e_ethdev.c
index cf6685e..28ea5dc 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -3059,11 +3059,15 @@ i40e_vsi_setup(struct i40e_pf *pf,
ctxt.connection_type = 0x1;
ctxt.flags = I40E_AQ_VSI_TYPE_VF;

-   /* Configure switch ID */
-   ctxt.info.valid_sections |=
-   rte_cpu_to_le_16(I40E_AQ_VSI_PROP_SWITCH_VALID);
-   ctxt.info.switch_id =
-   rte_cpu_to_le_16(I40E_AQ_VSI_SW_ID_FLAG_ALLOW_LB);
+   /**
+* Do not configure switch ID to enable VEB switch by
+* I40E_AQ_VSI_SW_ID_FLAG_ALLOW_LB. Because in Fortville,
+* if the source mac address of packet sent from VF is not
+* listed in the VEB's mac table, the VEB will switch the
+* packet back to the VF. Need to enable it when HW issue
+* is fixed.
+*/
+
/* Configure port/vlan */
ctxt.info.valid_sections |=
rte_cpu_to_le_16(I40E_AQ_VSI_PROP_VLAN_VALID);
-- 
1.9.3

[dpdk-dev] [PATCH v2] lib/librte_vhost:fix can't send packet anymore after mempool is full again

[linhaifeng]

From: Linhaifeng 

When failed to malloc buffer from mempool we just update last_used_idx but
not used->idx so after many times vhost thought have handle all packets
but virtio_net thought vhost have not handle all packets and will not
update avail->idx.

Signed-off-by: Linhaifeng 
---
 lib/librte_vhost/vhost_rxtx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index 535c7a1..510ffe8 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -609,7 +609,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t 
queue_id,
if (unlikely(m == NULL)) {
RTE_LOG(ERR, VHOST_DATA,
"Failed to allocate memory for mbuf.\n");
-   return entry_success;
+   break;  
}
seg_offset = 0;
seg_avail = m->buf_len - RTE_PKTMBUF_HEADROOM;
-- 
1.8.5.2.msysgit.0

[dpdk-dev] [PATCH] lib/librte_pmd_virtio fix can't receive packets after rx_q is empty If failed to alloc mbuf ring_size times the rx_q may be empty and can't receive any packets forever because nb_us

[linhaifeng]

From: Linhaifeng 

so we should try to refill when nb_used is 0.After otherone free mbuf
we can restart to receive packets.

Signed-off-by: Linhaifeng 
---
 lib/librte_pmd_virtio/virtio_rxtx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c 
b/lib/librte_pmd_virtio/virtio_rxtx.c
index 1d74b34..5c7e0cd 100644
--- a/lib/librte_pmd_virtio/virtio_rxtx.c
+++ b/lib/librte_pmd_virtio/virtio_rxtx.c
@@ -495,7 +495,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
num = num - ((rxvq->vq_used_cons_idx + num) % 
DESC_PER_CACHELINE);

if (num == 0)
-   return 0;
+   goto refill;

num = virtqueue_dequeue_burst_rx(rxvq, rcv_pkts, len, num);
PMD_RX_LOG(DEBUG, "used:%d dequeue:%d", nb_used, num);
@@ -536,6 +536,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)

rxvq->packets += nb_rx;

+refill:
/* Allocate new mbuf for the used descriptor */
error = ENOSPC;
while (likely(!virtqueue_full(rxvq))) {
-- 
1.8.5.2.msysgit.0

[dpdk-dev] [PATCH] lib/librte_pmd_virtio fix can't receive packets after rx_q is empty If failed to alloc mbuf ring_size times the rx_q may be empty and can't receive any packets forever because nb_us

[Linhaifeng]

Sorry for my wrong title. Please ignore it.

On 2015/3/20 17:10, linhaifeng wrote:
> From: Linhaifeng 
> 
> so we should try to refill when nb_used is 0.After otherone free mbuf
> we can restart to receive packets.
> 
> Signed-off-by: Linhaifeng 
> ---
>  lib/librte_pmd_virtio/virtio_rxtx.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c 
> b/lib/librte_pmd_virtio/virtio_rxtx.c
> index 1d74b34..5c7e0cd 100644
> --- a/lib/librte_pmd_virtio/virtio_rxtx.c
> +++ b/lib/librte_pmd_virtio/virtio_rxtx.c
> @@ -495,7 +495,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf 
> **rx_pkts, uint16_t nb_pkts)
>   num = num - ((rxvq->vq_used_cons_idx + num) % 
> DESC_PER_CACHELINE);
>  
>   if (num == 0)
> - return 0;
> + goto refill;
>  
>   num = virtqueue_dequeue_burst_rx(rxvq, rcv_pkts, len, num);
>   PMD_RX_LOG(DEBUG, "used:%d dequeue:%d", nb_used, num);
> @@ -536,6 +536,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf 
> **rx_pkts, uint16_t nb_pkts)
>  
>   rxvq->packets += nb_rx;
>  
> +refill:
>   /* Allocate new mbuf for the used descriptor */
>   error = ENOSPC;
>   while (likely(!virtqueue_full(rxvq))) {
> 

-- 
Regards,
Haifeng

[dpdk-dev] [PATCH 0/2] doc: update release notes for jobstats and bonding mode 6

[Pawel Wodkowski]

Update release notes for jobstats and bonding mode 6.

Pawel Wodkowski (2):
  doc: update bonding mode 6 release notes
  doc: add jobstats library and application release notes

 doc/guides/rel_notes/new_features.rst   | 4 +++-
 doc/guides/rel_notes/supported_features.rst | 9 -
 2 files changed, 11 insertions(+), 2 deletions(-)

-- 
1.9.1

[dpdk-dev] [PATCH 6/6] eal: Fix interface of pci_map_resource()

[Iremonger, Bernard]

> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Tuesday, March 17, 2015 9:31 AM
> To: dev at dpdk.org
> Cc: Iremonger, Bernard; Richardson, Bruce; Tetsuya Mukawa
> Subject: [PATCH 6/6] eal: Fix interface of pci_map_resource()
> 
> The function is implemented in both linuxapp and bsdapp, but interface is 
> different. The patch fixes
> the function of bsdapp to do same as linuxapp. After applying it, file 
> descriptor should be opened and
> closed out of pci_map_resource().
> Also, remove redundant error messages from linuxapp.
> 
> Signed-off-by: Tetsuya Mukawa 
> ---
>  lib/librte_eal/bsdapp/eal/eal_pci.c   | 109 
> ++
>  lib/librte_eal/linuxapp/eal/eal_pci_uio.c |  21 +++---
>  2 files changed, 75 insertions(+), 55 deletions(-)
> 
> diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c 
> b/lib/librte_eal/bsdapp/eal/eal_pci.c
> index 08b91b4..21a3d79 100644
> --- a/lib/librte_eal/bsdapp/eal/eal_pci.c
> +++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
> @@ -100,7 +100,7 @@ struct mapped_pci_resource {
> 
>   struct rte_pci_addr pci_addr;
>   char path[PATH_MAX];
> - size_t nb_maps;
> + int nb_maps;
>   struct pci_map maps[PCI_MAX_RESOURCE];  };
> 
> @@ -122,47 +122,30 @@ pci_unbind_kernel_driver(struct rte_pci_device *dev 
> __rte_unused)
> 
>  /* map a particular resource from a file */  static void * 
> -pci_map_resource(void *requested_addr,
> const char *devname, off_t offset,
> -  size_t size)
> +pci_map_resource(void *requested_addr, int fd, off_t offset, size_t size,
> +  int additional_flags)
>  {
> - int fd;
>   void *mapaddr;
> 
> - /*
> -  * open devname, to mmap it
> -  */
> - fd = open(devname, O_RDWR);
> - if (fd < 0) {
> - RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
> - devname, strerror(errno));
> - goto fail;
> - }
> -
>   /* Map the PCI memory resource of device */
>   mapaddr = mmap(requested_addr, size, PROT_READ | PROT_WRITE,
> - MAP_SHARED, fd, offset);
> - close(fd);
> - if (mapaddr == MAP_FAILED ||
> - (requested_addr != NULL && mapaddr != requested_addr)) {
> - RTE_LOG(ERR, EAL, "%s(): cannot mmap(%s(%d), %p, 0x%lx, 0x%lx):"
> - " %s (%p)\n", __func__, devname, fd, requested_addr,
> + MAP_SHARED | additional_flags, fd, offset);
> + if (mapaddr == MAP_FAILED) {
> + RTE_LOG(ERR, EAL,
> + "%s(): cannot mmap(%d, %p, 0x%lx, 0x%lx): %s (%p)\n",
> + __func__, fd, requested_addr,
>   (unsigned long)size, (unsigned long)offset,
>   strerror(errno), mapaddr);
> - goto fail;

Hi Tetsuya,

Previously pci_map_resource() returned NULL  when MAP_FAILED occurred.
It now returns MAP_FAILED.
Where pci_map_resource() is called it should now check for MAP_FAILED instead 
of NULL, or else the return value of NULL should be restored.
There is another comment below.


> - }
> -
> - RTE_LOG(DEBUG, EAL, "  PCI memory mapped at %p\n", mapaddr);
> + } else
> + RTE_LOG(DEBUG, EAL, "  PCI memory mapped at %p\n", mapaddr);
> 
>   return mapaddr;
> -
> -fail:
> - return NULL;
>  }
> 
>  static int
>  pci_uio_map_secondary(struct rte_pci_device *dev)  {
> - size_t i;
> + int i, fd;
>   struct mapped_pci_resource *uio_res;
>   struct mapped_pci_res_list *uio_res_list =
>   RTE_TAILQ_CAST(rte_uio_tailq.head, 
> mapped_pci_res_list); @@ -170,19
> +153,34 @@ pci_uio_map_secondary(struct rte_pci_device *dev)
>   TAILQ_FOREACH(uio_res, uio_res_list, next) {
> 
>   /* skip this element if it doesn't match our PCI address */
> - if (memcmp(&uio_res->pci_addr, &dev->addr, sizeof(dev->addr)))
> + if (rte_eal_compare_pci_addr(&uio_res->pci_addr, &dev->addr))
>   continue;
> 
>   for (i = 0; i != uio_res->nb_maps; i++) {
> - if (pci_map_resource(uio_res->maps[i].addr,
> -  uio_res->path,
> -  (off_t)uio_res->maps[i].offset,
> -  (size_t)uio_res->maps[i].size)
> - != uio_res->maps[i].addr) {
> + /*
> +  * open devname, to mmap it
> +  */
> + fd = open(uio_res->maps[i].path, O_RDWR);
> + if (fd < 0) {
> + RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
> + uio_res->maps[i].path, strerror(errno));
> + return -1;
> + }
> +
> + void *mapaddr = pci_map_resource(uio_res->maps[i].addr,
> +  

[dpdk-dev] [PATCH 1/2] doc: update bonding mode 6 release notes

[Pawel Wodkowski]

Signed-off-by: Pawel Wodkowski 
---
 doc/guides/rel_notes/new_features.rst   | 2 +-
 doc/guides/rel_notes/supported_features.rst | 5 -
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/doc/guides/rel_notes/new_features.rst 
b/doc/guides/rel_notes/new_features.rst
index a27e360..b8d4ea4 100644
--- a/doc/guides/rel_notes/new_features.rst
+++ b/doc/guides/rel_notes/new_features.rst
@@ -32,7 +32,7 @@ New Features
 
 *   Link Bonding

-*   Support for 802.3ad link aggregation (mode 4) and transmit load 
balancing (mode 5) to the link bonding library.
+*   Support for adaptive load balancing (mode 6) to the link bonding 
library.

 *   Support for registration of link status change callbacks with link 
bonding devices.

diff --git a/doc/guides/rel_notes/supported_features.rst 
b/doc/guides/rel_notes/supported_features.rst
index d87fcaa..e8785b7 100644
--- a/doc/guides/rel_notes/supported_features.rst
+++ b/doc/guides/rel_notes/supported_features.rst
@@ -39,7 +39,8 @@ Supported Features

 *   Support for VFIO for mapping BARs and setting up interrupts

-*   Link Bonding PMD Library supporting round-robin, active backup, 
balance(layer 2, layer 2+3, and layer 3+4) and broadcast bonding modes
+*   Link Bonding PMD Library supporting round-robin, active backup, 
balance(layer 2, layer 2+3, and layer 3+4), broadcast bonding modes
+802.3ad link aggregation (mode 4), transmit load balancing (mode 5) and 
adaptive load balancing (mode 6)

 *   Support zero copy mode RX/TX in user space vhost sample

@@ -313,6 +314,8 @@ Supported Features

 *   L3 Forwarding with Power Management

+*   Bonding mode 6
+
 *   QoS Scheduling

 *   QoS Metering + Dropper
-- 
1.9.1

[dpdk-dev] [PATCH 2/2] doc: add jobstats library and application release notes

[Pawel Wodkowski]

Signed-off-by: Pawel Wodkowski 
---
 doc/guides/rel_notes/new_features.rst   | 2 ++
 doc/guides/rel_notes/supported_features.rst | 4 
 2 files changed, 6 insertions(+)

diff --git a/doc/guides/rel_notes/new_features.rst 
b/doc/guides/rel_notes/new_features.rst
index b8d4ea4..6acfe0c 100644
--- a/doc/guides/rel_notes/new_features.rst
+++ b/doc/guides/rel_notes/new_features.rst
@@ -58,6 +58,8 @@ New Features

 *   Packet Distributor Sample Application

+*   Job Stats library and Sample Application.
+
 *   Poll Mode Driver - PCIE host-interface of Intel Ethernet Switch FM1 
Series (librte_pmd_fm10k)

 *   Basic Rx/Tx functions for PF/VF
diff --git a/doc/guides/rel_notes/supported_features.rst 
b/doc/guides/rel_notes/supported_features.rst
index e8785b7..c908877 100644
--- a/doc/guides/rel_notes/supported_features.rst
+++ b/doc/guides/rel_notes/supported_features.rst
@@ -308,6 +308,8 @@ Supported Features

 *   L2 Forwarding (supports virtualized and non-virtualized environments)

+*   L2 Forwarding Job Stats
+
 *   L3 Forwarding (IPv4 and IPv6)

 *   L3 Forwarding in a Virtualized Environment
@@ -370,6 +372,8 @@ Supported Features

 *   CPU-specific compiler optimization

+*   Job stats library for load/cpu utilization measurements
+
 *   Improvements to the Load Balancing sample application

 *   The addition of a PAUSE instruction to tight loops for energy-usage and 
performance improvements
-- 
1.9.1

[dpdk-dev] [PATCH] lib/librte_pmd_virtio fix can't receive packets after rx_q is empty

[linhaifeng]

From: Linhaifeng 

If failed to alloc mbuf ring_size times the rx_q may be empty and can't
receive any packets forever because nb_used is 0 forever.

so we should try to refill when nb_used is 0.After otherone free mbuf
we can restart to receive packets.

Signed-off-by: Linhaifeng 
---
 lib/librte_pmd_virtio/virtio_rxtx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c 
b/lib/librte_pmd_virtio/virtio_rxtx.c
index 1d74b34..5c7e0cd 100644
--- a/lib/librte_pmd_virtio/virtio_rxtx.c
+++ b/lib/librte_pmd_virtio/virtio_rxtx.c
@@ -495,7 +495,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
num = num - ((rxvq->vq_used_cons_idx + num) % 
DESC_PER_CACHELINE);

if (num == 0)
-   return 0;
+   goto refill;

num = virtqueue_dequeue_burst_rx(rxvq, rcv_pkts, len, num);
PMD_RX_LOG(DEBUG, "used:%d dequeue:%d", nb_used, num);
@@ -536,6 +536,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)

rxvq->packets += nb_rx;

+refill:
/* Allocate new mbuf for the used descriptor */
error = ENOSPC;
while (likely(!virtqueue_full(rxvq))) {
-- 
1.8.5.2.msysgit.0

[dpdk-dev] [PATCH] hash: fix breaking strict-aliasing rules

[Pawel Wodkowski]

On 2015-03-18 17:51, Yerden Zhumabekov wrote:
> Fix rte_hash_crc() function. Casting uint64_t pointer to uin32_t
> may trigger a compiler warning about breaking strict-aliasing rules.
> To avoid that, introduce a lookup table which is used to mask out
> a remainder of data.
>
> See issue #1, http://dpdk.org/ml/archives/dev/2015-March/015174.html
>
> Signed-off-by: Yerden Zhumabekov 
> ---
>   lib/librte_hash/rte_hash_crc.h |   31 +++
>   1 file changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h
> index 3dcd362..e81920f 100644
> --- a/lib/librte_hash/rte_hash_crc.h
> +++ b/lib/librte_hash/rte_hash_crc.h
> @@ -323,6 +323,16 @@ static const uint32_t crc32c_tables[8][256] = {{
>0xE54C35A1, 0xAC704886, 0x7734CFEF, 0x3E08B2C8, 0xC451B7CC, 0x8D6DCAEB, 
> 0x56294D82, 0x1F1530A5
>   }};
>
> +static const uint64_t odd_8byte_mask[] = {
> + 0x00FF,
> + 0x,
> + 0x00FF,
> + 0x,
> + 0x00FF,
> + 0x,
> + 0x00FF,
> +};
> +
>   #define CRC32_UPD(crc, n) \
>   (crc32c_tables[(n)][(crc) & 0xFF] ^ \
>crc32c_tables[(n)-1][((crc) >> 8) & 0xFF])
> @@ -535,38 +545,27 @@ static inline uint32_t
>   rte_hash_crc(const void *data, uint32_t data_len, uint32_t init_val)
>   {
>   unsigned i;
> - uint64_t temp = 0;
> + uint64_t temp;
>   const uint64_t *p64 = (const uint64_t *)data;
>
>   for (i = 0; i < data_len / 8; i++) {
>   init_val = rte_hash_crc_8byte(*p64++, init_val);
>   }
>
> - switch (7 - (data_len & 0x07)) {
> + i = 7 - (data_len & 0x07);

Great idea with lookup table!
Only one question here: why keeping this magic at all now?
If you sort odd_8byte_mask opposite direction you can do something like that

data_len &= 0x07;
switch (data_len & 0x07) {
case 1:
case 2:
case 3:
case 4:
temp = odd_8byte_mask[data_len] & *p64;
init_val = rte_hash_crc_4byte(temp, init_val);
case 5:
case 6:
case 7:
temp = odd_8byte_mask[data_len] & *p64;
init_val = rte_hash_crc_8byte(temp, init_val);
break;
default:
break;
}
Or

data_len &= 0x07;
if (data_len > 0) {
temp = odd_8byte_mask[data_len] & *p64;
if (data_len <= 4)
init_val = rte_hash_crc_4byte(temp, init_val);
else
init_val = rte_hash_crc_8byte(temp, init_val);
}

Is there something obvious what I am not seeing here?

Pawel

> + switch (i) {
>   case 0:
> - temp |= (uint64_t) *((const uint8_t *)p64 + 6) << 48;
> - /* Fallthrough */
>   case 1:
> - temp |= (uint64_t) *((const uint8_t *)p64 + 5) << 40;
> - /* Fallthrough */
>   case 2:
> - temp |= (uint64_t) *((const uint8_t *)p64 + 4) << 32;
> - temp |= *((const uint32_t *)p64);
> + temp = odd_8byte_mask[i] & *p64;
>   init_val = rte_hash_crc_8byte(temp, init_val);
>   break;
>   case 3:
> - init_val = rte_hash_crc_4byte(*(const uint32_t *)p64, init_val);
> - break;
>   case 4:
> - temp |= *((const uint8_t *)p64 + 2) << 16;
> - /* Fallthrough */
>   case 5:
> - temp |= *((const uint8_t *)p64 + 1) << 8;
> - /* Fallthrough */
>   case 6:
> - temp |= *((const uint8_t *)p64);
> + temp = odd_8byte_mask[i] & *p64;
>   init_val = rte_hash_crc_4byte(temp, init_val);
> - /* Fallthrough */
>   default:
>   break;
>   }
>


-- 
Pawel

[dpdk-dev] [PATCH] hash: fix breaking strict-aliasing rules

[Pawel Wodkowski]

On 2015-03-18 17:51, Yerden Zhumabekov wrote:

>
> - switch (7 - (data_len & 0x07)) {
> + i = 7 - (data_len & 0x07);
> + switch (i) {
>   case 0:
> - temp |= (uint64_t) *((const uint8_t *)p64 + 6) << 48;
> - /* Fallthrough */
>   case 1:
> - temp |= (uint64_t) *((const uint8_t *)p64 + 5) << 40;
> - /* Fallthrough */
>   case 2:
> - temp |= (uint64_t) *((const uint8_t *)p64 + 4) << 32;
> - temp |= *((const uint32_t *)p64);
> + temp = odd_8byte_mask[i] & *p64;
>   init_val = rte_hash_crc_8byte(temp, init_val);
>   break;
>   case 3:
> - init_val = rte_hash_crc_4byte(*(const uint32_t *)p64, init_val);
> - break;
>   case 4:
> - temp |= *((const uint8_t *)p64 + 2) << 16;
> - /* Fallthrough */
>   case 5:
> - temp |= *((const uint8_t *)p64 + 1) << 8;
> - /* Fallthrough */
>   case 6:
> - temp |= *((const uint8_t *)p64);
> + temp = odd_8byte_mask[i] & *p64;
>   init_val = rte_hash_crc_4byte(temp, init_val);
> - /* Fallthrough */
>   default:
>   break;
>   }
>

Second thought: is this not an issue here reading 8 bytes by 
dereferencing *p64 if there is less bytes in buffer?

-- 
Pawel

[dpdk-dev] [PATCHv2] ixgbe: fix compilation issue when RTE_LIBRTE_IXGBE_RX_ALLOW_BULK_ALLOC is disabled

[Konstantin Ananyev]

v2:
As per comments, reorder patch a bit, to avoid reintroducing extra ifdefs.

Signed-off-by: Konstantin Ananyev 
---
 lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 11 +++
 lib/librte_pmd_ixgbe/ixgbe_rxtx.h |  2 +-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c 
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index 42f0aa5..7b603d0 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
@@ -1170,6 +1170,17 @@ ixgbe_recv_pkts_bulk_alloc(void *rx_queue, struct 
rte_mbuf **rx_pkts,

return nb_rx;
 }
+
+#else
+
+/* Stub to avoid extra ifdefs */
+static uint16_t
+ixgbe_recv_pkts_bulk_alloc(__rte_unused void *rx_queue,
+   __rte_unused struct rte_mbuf **rx_pkts, __rte_unused uint16_t nb_pkts)
+{
+   return 0;
+}
+
 #endif /* RTE_LIBRTE_IXGBE_RX_ALLOW_BULK_ALLOC */

 uint16_t
diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.h 
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.h
index 3937cf6..0d549a0 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.h
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.h
@@ -36,9 +36,9 @@


 #define RTE_PMD_IXGBE_TX_MAX_BURST 32
+#define RTE_PMD_IXGBE_RX_MAX_BURST 32

 #ifdef RTE_LIBRTE_IXGBE_RX_ALLOW_BULK_ALLOC
-#define RTE_PMD_IXGBE_RX_MAX_BURST 32
 #define RTE_IXGBE_DESCS_PER_LOOP   4
 #elif defined(RTE_IXGBE_INC_VECTOR)
 #define RTE_IXGBE_DESCS_PER_LOOP   4
-- 
1.8.5.3

[dpdk-dev] Testpmd application failing with Cause: No probed ethernet device with DPDK-1.8.0

[Bruce Richardson]

On Fri, Mar 20, 2015 at 07:09:00AM +, Rapelly, Varun wrote:
> 
> Hi All,
> 
> I'm facing the following issue when testing testpmd application with 
> DPDK-1.8.0.
> 
> EAL: PCI device :03:00.0 on NUMA socket -1
> EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
> EAL:   :03:00.0 not managed by UIO driver, skipping
> EAL: PCI device :0b:00.0 on NUMA socket -1
> EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
> EAL:   :0b:00.0 not managed by UIO driver, skipping
> EAL: PCI device :13:00.0 on NUMA socket -1
> EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
> EAL:   :13:00.0 not managed by UIO driver, skipping
> EAL: PCI device :1b:00.0 on NUMA socket -1
> EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
> EAL:   :1b:00.0 not managed by UIO driver, skipping
> EAL: Error - exiting with code: 1
>   Cause: No probed ethernet device
> 
> Please let me know, what could be the issue.
> 
> FYI:
> Igb_uio and rte_kni ko modules are inserted successfully.

After you load the uio driver, you still need to bind some NIC devices to use
it, otherwise DPDK will ignore those devices as being used by the kernel.
The script "dpdk_nic_bind.py" in the tools directory can help with the binding
and unbinding to the different drivers.

/Bruce

> 
> Regards,
> Varun
> 

[dpdk-dev] [PATCHv2] ixgbe: fix compilation issue when RTE_LIBRTE_IXGBE_RX_ALLOW_BULK_ALLOC is disabled

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Konstantin
> Ananyev
> Sent: Friday, March 20, 2015 2:00 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCHv2] ixgbe: fix compilation issue when
> RTE_LIBRTE_IXGBE_RX_ALLOW_BULK_ALLOC is disabled
> 
> v2:
> As per comments, reorder patch a bit, to avoid reintroducing extra ifdefs.
> 
> Signed-off-by: Konstantin Ananyev 

Acked-by: Pablo de Lara 

[dpdk-dev] tools brainstorming

[Thomas Monjalon]

Hi,

As you probably know, a MAINTAINERS file is being filled, which is a great
help to request patch reviews and discuss design with the knowledgeable people
of this young DPDK community:
http://dpdk.org/browse/dpdk/tree/MAINTAINERS

The next step is to clearly define what are the guidelines to review a patch
and accept it. So let's write a new document CONTRIBUTING (or another
capitalized file ;). It will help contributors to do the right checks
before submitting, and will help reviewers.

As we are lazy developers, writing guidelines is not enough. It must be
coupled with the integration of some tools. Let's work on these ones:
- make autotests easier and faster to run for smoke testing
- automated basic testpmd check
- build check with various options combinations
- abi check (started with validate-abi.sh)
- static analyze (clang, free online coverity)
- comment check (doxygen, codespell, kerspell)
- format check (customized checkpatch)

I'm sure this last item will trigger a lot of debate.
Actually, format checking can be of two kinds:
- commit message formatting (how to write the title, how and when adding
Fixes tag, Signed-off-by tag, etc);
- coding style might deserve its own document.

At the end, we should be able to pass a "make check" on the whole code and
a "make checkpatch" before submitting.
Then the result of these tools could be automatically checked and displayed
in patchwork or in an adapted version of qemu's patchew. But this is
obviously a later step.
When all automatic lights are green and human design review is properly done,
the patch can be acknowledged by one or many reviewers. Speaking about that,
it would be helpful to have a column in our patchwork to summarize the counts
of tests, reviews and acknowledgements.

Comments and contributions are more than welcome!

[dpdk-dev] Queries on DPDK working with XL710 intel NIC

[Nissim Nisimov]

Seems like the issue related to the following errors I see in dmesg:

[48459.391753] dmar: DRHD: handling fault status reg 302
[48459.392092] dmar: DMAR:[DMA Read] Request device [21:00.1] fault addr 
fbaddd000 
[48459.392092] DMAR:[fault reason 06] PTE Read access is not set

I am running on HP ProLiant DL380p Gen8. Ubuntu 3.11.0-26-generic



Is anyone encounter this kind of issue with Intel XL710 NICs (Fortville)?

Thx
Nissim

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Nissim Nisimov
Sent: Thursday, March 19, 2015 7:58 PM
To: dev at dpdk.org
Subject: [dpdk-dev] Queries on DPDK working with XL710 intel NIC

Hi all,

I am trying to work with intel XL710 40GIG NIC but for some reason when trying 
to load it via dpdk I am getting the following error:


EAL: PCI device :21:00.1 on NUMA socket 1
EAL:   probe driver: 8086:1583 rte_i40e_pmd
EAL:   PCI memory mapped at 0x7fff939f9000
EAL:   PCI memory mapped at 0x7fffd54b8000
EAL: Error - exiting with code: 1
  Cause: Requested device :21:00.1 cannot be used

It seems that the "problematic" functions is i40e_aq_get_firmware_version() in 
the following line:
status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
(gdb) p status
$3 = I40E_ERR_ADMIN_QUEUE_TIMEOUT


I did read in another mail thread (attached below) that this might be a 
firmware issue so i upgraded my NIC firmware version to latest but still not 
able to get it work:

root at lagavulin:~# ethtool -i eth24
driver: i40e
version: 1.2.37
firmware-version: f4.33.31377 a1.2 n4.42 e1932
bus-info: :21:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes


any idea why I still see the issue?

thanks!
Nissim



Hi Yan



Please tell me what version of firmware are you using? If it is too old, please 
update to at least 4.2.6.

If it is still there, check that if your firmware updating is really 
successful. You can try to run linux kernel driver to have a double check.



Regards,

Helin



From: Yan Freedland [mailto:y...@radware.com]

Sent: Thursday, March 19, 2015 12:28 AM

To: Zhang, Helin

Cc: dev at dpdk.org

Subject: [dpdk-dev] i40e_aq_get_firmware_version failure



Hi,



I am trying to start DPDK with 40G Intel NIC and get a failure at 
initialization stage in i40e_aq_get_firmware_version(). For some reason this 
function reaches TIMEOUT for more than maximum allowed times (10 times). In the 
note below I understand that several failures may be considerable but not as 
many as I have.



Should I enlarge the retries number ?

Is it a HW issue ?



Anyone who faced it or may assist please comment.



Thanks,

Yan

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Friday, March 20, 2015 2:51 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] tools brainstorming
> 
> Hi,
> 
> As you probably know, a MAINTAINERS file is being filled, which is a great
> help to request patch reviews and discuss design with the knowledgeable
> people of this young DPDK community:
>   http://dpdk.org/browse/dpdk/tree/MAINTAINERS
> 
> The next step is to clearly define what are the guidelines to review a patch
> and accept it. So let's write a new document CONTRIBUTING (or another
> capitalized file ;). It will help contributors to do the right checks before
> submitting, and will help reviewers.
> 
> As we are lazy developers, writing guidelines is not enough. It must be
> coupled with the integration of some tools. Let's work on these ones:
>   - make autotests easier and faster to run for smoke testing
>   - automated basic testpmd check
>   - build check with various options combinations
>   - abi check (started with validate-abi.sh)
>   - static analyze (clang, free online coverity)
>   - comment check (doxygen, codespell, kerspell)
>   - format check (customized checkpatch)

This is a great list Thomas, totally agree with you we need some guidelines,
and some ways of automating basic checks to catch basic issues,
save time and traffic on the mailing list.

I propose we also add a bug tracking tool (e.g. Bugzilla or other).

And also a standalone page/document/archive of FAQ's.

> 
> I'm sure this last item will trigger a lot of debate.
> Actually, format checking can be of two kinds:
>   - commit message formatting (how to write the title, how and when
> adding
>   Fixes tag, Signed-off-by tag, etc);
>   - coding style might deserve its own document.
> 
> At the end, we should be able to pass a "make check" on the whole code and
> a "make checkpatch" before submitting.
> Then the result of these tools could be automatically checked and displayed
> in patchwork or in an adapted version of qemu's patchew. But this is
> obviously a later step.
> When all automatic lights are green and human design review is properly
> done, the patch can be acknowledged by one or many reviewers. Speaking
> about that, it would be helpful to have a column in our patchwork to
> summarize the counts of tests, reviews and acknowledgements.
> 
> Comments and contributions are more than welcome!

[dpdk-dev] tools brainstorming

[Neil Horman]

On Fri, Mar 20, 2015 at 03:51:11PM +0100, Thomas Monjalon wrote:
> Hi,
> 
> As you probably know, a MAINTAINERS file is being filled, which is a great
> help to request patch reviews and discuss design with the knowledgeable people
> of this young DPDK community:
>   http://dpdk.org/browse/dpdk/tree/MAINTAINERS
> 
> The next step is to clearly define what are the guidelines to review a patch
> and accept it. So let's write a new document CONTRIBUTING (or another
> capitalized file ;). It will help contributors to do the right checks
> before submitting, and will help reviewers.
> 
+100.  This is a great idea.  A few thoughts.

> As we are lazy developers, writing guidelines is not enough. It must be
> coupled with the integration of some tools. Let's work on these ones:
>   - make autotests easier and faster to run for smoke testing
>   - automated basic testpmd check
>   - build check with various options combinations
The kernel does this with some special make targets (make allyesconfig, make
randconfig, etc).  They basically act as build time fuzzers and are very useful.
I'm not sure that the DPDK build system is really condusive to that yet though,
since its made up of static configuration files.  This may require some
build environment changes

>   - abi check (started with validate-abi.sh)
This will need continued improvement, as it is currently a very interactive
tool. I'm not sure that in its current for it will ever be fully automated, save
for perhaps being able to give you a boolean response (yes, ABI is compatible,
or no it is not).


>   - static analyze (clang, free online coverity)
>   - comment check (doxygen, codespell, kerspell)
>   - format check (customized checkpatch)
> 
> I'm sure this last item will trigger a lot of debate.
> Actually, format checking can be of two kinds:
>   - commit message formatting (how to write the title, how and when adding
>   Fixes tag, Signed-off-by tag, etc);
>   - coding style might deserve its own document.
> 

I think both of these are worthwhile, especially if their not too egregious in
terms of work overhead.  A coding style is pretty common to enforce.  Commit
messages are a bit less so, but it would be reasonable to do some simple things,
like add a subsystem tag, signed off line, etc

> At the end, we should be able to pass a "make check" on the whole code and
> a "make checkpatch" before submitting.
> Then the result of these tools could be automatically checked and displayed
> in patchwork or in an adapted version of qemu's patchew. But this is
> obviously a later step.
> When all automatic lights are green and human design review is properly done,
> the patch can be acknowledged by one or many reviewers. Speaking about that,
> it would be helpful to have a column in our patchwork to summarize the counts
> of tests, reviews and acknowledgements.
> 
> Comments and contributions are more than welcome!
> 

[dpdk-dev] tools brainstorming

[Simon Kågström]

On 2015-03-20 15:51, Thomas Monjalon wrote:
> As we are lazy developers, writing guidelines is not enough. It must be
> coupled with the integration of some tools. Let's work on these ones:
>   - make autotests easier and faster to run for smoke testing
>   - automated basic testpmd check
>   - build check with various options combinations
>   - abi check (started with validate-abi.sh)
>   - static analyze (clang, free online coverity)
>   - comment check (doxygen, codespell, kerspell)
>   - format check (customized checkpatch)

Code coverage for automated tests can be useful as well.

In a way I'm speaking in my own interests here since I've written a tool
to do just this (and produce nice HTML etc output), kcov, that can be
found at github (https://github.com/SimonKagstrom/kcov).

// Simon

[dpdk-dev] Queries on DPDK working with XL710 intel NIC

[Roberts, Lee A.]

Nissim,

Recent HP ProLiant servers use RMRRs (see 
https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt)
to communicate management information.  Use of these RMRRs conflicts with IOMMU 
usage.

On ProLiant Gen8 servers, you have a couple options:

1) If you are doing bare-metal testing and don't require the IOMMU, turn it off.
   Some kernels have "intel_iommu=on" set by default.  You should be able to use
   "intel_iommu=off" if your kernel enables IOMMU by default.

2) If your application requires the IOMMU, there are BIOS parameters that can be
   configured to eliminate the RMRRs on a slot-by-slot basis.  (I will send 
instructions
   for this separately, since it is not a DPDK issue.)

  - Lee Roberts


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Nissim Nisimov
Sent: Friday, March 20, 2015 8:56 AM
To: Nissim Nisimov; dev at dpdk.org
Subject: Re: [dpdk-dev] Queries on DPDK working with XL710 intel NIC

Seems like the issue related to the following errors I see in dmesg:

[48459.391753] dmar: DRHD: handling fault status reg 302
[48459.392092] dmar: DMAR:[DMA Read] Request device [21:00.1] fault addr 
fbaddd000 
[48459.392092] DMAR:[fault reason 06] PTE Read access is not set

I am running on HP ProLiant DL380p Gen8. Ubuntu 3.11.0-26-generic



Is anyone encounter this kind of issue with Intel XL710 NICs (Fortville)?

Thx
Nissim

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Nissim Nisimov
Sent: Thursday, March 19, 2015 7:58 PM
To: dev at dpdk.org
Subject: [dpdk-dev] Queries on DPDK working with XL710 intel NIC

Hi all,

I am trying to work with intel XL710 40GIG NIC but for some reason when trying 
to load it via dpdk I am getting the following error:


EAL: PCI device :21:00.1 on NUMA socket 1
EAL:   probe driver: 8086:1583 rte_i40e_pmd
EAL:   PCI memory mapped at 0x7fff939f9000
EAL:   PCI memory mapped at 0x7fffd54b8000
EAL: Error - exiting with code: 1
  Cause: Requested device :21:00.1 cannot be used

It seems that the "problematic" functions is i40e_aq_get_firmware_version() in 
the following line:
status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
(gdb) p status
$3 = I40E_ERR_ADMIN_QUEUE_TIMEOUT


I did read in another mail thread (attached below) that this might be a 
firmware issue so i upgraded my NIC firmware version to latest but still not 
able to get it work:

root at lagavulin:~# ethtool -i eth24
driver: i40e
version: 1.2.37
firmware-version: f4.33.31377 a1.2 n4.42 e1932
bus-info: :21:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes


any idea why I still see the issue?

thanks!
Nissim



Hi Yan



Please tell me what version of firmware are you using? If it is too old, please 
update to at least 4.2.6.

If it is still there, check that if your firmware updating is really 
successful. You can try to run linux kernel driver to have a double check.



Regards,

Helin



From: Yan Freedland [mailto:y...@radware.com]

Sent: Thursday, March 19, 2015 12:28 AM

To: Zhang, Helin

Cc: dev at dpdk.org

Subject: [dpdk-dev] i40e_aq_get_firmware_version failure



Hi,



I am trying to start DPDK with 40G Intel NIC and get a failure at 
initialization stage in i40e_aq_get_firmware_version(). For some reason this 
function reaches TIMEOUT for more than maximum allowed times (10 times). In the 
note below I understand that several failures may be considerable but not as 
many as I have.



Should I enlarge the retries number ?

Is it a HW issue ?



Anyone who faced it or may assist please comment.



Thanks,

Yan

[dpdk-dev] [PATCH] Fix `eventfd_link' module leakages and races

[Pavel Boldin]

Changchun,

Please review the updated patch.

Pavel

On Tue, Mar 17, 2015 at 3:29 AM, Ouyang, Changchun <
changchun.ouyang at intel.com> wrote:

>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pavel Boldin
> > Sent: Tuesday, March 17, 2015 12:41 AM
> > To: dev at dpdk.org
> > Cc: Pavel Boldin
> > Subject: [dpdk-dev] [PATCH] Fix `eventfd_link' module leakages and races
> >
> > From: Pavel Boldin 
> >
> > The `eventfd_link' module provides an API to "steal" fd from another
> process
> > had been written with a bug that leaks `struct file' because of the extra
> > reference counter increment and missing `fput' call.
> >
> > The other bug is using another process' `task_struct' without
> incrementing a
> > reference counter.
> >
> > Fix these bugs and refactor the module.
> > ---
> >  examples/vhost/eventfd_link/eventfd_link.c | 236 -
> > 
> >  1 file changed, 130 insertions(+), 106 deletions(-)
> >
> > diff --git a/examples/vhost/eventfd_link/eventfd_link.c
> > b/examples/vhost/eventfd_link/eventfd_link.c
> > index 69470ba..9f1f8fb 100644
> > --- a/examples/vhost/eventfd_link/eventfd_link.c
> > +++ b/examples/vhost/eventfd_link/eventfd_link.c
> > @@ -42,15 +42,15 @@
> >   * get_files_struct is copied from fs/file.c
> >   */
> >  struct files_struct *
> > -get_files_struct (struct task_struct *task)
> > +get_files_struct(struct task_struct *task)
> >  {
> >   struct files_struct *files;
> >
> > - task_lock (task);
> > + task_lock(task);
> >   files = task->files;
> >   if (files)
> > - atomic_inc (&files->count);
> > - task_unlock (task);
> > + atomic_inc(&files->count);
> > + task_unlock(task);
>
> I don't find any actual code change for above.
> If they are tab, space, indent refine,
> I suggest it needs a separate patch named code cleanup,
> Then it is easy to review.
>
> Same for other places.
>
> Done.
> Changchun
>
>
> >
> >   return files;
> >  }
> > @@ -59,117 +59,142 @@ get_files_struct (struct task_struct *task)
> >   * put_files_struct is extracted from fs/file.c
> >   */
> >  void
> > -put_files_struct (struct files_struct *files)
> > +put_files_struct(struct files_struct *files)
> >  {
> > - if (atomic_dec_and_test (&files->count))
> > - {
> > + if (atomic_dec_and_test(&files->count))
> >   BUG ();
> > +}
> > +
> > +static struct file *
> > +fget_from_files(struct files_struct *files, unsigned fd) {
> > + struct file *file;
> > +
> > + rcu_read_lock();
> > + file = fcheck_files(files, fd);
> > + if (file)
> > + {
> > + if (file->f_mode & FMODE_PATH
> > + || !atomic_long_inc_not_zero(&file->f_count))
> > + file = NULL;
> >   }
> > + rcu_read_unlock();
> > +
> > + return file;
> > +}
> > +
> > +static int
> > +close_fd(unsigned fd)
> > +{
> > + struct file *file;
> > + struct files_struct *files = current->files;
> > + struct fdtable *fdt;
> > +
> > + spin_lock(&files->file_lock);
> > + fdt = files_fdtable(files);
> > + if (fd >= fdt->max_fds)
> > + goto out_unlock;
> > + file = fdt->fd[fd];
> > + if (!file)
> > + goto out_unlock;
> > + rcu_assign_pointer(fdt->fd[fd], NULL);
> > + __clear_bit(fd, fdt->close_on_exec);
> > + spin_unlock(&files->file_lock);
> > + return filp_close(file, files);
> > +
> > +out_unlock:
> > + spin_unlock(&files->file_lock);
> > + return -EBADF;
> >  }
> >
> >
> >  static long
> > -eventfd_link_ioctl (struct file *f, unsigned int ioctl, unsigned long
> arg)
> > +eventfd_link_ioctl_copy(unsigned long arg)
> >  {
> > - void __user *argp = (void __user *) arg;
> > + long ret = -EFAULT;
> >   struct task_struct *task_target = NULL;
> > - struct file *file;
> > - struct files_struct *files;
> > - struct fdtable *fdt;
> > + struct file *target_file = NULL;
> > + struct files_struct *target_files = NULL;
> >   struct eventfd_copy eventfd_copy;
> > + struct pid *pid;
> > +
> > + if (copy_from_user(&eventfd_copy, (void __user*)arg,
> > + sizeof(struct eventfd_copy)))
> > + goto out;
> > +
> > + /*
> > +  * Find the task struct for the target pid
> > +  */
> > + pid = find_vpid(eventfd_copy.target_pid);
> > + if (pid == NULL) {
> > + printk(KERN_INFO "Unable to find pid %d\n",
> > + eventfd_copy.target_pid);
> > + goto out;
> > + }
> > +
> > + task_target = get_pid_task(pid, PIDTYPE_PID);
> > + if (task_target == NULL) {
> > + printk(KERN_INFO "Failed to get task for pid %d\n",
> > + eventfd_copy.target_pid);
> > + goto out;
> > + }
> > +
> > + ret = close_fd(eventfd_copy.source_fd);
> > + if (ret)
> > + goto out_task;
> > + ret = -EFAULT;
> > +
> > 

[dpdk-dev] [PATCH] lib/librte_pmd_virtio fix can't receive packets after rx_q is empty

[Xie, Huawei]

On 3/20/2015 6:47 PM, linhaifeng wrote:
> From: Linhaifeng 
>
> If failed to alloc mbuf ring_size times the rx_q may be empty and can't
> receive any packets forever because nb_used is 0 forever.
Agreed. In current implementation, once VQ becomes empty, we have no
chance to refill it again.
The simple fix is, receive one and then refill one as other PMDs. Need
to consider which is best strategy in terms of performance in future.
How did you find this? through code review or real workload?
> so we should try to refill when nb_used is 0.After otherone free mbuf
> we can restart to receive packets.
>
> Signed-off-by: Linhaifeng 
> ---
>  lib/librte_pmd_virtio/virtio_rxtx.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c 
> b/lib/librte_pmd_virtio/virtio_rxtx.c
> index 1d74b34..5c7e0cd 100644
> --- a/lib/librte_pmd_virtio/virtio_rxtx.c
> +++ b/lib/librte_pmd_virtio/virtio_rxtx.c
> @@ -495,7 +495,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf 
> **rx_pkts, uint16_t nb_pkts)
>   num = num - ((rxvq->vq_used_cons_idx + num) % 
> DESC_PER_CACHELINE);
>  
>   if (num == 0)
> - return 0;
> + goto refill;
>  
>   num = virtqueue_dequeue_burst_rx(rxvq, rcv_pkts, len, num);
>   PMD_RX_LOG(DEBUG, "used:%d dequeue:%d", nb_used, num);
> @@ -536,6 +536,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf 
> **rx_pkts, uint16_t nb_pkts)
>  
>   rxvq->packets += nb_rx;
>  
> +refill:
>   /* Allocate new mbuf for the used descriptor */
>   error = ENOSPC;
>   while (likely(!virtqueue_full(rxvq))) {

[dpdk-dev] soft lockup calling receive burst

[Joseph Vossen]

hello,

I am working on a dpdk-based app using version 1.6 under RH7.3.  Under varying 
traffic loads, I will intermittently notice a kernel soft lockup and the RIP 
provided by the kernel always points to the same MOV instruction in 
rte_ethdev.h (line #1982).  The stack trace looks like:


dev = &rte_eth_devices[port_id];
return (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id], 
rx_pkts, nb_pkts);


473176: 0f b7 15 a7 68 38 00movzwl 
0x3868a7(%rip),%edx  # 7f9a24  rte_eth_rx_burst():
47317d: 0f b6 31movzbl 
(%rcx),%esi
473180: 48 89 f0mov %rsi,%rax
473183: 0f b6 71 01 movzbl 0x1(%rcx),%esi
473187: 48 c1 e0 06 shl $0x6,%rax
47318b: 48 8b b8 70 ed 83 00mov 0x83ed70(%rax),%rdi
>   473192: 48 8b 0fmov (%rdi),%rcx
473195: 48 8b 3c f1 mov 
(%rcx,%rsi,8),%rdi
473199: 4c 89 eemov %r13,%rsi
47319c: ff 90 60 ed 83 00   callq *0x83ed60(%rax)


has any one else seen something like this?

thanks

[dpdk-dev] soft lockup calling receive burst

[Jay Rolette]

On Fri, Mar 20, 2015 at 12:53 PM, Joseph Vossen  wrote:

> hello,
>
> I am working on a dpdk-based app using version 1.6 under RH7.3.  Under
> varying traffic loads, I will intermittently notice a kernel soft lockup
> and the RIP provided by the kernel always points to the same MOV
> instruction in rte_ethdev.h (line #1982).  The stack trace looks like:
>
>
> dev = &rte_eth_devices[port_id];
> return
> (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id], rx_pkts, nb_pkts);
>
>
> 473176: 0f b7 15 a7 68 38 00movzwl
> 0x3868a7(%rip),%edx  # 7f9a24  rte_eth_rx_burst():
> 47317d: 0f b6 31movzbl
> (%rcx),%esi
> 473180: 48 89 f0mov
> %rsi,%rax
> 473183: 0f b6 71 01 movzbl
> 0x1(%rcx),%esi
> 473187: 48 c1 e0 06 shl $0x6,%rax
> 47318b: 48 8b b8 70 ed 83 00mov
> 0x83ed70(%rax),%rdi
> >   473192: 48 8b 0fmov
> (%rdi),%rcx
> 473195: 48 8b 3c f1 mov
> (%rcx,%rsi,8),%rdi
> 473199: 4c 89 eemov
> %r13,%rsi
> 47319c: ff 90 60 ed 83 00   callq
> *0x83ed60(%rax)
>
>
> has any one else seen something like this?
>
> thanks


I haven't seen that, but there's a soft-lockup in KNI in DPDK 1.6. Here's
what I posted about that one a few weeks ago:

Found the problem. No patch to submit since it's already fixed in later
versions of DPDK, but thought I'd follow up with the details since I'm sure
we aren't the only ones trying to use bleeding-edge versions of DPDK...

In kni_net_rx_normal(), it was calling netif_receive_skb() instead of
netif_rx(). The source for netif_receive_skb() point out that it should
only be called from soft-irq context, which isn't the case for KNI.

As typical, simple fix once you track it down.

Yao-Po Wang's fix:  commit 41a6ebded53982107c1adfc0652d6cc1375a7db9.

Jay

[dpdk-dev] soft lockup calling receive burst

[Joseph Vossen]

[snip]

> I haven't seen that, but there's a soft-lockup in KNI in DPDK 1.6. Here's 
> what I posted about that one a few weeks ago:
> 
> Found the problem. No patch to submit since it's already fixed in later 
> versions of DPDK, but thought I'd follow up with the details since I'm sure 
> we aren't the only ones trying to use bleeding-edge versions of DPDK...
> 
> In kni_net_rx_normal(), it was calling netif_receive_skb() instead of 
> netif_rx(). The source for netif_receive_skb() point out that it should only 
> be called from soft-irq context, which isn't the case for KNI.
> 
> As typical, simple fix once you track it down.
> 
> Yao-Po Wang's fix:  commit 41a6ebded53982107c1adfc0652d6cc1375a7db9.

I noticed that posting, but KNI is not involved here...thanks!

[dpdk-dev] [PATCH v6 7/8] igb: enable rx queue interrupts for PF

[Stephen Hemminger]

On Fri, 27 Feb 2015 12:56:15 +0800
Cunming Liang  wrote:

>  
>  /*
> + * It clears the interrupt causes and enables the interrupt.
> + * It will be called once only during nic initialized.
> + *
> + * @param dev
> + *  Pointer to struct rte_eth_dev.
> + *
> + * @return
> + *  - On success, zero.
> + *  - On failure, a negative value.
> + */
> +static int eth_igb_rxq_interrupt_setup(struct rte_eth_dev *dev)
> +{
> +

This function should be void
It always succeeds and the caller just not check the return value.

If you did this in one driver, I bet other drivers have same problem.

[dpdk-dev] [PATCHv2] EAL: rename rte_common_vect.h into arch/x86/rte_vect.h

[Thomas Monjalon]

> Signed-off-by: Konstantin Ananyev 

Applied, thanks

[dpdk-dev] [PATCH] kni: fix compilation issue on kernel 3.19

[Thomas Monjalon]

Hi Pablo,

2015-03-12 17:24, Pablo de Lara:
> Due to API changes in functions ndo_dflt_bridge_getlink
> and igb_ndo_fdb_add in kernel 3.19, DPDK would not build.

Please provide the Linux commit id for this change.

> This patch solves the problem, by checking the kernel version
> and adding the necessary new parameters
> 
> Signed-off-by: Pablo de Lara 
> ---
>  lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c |7 +++
>  lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h  |3 +++
>  2 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c 
> b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
> index a802a02..24b147d 100644
> --- a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
> +++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
> @@ -2103,6 +2103,9 @@ static int igb_set_features(struct net_device *netdev,
>  static int igb_ndo_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
>  struct net_device *dev,
>  const unsigned char *addr,
> +#ifdef HAVE_NDO_FDB_ADD_VID
> +u16 vid,
> +#endif
>  u16 flags)
>  #else

You should explain in commit message why the change is not needed in #else
(!USE_CONST_DEV_UC_CHAR for version < 3.7).

>  static int igb_ndo_fdb_add(struct ndmsg *ndm,
> @@ -2259,7 +2262,11 @@ static int igb_ndo_bridge_getlink(struct sk_buff *skb, 
> u32 pid, u32 seq,
>   else
>   mode = BRIDGE_MODE_VEPA;
>  
> +#ifdef HAVE_NDO_FDB_ADD_VID
> + return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode, 0, 0);
> +#else
>   return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode);
> +#endif /* HAVE_NDO_FDB_ADD_VID */
>  }
>  #endif /* HAVE_BRIDGE_ATTRIBS */
>  #endif /* NTF_SELF */
> diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h 
> b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
> index 1213cc6..5c799e9 100644
> --- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
> +++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
> @@ -3881,4 +3881,7 @@ skb_set_hash(struct sk_buff *skb, __u32 hash, 
> __always_unused int type)
>  #define HAVE_VF_MIN_MAX_TXRATE 1
>  #endif /* >= 3.16.0 */
>  
> +#if ( LINUX_VERSION_CODE >= KERNEL_VERSION(3,19,0) )
> +#define HAVE_NDO_FDB_ADD_VID
> +#endif /* >= 3.19.0 */
>  #endif /* _KCOMPAT_H_ */

A blank line is missing here.
Are you sure there is no macro defined in the Linux changes which could be
checked instead of version number? I dislike version checks because of
backport problems.

[dpdk-dev] [PATCHv2] ixgbe: fix compilation issue when RTE_LIBRTE_IXGBE_RX_ALLOW_BULK_ALLOC is disabled

[Thomas Monjalon]

> > v2:
> > As per comments, reorder patch a bit, to avoid reintroducing extra ifdefs.
> > 
> > Signed-off-by: Konstantin Ananyev 
> 
> Acked-by: Pablo de Lara 

Fixes: 01fa1d6215fa ("ixgbe: unify Rx setup")

Applied, thanks

[dpdk-dev] [PATCH] ixgbe: fix buffer overrun bug in non-bulk alloc mode setup

[Thomas Monjalon]

2015-03-20 06:50, Jiajia, SunX:
> Tested-by: Jiajia, SunX 
> - Tested Commit: fe4810a01e57645ad92577d628f562791408ce21

This commit id is related to a PDF doc change.

> - OS: Fedora20 3.11.10-301.fc20.x86_64
> - GCC: gcc version 4.8.3
> - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
> - NIC: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection 
> [8086:10fb]
> - Target x86_64-native-linuxapp-gcc
> - Total 22 cases, 22 passed, 0 failed

It seems this test is related to bonding, not ixgbe buffer overrun in
non-bulk alloc mode.

> TOPO:
> * Connections ports between tester/ixia and DUT
>   - TESTER(Or IXIA)---DUT
>   - portA--port0
>   - portB--port1
>   - portC--port2
>   - portD--port3
> 
> Test Setup#1 for Functional test
> 
> 
> Tester has 4 ports(portA--portD), and DUT has 4 ports(port0--port3), then 
> connect portA to port0, portB to port1, portC to port2, portD to port3. 
> 
> 
> 
> - Case: Basic bonding--Create bonded devices and slaves
>   Description: 
>   Use Setup#1.
>   Create bonded device and add some ports as salve of bonded 
> device,
> Then removed slaves or added slaves or change the bonding primary 
> slave
> Or change bonding mode and so on.
>   Expected test result:
> Verify the basic functions are normal.
> 
> - Case: Basic bonding--MAC Address Test
>   Description: 
>   Use Setup#1.
>   Create bonded device and add some ports as slaves of bonded 
> device,
> Check that the changes of  the bonded device and slave MAC
>   Expected test result:
> Verify the behavior of bonded device and slave according to the 
> mode.
> 
> - Case: Basic bonding--Device Promiscuous Mode Test
>   Description: 
>   Use Setup#1.
>   Create bonded device and add some ports as slaves of bonded 
> device,
> Set promiscuous mode on or off, then send packets to the bonded 
> device
> Or slaves.
>   Expected test result:
> Verify the RX/TX status of bonded device and slaves according to 
> the mode.
> 
> - Case: Mode 0(Round Robin) TX/RX test
>   Description: 
>   Use Setup#1.
>   Create bonded device with mode 0 and add 3 ports as slaves of 
> bonded device,
> Forward packets between bonded device and unbounded device, start 
> to forward,
> And send packets to unbound device or slaves.
>   Expected test result:
> Verify the RX/TX status of bonded device and slaves in mode 0.
> 
> - Case: Mode 0(Round Robin) Bring one slave link down
>   Description: 
>   Use Setup#1.
>   Create bonded device with mode 0 and add 3 ports as slaves of 
> bonded device,
> Forward packets between bonded device and unbounded device, start 
> to forward,
> Bring the link on either port 0, 1 or 2 down. And send packets to 
> unbound 
> device or slaves.
>   Expected test result:
> Verify the RX/TX status of bonded device and slaves in mode 0.
> 
> - Case: Mode 0(Round Robin) Bring all slave links down
>   Description: 
>   Use Setup#1.
>   Create bonded device with mode 0 and add 3 ports as slaves of 
> bonded device,
> Forward packets between bonded device and unbounded device, start 
> to forward,
> Bring the links down on all bonded ports. And send packets to 
> unbound 
> device or slaves.
>   Expected test result:
> Verify the RX/TX status of bonded device and slaves in mode 0.
> 
> - Case: Mode 1(Active Backup) TX/RX Test
>   Description: 
>   Use Setup#1.
>   Create bonded device with mode 1 and add 3 ports as slaves of 
> bonded device,
> Forward packets between bonded device and unbounded device, start 
> to forward,
> And send packets to unbound device or slaves.
>   Expected test result:
> Verify the RX/TX status of bonded device and slaves in mode 1.
> 
> - Case: Mode 1(Active Backup) Change active slave, RX/TX test
>   Description: 
>   Use Setup#1.
>   Continuing from previous test case.Change the active slave port 
> from port0 
> to port1.Verify that the bonded device's MAC has changed to 
> slave1's MAC.
> 
> testpmd> set bonding primary 1 4 
> 
>Repeat the transmission and reception(TX/RX) test verify that data 
> is now 
>transmitted and received through the new active slave and no 
> longer through
>port0
>   Expected test result:
> Verify the RX/TX status of bonded device and slaves in mode 1.
> 
> - Case: Mode 1(Active Backup) Link up/down active eth dev
>   Description: 
>   Use Setup#1.
> 
>Bring link between port A and port0 down. If tester is ixia, can 
> u

[dpdk-dev] [PATCH] ixgbe: fix buffer overrun bug in non-bulk alloc mode setup

[Thomas Monjalon]

> > From: Pawel Wodkowski 
> > 
> > When bulk alloc is enabled at compile time but preconditions for
> > it are not met at runtime the ixgbe_reset_rx_queue() function
> > overrides rxq->sw_ring not allocated elements.
> > 
> > Fixes: 01fa1d6 ("ixgbe: unify Rx setup")

Thanks for using the Fixes: tag.

> > Signed-off-by: Pawel Wodkowski 
> 
> Acked-by: Konstantin Ananyev 

Applied, thanks

[dpdk-dev] [PATCH] virtio: Fix crash issue for secondary process

[Thomas Monjalon]

2015-03-19 09:45, Ouyang Changchun:
> It definitely needs Rx function even in the case of secondary process, so put
> the assignment a bit earlier to make sure of it.
> 
> Signed-off-by: Changchun Ouyang 
> ---
>  lib/librte_pmd_virtio/virtio_ethdev.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
> b/lib/librte_pmd_virtio/virtio_ethdev.c
> index 603be2d..ad24cf2 100644
> --- a/lib/librte_pmd_virtio/virtio_ethdev.c
> +++ b/lib/librte_pmd_virtio/virtio_ethdev.c
> @@ -1113,6 +1113,7 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
>   RTE_BUILD_BUG_ON(RTE_PKTMBUF_HEADROOM < sizeof(struct virtio_net_hdr));
>  
>   eth_dev->dev_ops = &virtio_eth_dev_ops;
> + eth_dev->rx_pkt_burst = &virtio_recv_pkts;
>   eth_dev->tx_pkt_burst = &virtio_xmit_pkts;
>  
>   if (rte_eal_process_type() == RTE_PROC_SECONDARY)
> @@ -1148,10 +1149,8 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
>   if (vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF)) {
>   eth_dev->rx_pkt_burst = &virtio_recv_mergeable_pkts;

Why the mergeable buffers case is not handled for secondary processes?

>   hw->vtnet_hdr_size = sizeof(struct virtio_net_hdr_mrg_rxbuf);
> - } else {
> - eth_dev->rx_pkt_burst = &virtio_recv_pkts;
> + } else
>   hw->vtnet_hdr_size = sizeof(struct virtio_net_hdr);
> - }
>  
>   /* Copy the permanent MAC address to: virtio_hw */
>   virtio_get_hwaddr(hw);

[dpdk-dev] [PATCH] lib/librte_vhost: fix build errors

[Thomas Monjalon]

> > fix the error "missing initializer" and "cast to pointer from integer of 
> > different size".
> >
> > For the pointer to integer cast issue, need to investigate changing the 
> > typeof mapped_address.
> >
> > Signed-off-by: Huawei Xie 
> >
> Acted-by: Changchun Ouyang 
^
I recommend copy/paste to avoid typo ;)

Applied, thanks