[dpdk-dev] [PATCH] net/virtio-user: Fix missing brackets in if condition

2016-07-12 Thread Yuanhan Liu
On Tue, Jul 12, 2016 at 11:30:25AM +0200, Maxime Coquelin wrote:
> The error is reported using test build script:
> 
> $ scripts/test-build.sh x86_64-native-linuxapp-gcc
> ...
> drivers/net/virtio/virtio_user_ethdev.c: In function 
> ?virtio_user_pmd_devinit?:
> drivers/net/virtio/virtio_user_ethdev.c:345:2: error: this ?if? clause does 
> not guard... [-Werror=misleading-indentation]
>   if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_PATH) == 1)
> ^~
> 
> Fixes: 404bd6bfe360 ("net/virtio-user: fix return value not checked")
> 
> Cc: Jianfeng Tan 
> Signed-off-by: Maxime Coquelin 

Acked-by: Yuanhan Liu 

Thanks for the fix.

--yliu


[dpdk-dev] [PATCH v2] Memory leak when adding/removing vhost_user ports

2016-07-12 Thread Yuanhan Liu
On Wed, Jul 06, 2016 at 09:08:12PM +0800, Yuanhan Liu wrote:
> On Wed, Jul 06, 2016 at 02:24:57PM +0200, Christian Ehrhardt wrote:
> > Hi,
> > while checking for dpdk 16.07 what backports are accepted in the meantime 
> > so I
> > can drop them I found this particular discussion has been silently 
> > forgotten by
> > all of us.
> 
> Not really. As later I found that my patch was actually wrong (besides
> the issue you already found). I will revisit this issue thoroughly when
> get time, hopefully, next week.

Here it is: vhost_destroy() will be invoked when:

- QEMU quits gracefully 
- QEMU terminates unexpectedly

Meaning, there should be no memory leak. I think we are fine here (I
maybe wrong though, feeling a bit dizzy now :(

--yliu


[dpdk-dev] Help: How to read packet statistics from device registers via dpdk PMD?

2016-07-12 Thread Bill Bonaparte
Hi, Jay:
  My apologies for taking me to get back to you.
  I tried the sample apps on my environment follow your advice, and I
found it works well.
  so I started to compare  the code related to the api between my app
and the sample app, I didn't find any significative difference. I am very
confused.
  .
  finnaly, with the help of my colleague, I tracked down the problem.
It's a confused character of my platform that make the packets miss  the
interface which I monitored.
  so I can access the IP of the interface, but the flow don't pass
through the interface.
  after ajusting the topology, the api works well.

 anyhow, thanks to your advice, I tracked down the problem.
 so again, I appreciate your time in talking with me about this api.

On Thu, Jul 7, 2016 at 8:19 PM, Jay Rolette  wrote:

>
> On Thu, Jul 7, 2016 at 12:52 AM, Bill Bonaparte 
> wrote:
>
>> I am so happy to get your reply.
>> My dpdk version is 2.1?and the OS is centOS 7?
>> the following is the output from "dpdk_nic_bind.py --status":
>>
>> [root at APV35 ~]# dpdk_nic_bind.py --status
>>
>> Network devices using DPDK-compatible driver
>> 
>> :04:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
>> :0b:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
>> :13:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
>> :1b:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
>>
>> Network devices using kernel driver
>> ===
>> :03:00.0 'VMXNET3 Ethernet Controller' if=ens160 drv=vmxnet3
>> unused=igb_uio *Active*
>>
>> Other network devices
>> =
>> 
>>
>
> That's a different virtual NIC than what I'm running in my VMs, but given
> your app isn't working directly on the hardware, I doubt that's the issue.
> In case it helps along the way, here's what I see in my VM:
>
> $ dpdk_nic_bind.py --status
>
> Network devices using DPDK-compatible driver
> 
> :02:02.0 '82545EM Gigabit Ethernet Controller (Copper)' drv=igb_uio
> unused=
> :02:03.0 '82545EM Gigabit Ethernet Controller (Copper)' drv=igb_uio
> unused=
> :02:04.0 '82545EM Gigabit Ethernet Controller (Copper)' drv=igb_uio
> unused=
> :02:05.0 '82545EM Gigabit Ethernet Controller (Copper)' drv=igb_uio
> unused=
>
> Network devices using kernel driver
> ===
> :02:01.0 '82545EM Gigabit Ethernet Controller (Copper)' if=eth0
> drv=e1000 unused=igb_uio *Active*
>
> Other network devices
> =
> 
>
>
>> I tried it on the physical mathine, it still does not work. the OS is
>> centOS 7, too.
>> [root at AN ~]# dpdk_nic_bind.py --status
>>
>> Network devices using DPDK-compatible driver
>> 
>> :01:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio
>> unused=
>> :01:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio
>> unused=
>> :03:00.0 'I350 Gigabit Backplane Connection' drv=igb_uio unused=
>> :03:00.1 'I350 Gigabit Backplane Connection' drv=igb_uio unused=
>> :03:00.2 'I350 Gigabit Backplane Connection' drv=igb_uio unused=
>> :03:00.3 'I350 Gigabit Backplane Connection' drv=igb_uio unused=
>> :07:00.0 'I350 Gigabit Network Connection' drv=igb_uio unused=
>> :07:00.1 'I350 Gigabit Network Connection' drv=igb_uio unused=
>> :07:00.2 'I350 Gigabit Network Connection' drv=igb_uio unused=
>> :07:00.3 'I350 Gigabit Network Connection' drv=igb_uio unused=
>> :09:00.0 'I350 Gigabit Network Connection' drv=igb_uio unused=
>> :09:00.1 'I350 Gigabit Network Connection' drv=igb_uio unused=
>> :09:00.2 'I350 Gigabit Network Connection' drv=igb_uio unused=
>> :09:00.3 'I350 Gigabit Network Connection' drv=igb_uio unused=
>> :0c:00.0 'Device 0011' drv=igb_uio unused=
>> :0f:00.1 'I350 Gigabit Network Connection' drv=igb_uio unused=
>>
>> Network devices using kernel driver
>> ===
>> :0f:00.0 'I350 Gigabit Network Connection' if=enp15s0f0 drv=igb
>> unused=igb_uio *Active*
>>
>> Other network devices
>> =
>> 
>>
>
> With it not working on hardware and you having devices successfully bound
> to DPDK, maybe it's a problem in your app. Have you tried running any of
> the sample apps that use rte_eth_stats_get() and see if it works there?
>
> Jay
>
>
>> On Tue, Jul 5, 2016 at 8:03 PM, Jay Rolette  wrote:
>>
>>>
>>> On Tue, Jul 5, 2016 at 2:35 AM, Bill Bonaparte 
>>> wrote:
>>>
 Hi:
 I am a new fish, I have tried my best to find answer about my question
 on
 web, but I failed. so
 I come here to ask for your help. the below is my question:

 I found that dpdk provides a api rte_eth_stats_get to read packet
 statistics about the interface, includes total input/output
 unicast/multicast/brodcast packets/bytes. but the 

[dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct location

2016-07-12 Thread Ananyev, Konstantin
> 
> 
> Hi Juhamatti,
> 
> >
> > Hello,
> >
> > > > > > -Original Message-
> > > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Juhamatti
> > > > > > Kuusisaari
> > > > > > Sent: Monday, July 11, 2016 11:21 AM
> > > > > > To: dev at dpdk.org
> > > > > > Subject: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to
> > > > > > correct location
> > > > > >
> > > > > > Fix the location of the rte_ring data dependency read barrier.
> > > > > > It needs to be called before accessing indexed data to ensure that
> > > > > > the data itself is guaranteed to be correctly updated.
> > > > > >
> > > > > > See more details at kernel/Documentation/memory-barriers.txt
> > > > > > section 'Data dependency barriers'.
> > > > >
> > > > >
> > > > > Any explanation why?
> > > > > From my point smp_rmb()s are on the proper places here :) Konstantin
> > > >
> > > > The problem here is that on a weak memory model system the CPU is
> > > > allowed to load the address data out-of-order in advance.
> > > > If the read barrier is after the DEQUEUE, you might end up having the
> > > > old data there on a race situation when the buffer is continuously full.
> > > > Having it before the DEQUEUE guarantees that the load is not done in
> > > > advance.
> > >
> > > Sorry, still didn't see any race condition in the current code.
> > > Can you provide any particular example?
> > > From other side, moving smp_rmb() before dequeueing the objects, could
> > > introduce a race condition, on cpus where later writes can be reordered 
> > > with
> > > earlier reads.
> >
> > Here is a simplified example sequence from time perspective:
> > 1. Consumer CPU (CCPU) loads value y from r->ring[x] out-of-order
> > (the key of the problem)
> 
> To read the value of ring[x] cpu has to calculate x first.
> And to calculate x it needs to read cons.head and prod.tail first.
> Are you saying that some modern cpu can:
>  -'speculate' value of cons.head and  prod.tail
>   (based on what?)
>  -calculate x based on these speculated values.
> - read ring[x]
> - read cons.head and prod.tail
> - if read values are not equal to speculated ones , then
>   re-caluclate x and re-read ring[x]
> - else use speculatively read ring[x]
> ?
> If such thing is possible  (is it really? and if yes on which cpu?),

As I can see, neither ARM or PPC support  such things.
Both of them do obey address dependency.
(ARM & PPC guys feel free to correct me here, if I am wrong here).
So what cpu we are talking about?
Konstantin

> then yes, we might need an extra  smp_rmb() before DEQUEUE_PTRS()
> for __rte_ring_sc_do_dequeue().
> For __rte_ring_mc_do_dequeue(), I think we are ok, as
> there is CAS just before DEQUEUE_PTRS().
> 
> > 2. Producer CPU (PCPU) updates r->ring[x] to value be z
> > 3. PCPU updates prod_tail to be x
> > 4. CCPU updates cons_head to be x
> > 5. CCPU loads r->ring[x] by using out-of-order loaded value y [is z in 
> > reality]
> >
> > The problem here is that on weak memory model, the CCPU is allowed to load
> > r->ring[x] value in advance, if it decides to do so (CCPU needs to be able 
> > to see
> > in advance that x will be an interesting index worth loading). The index 
> > value x
> > is updated atomically,  but it does not matter here. Also, the write 
> > barrier on PCPU
> > side guarantees that CCPU cannot see update of x before PCPU has really 
> > updated
> > the r->ring[x] to z and moved the tail, but still allows to do the 
> > out-of-order loads
> > without proper read barrier.
> >
> > When the read barrier is moved between steps 4 and 5, it disallows to use
> > any out-of-order loads so far and forces to drop r->ring[x] y value and
> > load current value z.
> >
> > The ring queue appears to work well as this is a rare corner case. Due to 
> > the
> > head,tail-structure the problem needs queue to be full and also CCPU needs
> > to see r->ring[x] update later than it does the out-of-order load. In 
> > addition,
> > the HW needs to be able to predict and choose the load to the future index
> > (which should be quite possible, considering modern CPUs). If you have seen
> > in the past problems and noticed that a larger ring queue works better as a
> > workaround, you may have encountered the problem already.
> 
> I don't understand what means 'larger rings works better' here.
> What we are talking about is  race condition, that if hit, would
> cause data corruption and most likely a crash.
> 
> >
> > It is quite safe to move the barrier before DEQUEUE because after the 
> > DEQUEUE
> > there is nothing really that we would want to protect with a read barrier.
> 
> I don't think so.
> If you remove barrier after DEQUEUE(), that means on systems with relaxed 
> memory ordering
> cons.tail could be updated before DEQUEUE() will be finished and producer can 
> overwrite
> queue entries that were not yet dequeued.
> So if cpu can really do such speculative out of order loads,
> then we do need for  __rte_ring_sc_do_dequeue() something 

[dpdk-dev] [PATCH] scripts: remove old build option

2016-07-12 Thread Thomas Monjalon
The config option CONFIG_RTE_PCI_CONFIG does not exist anymore.

Fixes: 7d619406f31d ("pci: remove deprecated specific config")

Signed-off-by: Thomas Monjalon 
---
 scripts/test-build.sh | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index 0c7a56b..30dfdf5 100755
--- a/scripts/test-build.sh
+++ b/scripts/test-build.sh
@@ -158,7 +158,6 @@ config () #   
# Automatic configuration
test "$DPDK_DEP_NUMA" != y || \
sed -ri   's,(NUMA=)n,\1y,' $1/.config
-   sed -ri 's,(PCI_CONFIG=)n,\1y,' $1/.config
sed -ri's,(LIBRTE_IEEE1588=)n,\1y,' $1/.config
sed -ri 's,(BYPASS=)n,\1y,' $1/.config
test "$DPDK_DEP_ARCHIVE" != y || \
-- 
2.7.0



[dpdk-dev] [PATCH] scripts: fix libnuma dependency in build test

2016-07-12 Thread Thomas Monjalon
The option CONFIG_RTE_LIBRTE_VHOST_NUMA depends on availability of
libnuma in the system.
The configuration option DPDK_DEP_NUMA can be set if available for
the DPDK_TARGET being built.

Fixes: cd31ca579c0d ("scripts: add build tests")

Signed-off-by: Thomas Monjalon 
---
 scripts/test-build.sh | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index 5bcecfc..0c7a56b 100755
--- a/scripts/test-build.sh
+++ b/scripts/test-build.sh
@@ -39,6 +39,7 @@ default_path=$PATH
 # - DPDK_DEP_CFLAGS
 # - DPDK_DEP_LDFLAGS
 # - DPDK_DEP_MOFED (y/[n])
+# - DPDK_DEP_NUMA (y/[n])
 # - DPDK_DEP_PCAP (y/[n])
 # - DPDK_DEP_SSL (y/[n])
 # - DPDK_DEP_SZE (y/[n])
@@ -118,6 +119,7 @@ reset_env ()
unset DPDK_DEP_CFLAGS
unset DPDK_DEP_LDFLAGS
unset DPDK_DEP_MOFED
+   unset DPDK_DEP_NUMA
unset DPDK_DEP_PCAP
unset DPDK_DEP_SSL
unset DPDK_DEP_SZE
@@ -154,7 +156,7 @@ config () #   
sed -ri 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config )

# Automatic configuration
-   ! echo $2 | grep -q '^x86_64' || \
+   test "$DPDK_DEP_NUMA" != y || \
sed -ri   's,(NUMA=)n,\1y,' $1/.config
sed -ri 's,(PCI_CONFIG=)n,\1y,' $1/.config
sed -ri's,(LIBRTE_IEEE1588=)n,\1y,' $1/.config
-- 
2.7.0



[dpdk-dev] option for IEEE1588

2016-07-12 Thread Thomas Monjalon
Hi all,

We have a compile-time option for IEEE1588 feature.
It means we must know wether the application will need it before
compiling DPDK. Linux distributions must make this choice when packaging.

Does it make sense to transform it into a runtime option?
Is the performance drawback so big?


[dpdk-dev] [PATCH v2] vhost_user: avoid crash when exeeding file descriptors

2016-07-12 Thread Yuanhan Liu
On Wed, Jul 06, 2016 at 02:24:58PM +0200, Christian Ehrhardt wrote:
> *update in v2*
> - refreshing for DPDK 16.07
> - Close fd on vserver->listenfd as suggested in discussion
> 
> Original From:
> From: Patrik Andersson 
> 
> Protect against DPDK crash when allocation of listen fd >= 1023.
> For events on fd:s >1023, the current implementation will trigger
> an abort due to access outside of allocated bit mask.

Hmmm, I have no idea why I missed this email in the beginning,
otherwise, it would have been in rc2 release.

Thanks for the re-posting, and we should have had it in last
release.

Acked-by: Yuanhan Liu 

--yliu


[dpdk-dev] [RFC] vhost: Add indirect descriptors support to the TX path

2016-07-12 Thread Maxime Coquelin
Indirect descriptors are usually supported by virtio-net devices,
allowing to dispatch a large number of large requests.

When the virtio device sends a packet using indirect descriptors,
only one slot is used in the ring, even for large packets.

Signed-off-by: Maxime Coquelin 
---
I have a two questions regarding the implementation of this feature:

1. Should I add a check to ensure the indirect feature is supported
(i.e. the negociation succeeded) when having an indirect desc?

2. Should I check in copy_desc_to_mbuf() that we don't have a nested
indirect descriptor?

Both these sanity checks are recommended from the virtio spec, but
since it is to be done in the hot path, it may introduce some
performance penalties.

Note that the first check is not done in the Kernel vhost driver, whereas
the second one is.

Cheers,
Maxime
---
 lib/librte_vhost/vhost_rxtx.c | 31 ++-
 lib/librte_vhost/virtio-net.c |  3 ++-
 2 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index 15ca956..74cbc75 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -669,8 +669,8 @@ make_rarp_packet(struct rte_mbuf *rarp_mbuf, const struct 
ether_addr *mac)
 }

 static inline int __attribute__((always_inline))
-copy_desc_to_mbuf(struct virtio_net *dev, struct vhost_virtqueue *vq,
- struct rte_mbuf *m, uint16_t desc_idx,
+copy_desc_to_mbuf(struct virtio_net *dev, struct vring_desc *descs,
+ uint16_t max_desc, struct rte_mbuf *m, uint16_t desc_idx,
  struct rte_mempool *mbuf_pool)
 {
struct vring_desc *desc;
@@ -683,7 +683,7 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct 
vhost_virtqueue *vq,
/* A counter to avoid desc dead loop chain */
uint32_t nr_desc = 1;

-   desc = >desc[desc_idx];
+   desc = [desc_idx];
if (unlikely(desc->len < dev->vhost_hlen))
return -1;

@@ -698,7 +698,7 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct 
vhost_virtqueue *vq,
 */
if (likely((desc->len == dev->vhost_hlen) &&
   (desc->flags & VRING_DESC_F_NEXT) != 0)) {
-   desc = >desc[desc->next];
+   desc = [desc->next];

desc_addr = gpa_to_vva(dev, desc->addr);
rte_prefetch0((void *)(uintptr_t)desc_addr);
@@ -731,10 +731,10 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct 
vhost_virtqueue *vq,
if ((desc->flags & VRING_DESC_F_NEXT) == 0)
break;

-   if (unlikely(desc->next >= vq->size ||
-++nr_desc >= vq->size))
+   if (unlikely(desc->next >= max_desc ||
+++nr_desc >= max_desc))
return -1;
-   desc = >desc[desc->next];
+   desc = [desc->next];

desc_addr = gpa_to_vva(dev, desc->addr);
rte_prefetch0((void *)(uintptr_t)desc_addr);
@@ -859,19 +859,32 @@ rte_vhost_dequeue_burst(int vid, uint16_t queue_id,
/* Prefetch descriptor index. */
rte_prefetch0(>desc[desc_indexes[0]]);
for (i = 0; i < count; i++) {
+   struct vring_desc *desc;
+   uint16_t size, idx;
int err;

if (likely(i + 1 < count))
rte_prefetch0(>desc[desc_indexes[i + 1]]);

+   if (vq->desc[desc_indexes[i]].flags & VRING_DESC_F_INDIRECT) {
+   desc = (struct vring_desc *)gpa_to_vva(dev,
+   vq->desc[desc_indexes[i]].addr);
+   rte_prefetch0(desc);
+   size = vq->desc[desc_indexes[i]].len / sizeof(*desc);
+   idx = 0;
+   } else {
+   desc = vq->desc;
+   size = vq->size;
+   idx = desc_indexes[i];
+   }
+
pkts[i] = rte_pktmbuf_alloc(mbuf_pool);
if (unlikely(pkts[i] == NULL)) {
RTE_LOG(ERR, VHOST_DATA,
"Failed to allocate memory for mbuf.\n");
break;
}
-   err = copy_desc_to_mbuf(dev, vq, pkts[i], desc_indexes[i],
-   mbuf_pool);
+   err = copy_desc_to_mbuf(dev, desc, size, pkts[i], idx, 
mbuf_pool);
if (unlikely(err)) {
rte_pktmbuf_free(pkts[i]);
break;
diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
index 1785695..0304812 100644
--- a/lib/librte_vhost/virtio-net.c
+++ b/lib/librte_vhost/virtio-net.c
@@ -76,7 +76,8 @@ struct virtio_net_device_ops const *notify_ops;
(1ULL << 

[dpdk-dev] [PATCH] doc: grammatical fix in EAL docs

2016-07-12 Thread Mcnamara, John
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Shreyansh Jain
> Sent: Tuesday, July 12, 2016 10:28 AM
> To: david.marchand at 6wind.com
> Cc: dev at dpdk.org; thomas.monjalon at 6wind.com
> Subject: [dpdk-dev] [PATCH] doc: grammatical fix in EAL docs
> 
> Signed-off-by: Shreyansh Jain 

Acked-by: John McNamara 



[dpdk-dev] [PATCH] doc: fix consumer/producer mixup in Ring lib doc

2016-07-12 Thread Shreyansh Jain
Signed-off-by: Shreyansh Jain 
---
 doc/guides/prog_guide/ring_lib.rst | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/doc/guides/prog_guide/ring_lib.rst 
b/doc/guides/prog_guide/ring_lib.rst
index 3b92a8f..5cf4ce2 100644
--- a/doc/guides/prog_guide/ring_lib.rst
+++ b/doc/guides/prog_guide/ring_lib.rst
@@ -252,7 +252,7 @@ In this example, only the producer head and tail (prod_head 
and prod_tail) are m

 The initial state is to have a prod_head and prod_tail pointing at the same 
location.

-Multiple Consumer Enqueue First Step
+Multiple Producers Enqueue First Step
 

 On both cores, *ring->prod_head* and ring->cons_tail are copied in local 
variables.
@@ -266,10 +266,10 @@ If there is not enough room in the ring (this is detected 
by checking cons_tail)

 .. figure:: img/ring-mp-enqueue1.*

-   Multiple consumer enqueue first step
+   Multiple producer enqueue first step


-Multiple Consumer Enqueue Second Step
+Multiple Producers Enqueue Second Step
 ^

 The second step is to modify ring->prod_head in the ring structure to point to 
the same location as prod_next.
@@ -288,10 +288,10 @@ In the figure, the operation succeeded on core 1, and 
step one restarted on core

 .. figure:: img/ring-mp-enqueue2.*

-   Multiple consumer enqueue second step
+   Multiple producer enqueue second step


-Multiple Consumer Enqueue Third Step
+Multiple Producers Enqueue Third Step
 

 The CAS operation is retried on core 2 with success.
@@ -303,10 +303,10 @@ The core 1 updates one element of the ring(obj4), and the 
core 2 updates another

 .. figure:: img/ring-mp-enqueue3.*

-   Multiple consumer enqueue third step
+   Multiple producer enqueue third step


-Multiple Consumer Enqueue Fourth Step
+Multiple Producers Enqueue Fourth Step
 ^

 Each core now wants to update ring->prod_tail.
@@ -318,10 +318,10 @@ This is only true on core 1. The operation is finished on 
core 1.

 .. figure:: img/ring-mp-enqueue4.*

-   Multiple consumer enqueue fourth step
+   Multiple producer enqueue fourth step


-Multiple Consumer Enqueue Last Step
+Multiple Producers Enqueue Last Step
 ^^^

 Once ring->prod_tail is updated by core 1, core 2 is allowed to update it too.
@@ -332,7 +332,7 @@ The operation is also finished on core 2.

 .. figure:: img/ring-mp-enqueue5.*

-   Multiple consumer enqueue last step
+   Multiple producer enqueue last step


 Modulo 32-bit Indexes
-- 
2.7.4



[dpdk-dev] [PATCH] doc: grammatical fix in EAL docs

2016-07-12 Thread Shreyansh Jain
Signed-off-by: Shreyansh Jain 
---
 doc/guides/prog_guide/env_abstraction_layer.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst 
b/doc/guides/prog_guide/env_abstraction_layer.rst
index 4b9895e..10a10a8 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -341,7 +341,7 @@ Known Issues
   be preempted by another pthread doing a multi-consumer dequeue on
   the same ring.

-Bypassing this constraint it may cause the 2nd pthread to spin until the 
1st one is scheduled again.
+Bypassing this constraint may cause the 2nd pthread to spin until the 1st 
one is scheduled again.
 Moreover, if the 1st pthread is preempted by a context that has an higher 
priority, it may even cause a dead lock.

   This does not mean it cannot be used, simply, there is a need to narrow down 
the situation when it is used by multi-pthread on the same core.
-- 
2.7.4



[dpdk-dev] [PATCH 0/2] doc: live migration procedure with vhost_user

2016-07-12 Thread Yuanhan Liu
On Mon, Jul 11, 2016 at 04:05:17PM +0100, Bernard Iremonger wrote:
> This patchset describes the procedure to Live migrate a VM with
> Virtio PMD's with the vhost_user sample application (vhost-switch)
> running on the host.
> 
> Bernard Iremonger (2):
>   doc: live migration of VM with vhost_user on host
>   doc: add vhost_user live migration image

Reviewed-by: Yuanhan Liu 

And thanks for the doc!

--yliu
> 
>  doc/guides/howto/img/lm_vhost_user.svg| 644 
> ++
>  doc/guides/howto/index.rst|   1 +
>  doc/guides/howto/lm_virtio_vhost_user.rst | 508 +++
>  3 files changed, 1153 insertions(+)
>  create mode 100644 doc/guides/howto/img/lm_vhost_user.svg
>  create mode 100644 doc/guides/howto/lm_virtio_vhost_user.rst
> 
> -- 
> 2.9.0


[dpdk-dev] Compiling DPDK is not working on Red Hat 6.7

2016-07-12 Thread Thomas Monjalon
Hi,

2016-07-12 11:35, Raslan Darawsheh:
> I think the option is there as you see:
> 
[...]
> -Wl,--as-needed  -Wl,-lrt -Wl,-lm |...] -Wl,-lrte_eal
[...]
> eal_timer.c:(.text+0x152): undefined reference to `clock_gettime'

I suspect we need -lrt after -lrte_eal.

Please could you try the following patch?


--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -176,6 +176,8 @@ ifeq ($(RTE_DEVEL_BUILD)$(CONFIG_RTE_BUILD_SHARED_LIB),yy)
 LDFLAGS += -rpath=$(RTE_SDK_BIN)/lib
 endif

+MAPFLAGS = -Map=$@.map --cref
+
 .PHONY: all
 all: install

@@ -190,15 +192,13 @@ build: _postbuild
 exe2cmd = $(strip $(call dotfile,$(patsubst %,%.cmd,$(1

 ifeq ($(LINK_USING_CC),1)
-override EXTRA_LDFLAGS := $(call linkerprefix,$(EXTRA_LDFLAGS))
-O_TO_EXE = $(CC) $(CFLAGS) \
-   $(call linkerprefix,$(LDLIBS)) \
-   $(call linkerprefix,$(LDFLAGS)) $(LDFLAGS_$(@)) $(EXTRA_LDFLAGS) \
-   -Wl,-Map=$(@).map,--cref -o $@ $(OBJS-y)
+O_TO_EXE = $(CC) -o $@ $(CFLAGS) $(OBJS-y) $(call linkerprefix, \
+   $(LDLIBS) $(LDFLAGS) $(LDFLAGS_$(@)) $(EXTRA_LDFLAGS) \
+   $(MAPFLAGS))
 else
-O_TO_EXE = $(LD) $(LDLIBS) \
-   $(LDFLAGS) $(LDFLAGS_$(@)) $(EXTRA_LDFLAGS) \
-   -Map=$(@).map --cref -o $@ $(OBJS-y)
+O_TO_EXE = $(LD) -o $@ $(OBJS-y)
+   $(LDLIBS) $(LDFLAGS) $(LDFLAGS_$(@)) $(EXTRA_LDFLAGS) \
+   $(MAPFLAGS)
 endif
 O_TO_EXE_STR = $(subst ','\'',$(O_TO_EXE)) #'# fix syntax highlight
 O_TO_EXE_DISP = $(if $(V),"$(O_TO_EXE_STR)","  LD $(@)")



[dpdk-dev] [PATCH v1 28/28] ether: support SoC device/driver

2016-07-12 Thread Shreyansh jain
Hi Jan,

On Monday 04 July 2016 08:06 PM, Jan Viktorin wrote:
> On Mon, 4 Jul 2016 19:57:18 +0530
> Shreyansh jain  wrote:
> 
> [...]
> 
> @@ -1431,7 +1524,7 @@ rte_eth_dev_info_get(uint8_t port_id, struct 
> rte_eth_dev_info *dev_info)
>  
>   RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
>   (*dev->dev_ops->dev_infos_get)(dev, dev_info);
> - dev_info->pci_dev = dev->pci_dev;
> + dev_info->soc_dev = dev->soc_dev;

 I think both the members, pci_dev and soc_dev, should be updated by this 
 call.
 Is there some specific reason why soc_dev is the only one which is getting 
 updated?  
>>>
>>> Yes, looks like a mistake. Thanks! And sorry for delayed reply.  
>>
>> No problems - thanks for confirmation.
>> I have gone through almost complete series and as and when you rebase it, it 
>> would have my ACK.
> 
> OK, thanks. That's what I am playing with right now. I've rebased on v3 of 
> this patch. There will
> be some more tests in my v2.
> 
>> rte_driver patchset which I sent last are broken - I will publish an updated 
>> version very soon.
> 
> I am surprised that you've changed the args to RTE_EAL_PCI_REGISTER... Are 
> you sure about this step?
> I wrote that I'll change it myself for v2 for SoC to accept name and pointer 
> as it was originally for PCI...

I have sent across a v6 of the rte_device/driver change set.
Can you see if that is in-line with your expectations as well as the series [1] 
posted by you recently?
I was making changes for vdev but for now I have ignored them as your series 
already includes those changes.

I used your patches and based them over the v6 rte_device patchset - besides 
some minor conflicts, its seems to merge fine.

[1] http://dpdk.org/ml/archives/dev/2016-July/043645.html

> 
> Jan
> 

-
Shreyansh



[dpdk-dev] [PATCH] examples/ipsec-secgw: fix inbound segfault

2016-07-12 Thread Sergio Gonzalez Monroy
When sending Inbound non IPSec traffic that matches an Inbound Security
Policy set to Protect, the code will check that the SPI of the packet
and the associated Security Association match.

That check should only be done for IPSec packets and results in SEGFAULT
when done on non IPSec packets.

Fixes: 906257e965b7 ("examples/ipsec-secgw: support IPv6")

Signed-off-by: Sergio Gonzalez Monroy 
---
 examples/ipsec-secgw/ipsec-secgw.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/examples/ipsec-secgw/ipsec-secgw.c 
b/examples/ipsec-secgw/ipsec-secgw.c
index f78743d..1ca144b 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -384,7 +384,8 @@ send_single_packet(struct rte_mbuf *m, uint8_t port)
 }

 static inline void
-inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa, struct traffic_type *ip)
+inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa, struct traffic_type *ip,
+   uint16_t lim)
 {
struct rte_mbuf *m;
uint32_t i, j, res, sa_idx;
@@ -399,15 +400,15 @@ inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa, 
struct traffic_type *ip)
for (i = 0; i < ip->num; i++) {
m = ip->pkts[i];
res = ip->res[i];
-   if (res & DISCARD) {
-   rte_pktmbuf_free(m);
-   continue;
-   }
if (res & BYPASS) {
ip->pkts[j++] = m;
continue;
}
-   /* Check return SA SPI matches pkt SPI */
+   if (res & DISCARD || i < lim) {
+   rte_pktmbuf_free(m);
+   continue;
+   }
+   /* Only check SPI match for processed IPSec packets */
sa_idx = ip->res[i] & PROTECT_MASK;
if (sa_idx == 0 || !inbound_sa_check(sa, m, sa_idx)) {
rte_pktmbuf_free(m);
@@ -423,11 +424,14 @@ process_pkts_inbound(struct ipsec_ctx *ipsec_ctx,
struct ipsec_traffic *traffic)
 {
struct rte_mbuf *m;
-   uint16_t idx, nb_pkts_in, i;
+   uint16_t idx, nb_pkts_in, i, n_ip4, n_ip6;

nb_pkts_in = ipsec_inbound(ipsec_ctx, traffic->ipsec.pkts,
traffic->ipsec.num, MAX_PKT_BURST);

+   n_ip4 = traffic->ip4.num;
+   n_ip6 = traffic->ip6.num;
+
/* SP/ACL Inbound check ipsec and ip4 */
for (i = 0; i < nb_pkts_in; i++) {
m = traffic->ipsec.pkts[i];
@@ -447,9 +451,11 @@ process_pkts_inbound(struct ipsec_ctx *ipsec_ctx,
rte_pktmbuf_free(m);
}

-   inbound_sp_sa(ipsec_ctx->sp4_ctx, ipsec_ctx->sa_ctx, >ip4);
+   inbound_sp_sa(ipsec_ctx->sp4_ctx, ipsec_ctx->sa_ctx, >ip4,
+   n_ip4);

-   inbound_sp_sa(ipsec_ctx->sp6_ctx, ipsec_ctx->sa_ctx, >ip6);
+   inbound_sp_sa(ipsec_ctx->sp6_ctx, ipsec_ctx->sa_ctx, >ip6,
+   n_ip6);
 }

 static inline void
-- 
2.4.11



[dpdk-dev] [PATCH] mk: fix default rule of test subdirectory

2016-07-12 Thread Thomas Monjalon
> 2016-07-12 11:16, Pattan, Reshma:
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> > > Note that make app/test_sub (without environment variable) is preffered.
> > 
> > What is test_sub here? I could not execute the command make 
> > app/test_sub(without environment variable) . 
> 
> It is a rule. You can check it here:
>   http://dpdk.org/browse/dpdk/tree/mk/rte.sdkbuild.mk?id=11c5e45#n93

The %_sub rule should match anything ending with _sub.
The syntax is "make _sub".


[dpdk-dev] mutli process C/S model example init failed on xen dom0 with dpdk-16.07 rc2 package

2016-07-12 Thread Olivier MATZ
Hi Huilong,


On 07/12/2016 11:22 AM, Xu, HuilongX wrote:
> Hi all,
>
> I run mutli procee C/S model example failed on xen dom0. Does anyone
> give me some suggest how to debug it?
>
> Thanks a lot
>
> test environment:
>
>OS: 3.17.4-301.fc21.x86_64
>
> Gcc version: gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC)
>
> Package :dpdk.16.07-rc1.tar.gz
>
> Target: x86_64-native-linuxapp-gcc
>
> Compile switch: enable CONFIG_RTE_LIBRTE_XEN_DOM0
>
> Xen version:4.4.1
>
> Test cmdline and result:
>
> /examples/multi_process/client_server_mp/mp_server/mp_server/x86_64-native-linuxapp-gcc/mp_server
> -c f -n 4 --xen-dom0 -- -p 0x3 -n 2
> EAL: Detected 72 lcore(s)
> EAL: Probing VFIO support...
> PMD: bnxt_rte_pmd_init() called for (null)
> EAL: PCI device :01:00.0 on NUMA socket 0
> EAL: probe driver: 8086:1521 rte_igb_pmd
> EAL: PCI device :01:00.1 on NUMA socket 0
> EAL: probe driver: 8086:1521 rte_igb_pmd
> EAL: PCI device :04:00.0 on NUMA socket 0
> EAL: probe driver: 8086:10fb rte_ixgbe_pmd
> EAL: PCI device :04:00.1 on NUMA socket 0
> EAL: probe driver: 8086:10fb rte_ixgbe_pmd
> Creating mbuf pool 'MProc_pktmbuf_pool' [6144 mbufs] ...
> Port 0 init ... Segmentation fault (core dumped)
>

I reproduced the issue on my platform. In my case, the crash occurs in 
rx_queue_setup():

 /* Free memory prior to re-allocation if needed. */
 if (dev->data->rx_queues[queue_idx] != NULL) {
=>  em_rx_queue_release(dev->data->rx_queues[queue_idx]);
 dev->data->rx_queues[queue_idx] = NULL;
 }

I don't this we should go in that area for the first rx queue 
initialization. I suspect it could be related to this commit:
http://dpdk.org/browse/dpdk/commit/?id=ea0bddbd14e68f

I think we cannot expect that memory is initialized at 0 when using Xen 
dom0. If I add the following (dirty) patch, I don't see a crash anymore:

--- a/lib/librte_eal/common/eal_common_memzone.c
+++ b/lib/librte_eal/common/eal_common_memzone.c
@@ -258,6 +258,8 @@ memzone_reserve_aligned_thread_unsafe(const char 
*name, size_t len,
 mz->flags = 0;
 mz->memseg_id = elem->ms - 
rte_eal_get_configuration()->mem_config->memseg;

+   memset(mz->addr, 0, mz->len);
+
 return mz;
  }

--- a/lib/librte_eal/common/rte_malloc.c
+++ b/lib/librte_eal/common/rte_malloc.c
@@ -123,7 +123,13 @@ rte_malloc(const char *type, size_t size, unsigned 
align)
  void *
  rte_zmalloc_socket(const char *type, size_t size, unsigned align, int 
socket)
  {
-   return rte_malloc_socket(type, size, align, socket);
+   void *x = rte_malloc_socket(type, size, align, socket);
+
+   if (x == NULL)
+   return NULL;
+
+   memset(x, 0, size);
+   return x;
  }

  /*


Sergio, could you have a look at it?

Regards,
Olivier


[dpdk-dev] [PATCH v1 28/28] ether: support SoC device/driver

2016-07-12 Thread Jan Viktorin
On Tue, 12 Jul 2016 14:15:17 +0530
Shreyansh jain  wrote:

> Hi Jan,
> 
> On Monday 04 July 2016 08:06 PM, Jan Viktorin wrote:
> > On Mon, 4 Jul 2016 19:57:18 +0530
> > Shreyansh jain  wrote:
> > 
> > [...]
> >   
> > @@ -1431,7 +1524,7 @@ rte_eth_dev_info_get(uint8_t port_id, struct 
> > rte_eth_dev_info *dev_info)
> >  
> > RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
> > (*dev->dev_ops->dev_infos_get)(dev, dev_info);
> > -   dev_info->pci_dev = dev->pci_dev;
> > +   dev_info->soc_dev = dev->soc_dev;  
> 
>  I think both the members, pci_dev and soc_dev, should be updated by this 
>  call.
>  Is there some specific reason why soc_dev is the only one which is 
>  getting updated?
> >>>
> >>> Yes, looks like a mistake. Thanks! And sorry for delayed reply.
> >>
> >> No problems - thanks for confirmation.
> >> I have gone through almost complete series and as and when you rebase it, 
> >> it would have my ACK.  
> > 
> > OK, thanks. That's what I am playing with right now. I've rebased on v3 of 
> > this patch. There will
> > be some more tests in my v2.
> >   
> >> rte_driver patchset which I sent last are broken - I will publish an 
> >> updated version very soon.  
> > 
> > I am surprised that you've changed the args to RTE_EAL_PCI_REGISTER... Are 
> > you sure about this step?
> > I wrote that I'll change it myself for v2 for SoC to accept name and 
> > pointer as it was originally for PCI...  
> 
> I have sent across a v6 of the rte_device/driver change set.
> Can you see if that is in-line with your expectations as well as the series 
> [1] posted by you recently?
> I was making changes for vdev but for now I have ignored them as your series 
> already includes those changes.
> 
> I used your patches and based them over the v6 rte_device patchset - besides 
> some minor conflicts, its seems to merge fine.
> 
> [1] http://dpdk.org/ml/archives/dev/2016-July/043645.html

I will check it as soon as possible. Thanks.

Jan

> 
> > 
> > Jan
> >   
> 
> -
> Shreyansh
> 



-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic


[dpdk-dev] [PATCH] net/enic: fix Tx and Rx queue stop and start

2016-07-12 Thread John Daley
The exported device start and stop functions where not setting the queue
states to RTE_ETH_QUEUE_STATE_STARTED and RTE_ETH_QUEUE_STATE_STOPPED.
After starting the device, the RTE queue stop function would not call
the enic queue stop function since queue was already marked as stopped.

Put queue state updates in the lower level queue start/stop functions
which are called by both device and queue start/stop functions.

Fixes: fefed3d1e62c ("enic: new driver")

Reviewed-by: Nelson Escobar 
Signed-off-by: John Daley 
---
 drivers/net/enic/enic_ethdev.c |  6 --
 drivers/net/enic/enic_main.c   | 22 ++
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 3c87b49..f410f84 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -196,7 +196,6 @@ static int enicpmd_dev_tx_queue_start(struct rte_eth_dev 
*eth_dev,
ENICPMD_FUNC_TRACE();

enic_start_wq(enic, queue_idx);
-   eth_dev->data->tx_queue_state[queue_idx] = RTE_ETH_QUEUE_STATE_STARTED;

return 0;
 }
@@ -212,8 +211,6 @@ static int enicpmd_dev_tx_queue_stop(struct rte_eth_dev 
*eth_dev,
ret = enic_stop_wq(enic, queue_idx);
if (ret)
dev_err(enic, "error in stopping wq %d\n", queue_idx);
-   else
-   eth_dev->data->tx_queue_state[queue_idx] = 
RTE_ETH_QUEUE_STATE_STOPPED;

return ret;
 }
@@ -226,7 +223,6 @@ static int enicpmd_dev_rx_queue_start(struct rte_eth_dev 
*eth_dev,
ENICPMD_FUNC_TRACE();

enic_start_rq(enic, queue_idx);
-   eth_dev->data->rx_queue_state[queue_idx] = RTE_ETH_QUEUE_STATE_STARTED;

return 0;
 }
@@ -242,8 +238,6 @@ static int enicpmd_dev_rx_queue_stop(struct rte_eth_dev 
*eth_dev,
ret = enic_stop_rq(enic, queue_idx);
if (ret)
dev_err(enic, "error in stopping rq %d\n", queue_idx);
-   else
-   eth_dev->data->rx_queue_state[queue_idx] = 
RTE_ETH_QUEUE_STATE_STOPPED;

return ret;
 }
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index d8669cc..425f55d 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -518,30 +518,41 @@ void enic_free_rq(void *rxq)

 void enic_start_wq(struct enic *enic, uint16_t queue_idx)
 {
+   struct rte_eth_dev *eth_dev = enic->rte_dev;
vnic_wq_enable(>wq[queue_idx]);
+   eth_dev->data->tx_queue_state[queue_idx] = RTE_ETH_QUEUE_STATE_STARTED;
 }

 int enic_stop_wq(struct enic *enic, uint16_t queue_idx)
 {
-   return vnic_wq_disable(>wq[queue_idx]);
+   struct rte_eth_dev *eth_dev = enic->rte_dev;
+   int ret;
+
+   ret = vnic_wq_disable(>wq[queue_idx]);
+   if (ret)
+   return ret;
+
+   eth_dev->data->tx_queue_state[queue_idx] = RTE_ETH_QUEUE_STATE_STOPPED;
+   return 0;
 }

 void enic_start_rq(struct enic *enic, uint16_t queue_idx)
 {
struct vnic_rq *rq_sop = >rq[enic_sop_rq(queue_idx)];
struct vnic_rq *rq_data = >rq[rq_sop->data_queue_idx];
+   struct rte_eth_dev *eth_dev = enic->rte_dev;

if (rq_data->in_use)
vnic_rq_enable(rq_data);
rte_mb();
vnic_rq_enable(rq_sop);
-
+   eth_dev->data->rx_queue_state[queue_idx] = RTE_ETH_QUEUE_STATE_STARTED;
 }

 int enic_stop_rq(struct enic *enic, uint16_t queue_idx)
 {
int ret1 = 0, ret2 = 0;
-
+   struct rte_eth_dev *eth_dev = enic->rte_dev;
struct vnic_rq *rq_sop = >rq[enic_sop_rq(queue_idx)];
struct vnic_rq *rq_data = >rq[rq_sop->data_queue_idx];

@@ -552,8 +563,11 @@ int enic_stop_rq(struct enic *enic, uint16_t queue_idx)

if (ret2)
return ret2;
-   else
+   else if (ret1)
return ret1;
+
+   eth_dev->data->rx_queue_state[queue_idx] = RTE_ETH_QUEUE_STATE_STOPPED;
+   return 0;
 }

 int enic_alloc_rq(struct enic *enic, uint16_t queue_idx,
-- 
2.7.0



[dpdk-dev] [PATCH] mk: fix default rule of test subdirectory

2016-07-12 Thread Thomas Monjalon
When using "make -C app/test" (with RTE_SDK/RTE_TARGET adjusted)
without specifying the rule (all), the build is not done.
Indeed the default rule is not "all" anymore since there are some
rules added for external resources link.

It is fixed by adding a reference to "all" at the top of the file
which makes it the default rule.

Note that make app/test_sub (without environment variable) is preffered.

Fixes: ab64f5df8004 ("app/test: support resources externally linked")

Reported-by: Reshma Pattan 
Signed-off-by: Thomas Monjalon 
---
 app/test/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/app/test/Makefile b/app/test/Makefile
index 2de8c7a..6015b19 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -33,6 +33,9 @@ include $(RTE_SDK)/mk/rte.vars.mk

 ifeq ($(CONFIG_RTE_APP_TEST),y)

+# default rule
+all:
+
 # Define an externally linked resource. A linked resource is an arbitrary
 # file that is linked into the test binary. The application refers to this
 # resource by name. The linked generates identifiers beg_ and end_
-- 
2.7.0



[dpdk-dev] Compiling DPDK is not working on Red Hat 6.7

2016-07-12 Thread Christian Ehrhardt
Hi,
checking "man clock_gettime" I see: "Link with -lrt (only for glibc
versions before 2.17)."

RH 6.7 is at glibc 2.12, I haven't check the build, but you might easily
run the make with V=1 and see the call.
Check if it contains -lrt for the linking step.




Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Tue, Jul 12, 2016 at 12:02 PM, Raslan Darawsheh 
wrote:

> Hi,
>
> When trying to compile DPDK on Red Hat Enterprise Linux Server release 6.7
> (Santiago) it fails to compile.
>
> This is the compilation error that is being seen:
> LD test
> /download/dpdk/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_timer.o):
> In function `get_tsc_freq':
> eal_timer.c:(.text+0x152): undefined reference to `clock_gettime'
> eal_timer.c:(.text+0x190): undefined reference to `clock_gettime'
> /download/dpdk/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_alarm.o):
> In function `rte_eal_alarm_set':
> eal_alarm.c:(.text+0x382): undefined reference to `clock_gettime'
> /download/dpdk/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_alarm.o):
> In function `eal_alarm_callback':
> eal_alarm.c:(.text+0x5e2): undefined reference to `clock_gettime'
> collect2: ld returned 1 exit status
> make[5]: *** [test] Error 1
> make[4]: *** [test] Error 2
> make[3]: *** [app] Error 2
> make[2]: *** [all] Error 2
> make[1]: *** [pre_install] Error 2
> make: *** [install] Error 2
>
> Kindest regards
> Raslan Darawsheh
>


[dpdk-dev] [PATCH] net/virtio-user: Fix missing brackets in if condition

2016-07-12 Thread Maxime Coquelin

On 07/12/2016 11:35 AM, Thomas Monjalon wrote:
> Hi,
>
> 2016-07-12 11:30, Maxime Coquelin:
>> The error is reported using test build script:
>>
>> $ scripts/test-build.sh x86_64-native-linuxapp-gcc
>> ...
>> drivers/net/virtio/virtio_user_ethdev.c: In function 
>> ?virtio_user_pmd_devinit?:
>> drivers/net/virtio/virtio_user_ethdev.c:345:2: error: this ?if? clause does 
>> not guard... [-Werror=misleading-indentation]
> Are you using gcc 6 ?
Yes:
$ gcc --version
gcc (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3)



[dpdk-dev] [PATCH] net/virtio-user: Fix missing brackets in if condition

2016-07-12 Thread Thomas Monjalon
Hi,

2016-07-12 11:30, Maxime Coquelin:
> The error is reported using test build script:
> 
> $ scripts/test-build.sh x86_64-native-linuxapp-gcc
> ...
> drivers/net/virtio/virtio_user_ethdev.c: In function 
> ?virtio_user_pmd_devinit?:
> drivers/net/virtio/virtio_user_ethdev.c:345:2: error: this ?if? clause does 
> not guard... [-Werror=misleading-indentation]

Are you using gcc 6 ?


[dpdk-dev] Compiling DPDK is not working on Red Hat 6.7

2016-07-12 Thread Raslan Darawsheh
I think the option is there as you see:

== Build app/test
gcc -m64 -pthread  -march=native -DRTE_MACHINE_CPUFLAG_SSE 
-DRTE_MACHINE_CPUFLAG_SSE2 -DRTE_MACHINE_CPUFLAG_SSE3 
-DRTE_MACHINE_CPUFLAG_SSSE3 -DRTE_MACHINE_CPUFLAG_SSE4_1 
-DRTE_MACHINE_CPUFLAG_SSE4_2 -DRTE_MACHINE_CPUFLAG_AES 
-DRTE_MACHINE_CPUFLAG_PCLMULQDQ -DRTE_MACHINE_CPUFLAG_AVX  
-I/tmp/dpdk/x86_64-native-linuxapp-gcc/include -include 
/tmp/dpdk/x86_64-native-linuxapp-gcc/include/rte_config.h -O3 -W -Wall 
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wold-style-definition -Wpointer-arith -Wcast-align -Wnested-externs 
-Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef -Wwrite-strings 
-Werror -Wno-missing-field-initializers -Wno-uninitialized -D_GNU_SOURCE  
-Wl,-Map=test.map,--cref -o test commands.o test.o resource.o test_resource.o 
test_resource_c.res.o test_prefetch.o test_byteorder.o test_per_lcore.o 
test_atomic.o test_malloc.o test_cycles.o test_spinlock.o test_memory.o 
test_memzone.o test_ring.o test_ring_perf.o test_pmd_perf.o test_rwlock.o 
test_timer.o test_timer_perf.o test_timer_racecond.o test_mempool.o 
test_mempool_perf.o test_mbuf.o test_logs.o test_memcpy.o test_memcpy_perf.o 
test_hash.o test_thash.o test_hash_perf.o test_hash_functions.o 
test_hash_scaling.o test_hash_multiwriter.o test_debug.o test_errno.o 
test_tailq.o test_string_fns.o test_cpuflags.o test_mp_secondary.o 
test_eal_flags.o test_eal_fs.o test_alarm.o test_interrupts.o test_version.o 
test_func_reentrancy.o test_cmdline.o test_cmdline_num.o 
test_cmdline_etheraddr.o test_cmdline_portlist.o test_cmdline_ipaddr.o 
test_cmdline_cirbuf.o test_cmdline_string.o test_cmdline_lib.o test_red.o 
test_sched.o test_meter.o test_kni.o test_power.o test_power_acpi_cpufreq.o 
test_power_kvm_vm.o test_common.o test_distributor.o test_distributor_perf.o 
test_reorder.o test_devargs.o virtual_pmd.o packet_burst_generator.o test_acl.o 
test_link_bonding.o test_link_bonding_mode4.o test_link_bonding_rssconf.o 
test_pmd_ring.o test_pmd_ring_perf.o test_kvargs.o -Wl,-export-dynamic 
-Wl,-export-dynamic -Wl,-export-dynamic 
-L/tmp/dpdk/x86_64-native-linuxapp-gcc/lib -Wl,--as-needed  -Wl,-lrt -Wl,-lm 
-L/tmp/dpdk/x86_64-native-linuxapp-gcc/lib -Wl,-lrte_kni -Wl,-lrte_port 
-Wl,-lrte_pdump -Wl,-lrte_distributor -Wl,-lrte_reorder -Wl,-lrte_ip_frag 
-Wl,-lrte_meter -Wl,-lrte_sched -Wl,--whole-archive -Wl,-lrte_acl 
-Wl,--no-whole-archive -Wl,-lrte_jobstats -Wl,-lrte_power -Wl,--whole-archive 
-Wl,-lrte_timer -Wl,-lrte_hash -Wl,-lrte_vhost -Wl,-lrte_kvargs -Wl,-lrte_mbuf 
-Wl,-lethdev -Wl,-lrte_mempool -Wl,-lrte_ring -Wl,-lrte_eal -Wl,-lrte_cmdline 
-Wl,-lrte_cfgfile -Wl,-lrte_pmd_bond -Wl,-lrte_pmd_af_packet 
-Wl,-lrte_pmd_cxgbe -Wl,-lrte_pmd_e1000 -Wl,-lrte_pmd_ena -Wl,-lrte_pmd_enic 
-Wl,-lrte_pmd_fm10k -Wl,-lrte_pmd_ixgbe -Wl,-lrte_pmd_mlx5 -Wl,-libverbs 
-Wl,-lrte_pmd_null -Wl,-lrte_pmd_ring -Wl,-lrte_pmd_virtio -Wl,-lrte_pmd_vhost 
-Wl,-lrte_pmd_vmxnet3_uio -Wl,--no-whole-archive -Wl,-ldl
/tmp/dpdk/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_timer.o): In function 
`get_tsc_freq':
eal_timer.c:(.text+0x152): undefined reference to `clock_gettime'
eal_timer.c:(.text+0x190): undefined reference to `clock_gettime'
/tmp/dpdk/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_alarm.o): In function 
`rte_eal_alarm_set':
eal_alarm.c:(.text+0x382): undefined reference to `clock_gettime'
/tmp/dpdk/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_alarm.o): In function 
`eal_alarm_callback':
eal_alarm.c:(.text+0x5e2): undefined reference to `clock_gettime'
collect2: ld returned 1 exit status
make[5]: *** [test] Error 1
make[4]: *** [test] Error 2
make[3]: *** [app] Error 2
make[2]: *** [all] Error 2
make[1]: *** [pre_install] Error 2
make: *** [install] Error 2 but

kindest regards
Raslan Darawsheh

From: Christian Ehrhardt [mailto:christian.ehrha...@canonical.com]
Sent: Tuesday, July 12, 2016 1:10 PM
To: Raslan Darawsheh
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] Compiling DPDK is not working on Red Hat 6.7

Hi,
checking "man clock_gettime" I see: "Link with -lrt (only for glibc versions 
before 2.17)."

RH 6.7 is at glibc 2.12, I haven't check the build, but you might easily run 
the make with V=1 and see the call.
Check if it contains -lrt for the linking step.




Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Tue, Jul 12, 2016 at 12:02 PM, Raslan Darawsheh mailto:rasland at mellanox.com>> wrote:
Hi,

When trying to compile DPDK on Red Hat Enterprise Linux Server release 6.7 
(Santiago) it fails to compile.

This is the compilation error that is being seen:
LD test
/download/dpdk/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_timer.o): In 
function `get_tsc_freq':
eal_timer.c:(.text+0x152): undefined reference to `clock_gettime'
eal_timer.c:(.text+0x190): undefined reference to `clock_gettime'
/download/dpdk/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_alarm.o): In 
function `rte_eal_alarm_set':
eal_alarm.c:(.text+0x382): 

[dpdk-dev] DPDK on Xen maintenance

2016-07-12 Thread Thomas Monjalon
Hi all,

We are facing some issues with Xen dom0.
Some were fixed in RC2:
http://dpdk.org/ml/archives/dev/2016-July/043760.html
and there still have some other issues.

It seems Xen is becoming less attractive:
- we do not have a lot of test reports or feedbacks
- there is no maintainer for DPDK on Xen
- we are still waiting for the Xen netfront PMD

I wonder wether it still makes sense to maintain this code or not?
In case of positive reply, it would be nice to have the name of
someone responsible for this code, i.e. a maintainer.

Thanks


[dpdk-dev] [PATCH v6 17/17] ethdev: get rid of device type

2016-07-12 Thread Shreyansh Jain
Now that hotplug has been moved to eal, there is no reason to keep the device
type in this layer.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 app/test/virtual_pmd.c|  2 +-
 drivers/net/af_packet/rte_eth_af_packet.c |  2 +-
 drivers/net/bonding/rte_eth_bond_api.c|  2 +-
 drivers/net/cxgbe/cxgbe_main.c|  2 +-
 drivers/net/mlx4/mlx4.c   |  2 +-
 drivers/net/mlx5/mlx5.c   |  2 +-
 drivers/net/mpipe/mpipe_tilegx.c  |  2 +-
 drivers/net/null/rte_eth_null.c   |  2 +-
 drivers/net/pcap/rte_eth_pcap.c   |  2 +-
 drivers/net/ring/rte_eth_ring.c   |  2 +-
 drivers/net/vhost/rte_eth_vhost.c |  2 +-
 drivers/net/virtio/virtio_user_ethdev.c   |  2 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c |  2 +-
 examples/ip_pipeline/init.c   | 22 --
 lib/librte_ether/rte_ethdev.c |  5 ++---
 lib/librte_ether/rte_ethdev.h | 15 +--
 16 files changed, 16 insertions(+), 52 deletions(-)

diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c
index b4bd2f2..8a1f0d0 100644
--- a/app/test/virtual_pmd.c
+++ b/app/test/virtual_pmd.c
@@ -581,7 +581,7 @@ virtual_ethdev_create(const char *name, struct ether_addr 
*mac_addr,
goto err;

/* reserve an ethdev entry */
-   eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_PCI);
+   eth_dev = rte_eth_dev_allocate(name);
if (eth_dev == NULL)
goto err;

diff --git a/drivers/net/af_packet/rte_eth_af_packet.c 
b/drivers/net/af_packet/rte_eth_af_packet.c
index f795566..d629ee3 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -666,7 +666,7 @@ rte_pmd_init_internals(const char *name,
}

/* reserve an ethdev entry */
-   *eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_VIRTUAL);
+   *eth_dev = rte_eth_dev_allocate(name);
if (*eth_dev == NULL)
goto error;

diff --git a/drivers/net/bonding/rte_eth_bond_api.c 
b/drivers/net/bonding/rte_eth_bond_api.c
index 203ebe9..8514652 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -189,7 +189,7 @@ rte_eth_bond_create(const char *name, uint8_t mode, uint8_t 
socket_id)
}

/* reserve an ethdev entry */
-   eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_VIRTUAL);
+   eth_dev = rte_eth_dev_allocate(name);
if (eth_dev == NULL) {
RTE_BOND_LOG(ERR, "Unable to allocate rte_eth_dev");
goto err;
diff --git a/drivers/net/cxgbe/cxgbe_main.c b/drivers/net/cxgbe/cxgbe_main.c
index ceaf5ab..922155b 100644
--- a/drivers/net/cxgbe/cxgbe_main.c
+++ b/drivers/net/cxgbe/cxgbe_main.c
@@ -1150,7 +1150,7 @@ int cxgbe_probe(struct adapter *adapter)
 */

/* reserve an ethdev entry */
-   pi->eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_PCI);
+   pi->eth_dev = rte_eth_dev_allocate(name);
if (!pi->eth_dev)
goto out_free;

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 2bed4de..b333ad6 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -5803,7 +5803,7 @@ mlx4_pci_devinit(struct rte_pci_driver *pci_drv, struct 
rte_pci_device *pci_dev)

snprintf(name, sizeof(name), "%s port %u",
 ibv_get_device_name(ibv_dev), port);
-   eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_PCI);
+   eth_dev = rte_eth_dev_allocate(name);
}
if (eth_dev == NULL) {
ERROR("can not allocate rte ethdev");
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 3658769..ebad7cb 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -617,7 +617,7 @@ mlx5_pci_devinit(struct rte_pci_driver *pci_drv, struct 
rte_pci_device *pci_dev)

snprintf(name, sizeof(name), "%s port %u",
 ibv_get_device_name(ibv_dev), port);
-   eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_PCI);
+   eth_dev = rte_eth_dev_allocate(name);
}
if (eth_dev == NULL) {
ERROR("can not allocate rte ethdev");
diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index 93f8730..c0d0e3b 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -1587,7 +1587,7 @@ rte_pmd_mpipe_devinit(const char *ifname,
return -ENODEV;
}

-   eth_dev = rte_eth_dev_allocate(ifname, RTE_ETH_DEV_VIRTUAL);
+   eth_dev = rte_eth_dev_allocate(ifname);
if (!eth_dev) {
RTE_LOG(ERR, PMD, "%s: Failed to allocate device.\n", ifname);
 

[dpdk-dev] [PATCH v6 16/17] ethdev: convert to eal hotplug

2016-07-12 Thread Shreyansh Jain
Remove bus logic from ethdev hotplug by using eal for this.

Current api is preserved:
- the last port that has been created is tracked to return it to the
  application when attaching,
- the internal device name is reused when detaching.

We can not get rid of ethdev hotplug yet since we still need some mechanism
to inform applications of port creation/removal to substitute for ethdev
hotplug api.

dev_type field in struct rte_eth_dev and rte_eth_dev_allocate are kept as
is, but this information is not needed anymore and is removed in the following
commit.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_ether/rte_ethdev.c | 207 +++---
 1 file changed, 33 insertions(+), 174 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index a667012..8d14fd7 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -72,6 +72,7 @@
 static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
 struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
 static struct rte_eth_dev_data *rte_eth_dev_data;
+static uint8_t eth_dev_last_created_port;
 static uint8_t nb_ports;

 /* spinlock for eth device callbacks */
@@ -216,6 +217,7 @@ rte_eth_dev_allocate(const char *name, enum 
rte_eth_dev_type type)
eth_dev->data->port_id = port_id;
eth_dev->attached = DEV_ATTACHED;
eth_dev->dev_type = type;
+   eth_dev_last_created_port = port_id;
nb_ports++;
return eth_dev;
 }
@@ -347,27 +349,6 @@ rte_eth_dev_count(void)
return nb_ports;
 }

-static enum rte_eth_dev_type
-rte_eth_dev_get_device_type(uint8_t port_id)
-{
-   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, RTE_ETH_DEV_UNKNOWN);
-   return rte_eth_devices[port_id].dev_type;
-}
-
-static int
-rte_eth_dev_get_addr_by_port(uint8_t port_id, struct rte_pci_addr *addr)
-{
-   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
-
-   if (addr == NULL) {
-   RTE_PMD_DEBUG_TRACE("Null pointer is specified\n");
-   return -EINVAL;
-   }
-
-   *addr = rte_eth_devices[port_id].pci_dev->addr;
-   return 0;
-}
-
 int
 rte_eth_dev_get_name_by_port(uint8_t port_id, char *name)
 {
@@ -413,34 +394,6 @@ rte_eth_dev_get_port_by_name(const char *name, uint8_t 
*port_id)
 }

 static int
-rte_eth_dev_get_port_by_addr(const struct rte_pci_addr *addr, uint8_t *port_id)
-{
-   int i;
-   struct rte_pci_device *pci_dev = NULL;
-
-   if (addr == NULL) {
-   RTE_PMD_DEBUG_TRACE("Null pointer is specified\n");
-   return -EINVAL;
-   }
-
-   *port_id = RTE_MAX_ETHPORTS;
-
-   for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
-
-   pci_dev = rte_eth_devices[i].pci_dev;
-
-   if (pci_dev &&
-   !rte_eal_compare_pci_addr(_dev->addr, addr)) {
-
-   *port_id = i;
-
-   return 0;
-   }
-   }
-   return -ENODEV;
-}
-
-static int
 rte_eth_dev_is_detachable(uint8_t port_id)
 {
uint32_t dev_flags;
@@ -465,124 +418,45 @@ rte_eth_dev_is_detachable(uint8_t port_id)
return 1;
 }

-/* attach the new physical device, then store port_id of the device */
-static int
-rte_eth_dev_attach_pdev(struct rte_pci_addr *addr, uint8_t *port_id)
-{
-   /* Invoke probe func of the driver can handle the new device. */
-   if (rte_eal_pci_probe_one(addr))
-   goto err;
-
-   if (rte_eth_dev_get_port_by_addr(addr, port_id))
-   goto err;
-
-   return 0;
-err:
-   return -1;
-}
-
-/* detach the new physical device, then store pci_addr of the device */
-static int
-rte_eth_dev_detach_pdev(uint8_t port_id, struct rte_pci_addr *addr)
-{
-   struct rte_pci_addr freed_addr;
-   struct rte_pci_addr vp;
-
-   /* get pci address by port id */
-   if (rte_eth_dev_get_addr_by_port(port_id, _addr))
-   goto err;
-
-   /* Zeroed pci addr means the port comes from virtual device */
-   vp.domain = vp.bus = vp.devid = vp.function = 0;
-   if (rte_eal_compare_pci_addr(, _addr) == 0)
-   goto err;
-
-   /* invoke devuninit func of the pci driver,
-* also remove the device from pci_device_list */
-   if (rte_eal_pci_detach(_addr))
-   goto err;
-
-   *addr = freed_addr;
-   return 0;
-err:
-   return -1;
-}
-
-/* attach the new virtual device, then store port_id of the device */
-static int
-rte_eth_dev_attach_vdev(const char *vdevargs, uint8_t *port_id)
-{
-   char *name = NULL, *args = NULL;
-   int ret = -1;
-
-   /* parse vdevargs, then retrieve device name and args */
-   if (rte_eal_parse_devargs_str(vdevargs, , ))
-   goto end;
-
-   /* walk around dev_driver_list to find the driver of the device,
-* then invoke probe function of the driver.
-* rte_eal_vdev_init() updates port_id 

[dpdk-dev] [PATCH v6 15/17] eal: add hotplug operations for pci and vdev

2016-07-12 Thread Shreyansh Jain
Hotplug which deals with resources should come from the layer that already
handles them, i.e. EAL.

For both attach and detach operations, 'name' is used to select the bus
that will handle the request.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |  2 ++
 lib/librte_eal/common/eal_common_dev.c  | 47 +
 lib/librte_eal/common/include/rte_dev.h | 25 +
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |  2 ++
 4 files changed, 76 insertions(+)

diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map 
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 1852c4a..6f9324f 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -159,5 +159,7 @@ DPDK_16.07 {
rte_keepalive_mark_sleep;
rte_keepalive_register_relay_callback;
rte_thread_setname;
+   rte_eal_dev_attach;
+   rte_eal_dev_detach;

 } DPDK_16.04;
diff --git a/lib/librte_eal/common/eal_common_dev.c 
b/lib/librte_eal/common/eal_common_dev.c
index a8a4146..14c6cf1 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -150,3 +150,50 @@ rte_eal_vdev_uninit(const char *name)
RTE_LOG(ERR, EAL, "no driver found for %s\n", name);
return -EINVAL;
 }
+
+int rte_eal_dev_attach(const char *name, const char *devargs)
+{
+   struct rte_pci_addr addr;
+   int ret = -1;
+
+   if (name == NULL || devargs == NULL) {
+   RTE_LOG(ERR, EAL, "Invalid device arguments provided\n");
+   return ret;
+   }
+
+   if (eal_parse_pci_DomBDF(name, ) == 0) {
+   if (rte_eal_pci_probe_one() < 0)
+   goto err;
+
+   } else {
+   if (rte_eal_vdev_init(name, devargs))
+   goto err;
+   }
+
+   return 0;
+
+err:
+   RTE_LOG(ERR, EAL, "Driver cannot attach the device\n");
+   return ret;
+}
+
+int rte_eal_dev_detach(const char *name)
+{
+   struct rte_pci_addr addr;
+
+   if (name == NULL)
+   goto err;
+
+   if (eal_parse_pci_DomBDF(name, ) == 0) {
+   if (rte_eal_pci_detach() < 0)
+   goto err;
+   } else {
+   if (rte_eal_vdev_uninit(name))
+   goto err;
+   }
+   return 0;
+
+err:
+   RTE_LOG(ERR, EAL, "Driver cannot detach the device\n");
+   return -1;
+}
diff --git a/lib/librte_eal/common/include/rte_dev.h 
b/lib/librte_eal/common/include/rte_dev.h
index 994650b..2f0579c 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -178,6 +178,31 @@ int rte_eal_vdev_init(const char *name, const char *args);
  */
 int rte_eal_vdev_uninit(const char *name);

+/**
+ * Attach a resource to a registered driver.
+ *
+ * @param name
+ *   The resource name, that refers to a pci resource or some private
+ *   way of designating a resource for vdev drivers. Based on this
+ *   resource name, eal will identify a driver capable of handling
+ *   this resource and pass this resource to the driver probing
+ *   function.
+ * @param devargs
+ *   Device arguments to be passed to the driver.
+ * @return
+ *   0 on success, negative on error.
+ */
+int rte_eal_dev_attach(const char *name, const char *devargs);
+
+/**
+ * Detach a resource from its driver.
+ *
+ * @param name
+ *   Same description as for rte_eal_dev_attach().
+ *   Here, eal will call the driver detaching function.
+ */
+int rte_eal_dev_detach(const char *name);
+
 #define DRIVER_EXPORT_NAME_ARRAY(n, idx) n##idx[]

 #define DRIVER_EXPORT_NAME(name, idx) \
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map 
b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index a617b9e..db866b8 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -163,5 +163,7 @@ DPDK_16.07 {
rte_keepalive_mark_sleep;
rte_keepalive_register_relay_callback;
rte_thread_setname;
+   rte_eal_dev_attach;
+   rte_eal_dev_detach;

 } DPDK_16.04;
-- 
2.7.4



[dpdk-dev] [PATCH v6 14/17] ethdev: do not scan all pci devices on attach

2016-07-12 Thread Shreyansh Jain
No need to scan all devices, we only need to update the device being
attached.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_eal/common/eal_common_pci.c | 11 ---
 lib/librte_ether/rte_ethdev.c  |  3 ---
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_pci.c 
b/lib/librte_eal/common/eal_common_pci.c
index 58f0c74..e001837 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -339,6 +339,11 @@ rte_eal_pci_probe_one(const struct rte_pci_addr *addr)
if (addr == NULL)
return -1;

+   /* update current pci device in global list, kernel bindings might have
+* changed since last time we looked at it */
+   if (pci_update_device(addr) < 0)
+   goto err_return;
+
TAILQ_FOREACH(dev, _device_list, next) {
if (rte_eal_compare_pci_addr(>addr, addr))
continue;
@@ -351,9 +356,9 @@ rte_eal_pci_probe_one(const struct rte_pci_addr *addr)
return -1;

 err_return:
-   RTE_LOG(WARNING, EAL, "Requested device " PCI_PRI_FMT
-   " cannot be used\n", dev->addr.domain, dev->addr.bus,
-   dev->addr.devid, dev->addr.function);
+   RTE_LOG(WARNING, EAL,
+   "Requested device " PCI_PRI_FMT " cannot be used\n",
+   addr->domain, addr->bus, addr->devid, addr->function);
return -1;
 }

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 147b26f..a667012 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -469,9 +469,6 @@ rte_eth_dev_is_detachable(uint8_t port_id)
 static int
 rte_eth_dev_attach_pdev(struct rte_pci_addr *addr, uint8_t *port_id)
 {
-   /* re-construct pci_device_list */
-   if (rte_eal_pci_scan())
-   goto err;
/* Invoke probe func of the driver can handle the new device. */
if (rte_eal_pci_probe_one(addr))
goto err;
-- 
2.7.4



[dpdk-dev] [PATCH v6 13/17] pci: add a helper to update a device

2016-07-12 Thread Shreyansh Jain
This helper updates a pci device object with latest information it can
find.
It will be used mainly for hotplug code.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_eal/bsdapp/eal/eal_pci.c | 49 +
 lib/librte_eal/common/eal_common_pci.c  |  2 --
 lib/librte_eal/common/eal_private.h | 13 +
 lib/librte_eal/common/include/rte_pci.h |  3 ++
 lib/librte_eal/linuxapp/eal/eal_pci.c   | 13 +
 5 files changed, 78 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c 
b/lib/librte_eal/bsdapp/eal/eal_pci.c
index a73cbb0..1d91c78 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -406,6 +406,55 @@ error:
return -1;
 }

+int
+pci_update_device(const struct rte_pci_addr *addr)
+{
+   int fd;
+   struct pci_conf matches[2];
+   struct pci_match_conf match = {
+   .pc_sel = {
+   .pc_domain = addr->domain,
+   .pc_bus = addr->bus,
+   .pc_dev = addr->devid,
+   .pc_func = addr->function,
+   },
+   };
+   struct pci_conf_io conf_io = {
+   .pat_buf_len = 0,
+   .num_patterns = 1,
+   .patterns = ,
+   .match_buf_len = sizeof(matches),
+   .matches = [0],
+   };
+
+   fd = open("/dev/pci", O_RDONLY);
+   if (fd < 0) {
+   RTE_LOG(ERR, EAL, "%s(): error opening /dev/pci\n", __func__);
+   goto error;
+   }
+
+   if (ioctl(fd, PCIOCGETCONF, _io) < 0) {
+   RTE_LOG(ERR, EAL, "%s(): error with ioctl on /dev/pci: %s\n",
+   __func__, strerror(errno));
+   goto error;
+   }
+
+   if (conf_io.num_matches != 1)
+   goto error;
+
+   if (pci_scan_one(fd, [0]) < 0)
+   goto error;
+
+   close(fd);
+
+   return 0;
+
+error:
+   if (fd >= 0)
+   close(fd);
+   return -1;
+}
+
 /* Read PCI config space. */
 int rte_eal_pci_read_config(const struct rte_pci_device *dev,
void *buf, size_t len, off_t offset)
diff --git a/lib/librte_eal/common/eal_common_pci.c 
b/lib/librte_eal/common/eal_common_pci.c
index 6a0f6ac..58f0c74 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -87,8 +87,6 @@ struct pci_driver_list pci_driver_list =
 struct pci_device_list pci_device_list =
TAILQ_HEAD_INITIALIZER(pci_device_list);

-#define SYSFS_PCI_DEVICES "/sys/bus/pci/devices"
-
 const char *pci_get_sysfs_path(void)
 {
const char *path = NULL;
diff --git a/lib/librte_eal/common/eal_private.h 
b/lib/librte_eal/common/eal_private.h
index 06a68f6..b8ff9c5 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -152,6 +152,19 @@ struct rte_pci_driver;
 struct rte_pci_device;

 /**
+ * Update a pci device object by asking the kernel for the latest information.
+ *
+ * This function is private to EAL.
+ *
+ * @param addr
+ * The PCI Bus-Device-Function address to look for
+ * @return
+ *   - 0 on success.
+ *   - negative on error.
+ */
+int pci_update_device(const struct rte_pci_addr *addr);
+
+/**
  * Unbind kernel driver for this device
  *
  * This function is private to EAL.
diff --git a/lib/librte_eal/common/include/rte_pci.h 
b/lib/librte_eal/common/include/rte_pci.h
index 06508fa..5c2062c 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -107,6 +107,9 @@ const char *pci_get_sysfs_path(void);
 /** Nb. of values in PCI resource format. */
 #define PCI_RESOURCE_FMT_NVAL 3

+/** Default sysfs path for PCI device search. */
+#define SYSFS_PCI_DEVICES "/sys/bus/pci/devices"
+
 /**
  * A structure describing a PCI resource.
  */
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index f0215ee..8f3ef20 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -417,6 +417,19 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t 
bus,
return 0;
 }

+int
+pci_update_device(const struct rte_pci_addr *addr)
+{
+   char filename[PATH_MAX];
+
+   snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT,
+SYSFS_PCI_DEVICES, addr->domain, addr->bus, addr->devid,
+addr->function);
+
+   return pci_scan_one(filename, addr->domain, addr->bus, addr->devid,
+   addr->function);
+}
+
 /*
  * split up a pci address into its constituent parts.
  */
-- 
2.7.4



[dpdk-dev] [PATCH v6 12/17] pci: add a helper for device name

2016-07-12 Thread Shreyansh Jain
eal is a better place than crypto / ethdev for naming resources.
Add a helper in eal and make use of it in crypto / ethdev.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_cryptodev/rte_cryptodev.c| 27 ---
 lib/librte_eal/common/include/rte_pci.h | 25 +
 lib/librte_ether/rte_ethdev.c   | 24 
 3 files changed, 33 insertions(+), 43 deletions(-)

diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index d7be111..60c6384 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -367,23 +367,6 @@ rte_cryptodev_pmd_allocate(const char *name, int socket_id)
return cryptodev;
 }

-static inline int
-rte_cryptodev_create_unique_device_name(char *name, size_t size,
-   struct rte_pci_device *pci_dev)
-{
-   int ret;
-
-   if ((name == NULL) || (pci_dev == NULL))
-   return -EINVAL;
-
-   ret = snprintf(name, size, "%d:%d.%d",
-   pci_dev->addr.bus, pci_dev->addr.devid,
-   pci_dev->addr.function);
-   if (ret < 0)
-   return ret;
-   return 0;
-}
-
 int
 rte_cryptodev_pmd_release_device(struct rte_cryptodev *cryptodev)
 {
@@ -446,9 +429,8 @@ rte_cryptodev_pci_probe(struct rte_pci_driver *pci_drv,
if (cryptodrv == NULL)
return -ENODEV;

-   /* Create unique Crypto device name using PCI address */
-   rte_cryptodev_create_unique_device_name(cryptodev_name,
-   sizeof(cryptodev_name), pci_dev);
+   rte_eal_pci_device_name(_dev->addr, cryptodev_name,
+   sizeof(cryptodev_name));

cryptodev = rte_cryptodev_pmd_allocate(cryptodev_name, rte_socket_id());
if (cryptodev == NULL)
@@ -503,9 +485,8 @@ rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev)
if (pci_dev == NULL)
return -EINVAL;

-   /* Create unique device name using PCI address */
-   rte_cryptodev_create_unique_device_name(cryptodev_name,
-   sizeof(cryptodev_name), pci_dev);
+   rte_eal_pci_device_name(_dev->addr, cryptodev_name,
+   sizeof(cryptodev_name));

cryptodev = rte_cryptodev_pmd_get_named_dev(cryptodev_name);
if (cryptodev == NULL)
diff --git a/lib/librte_eal/common/include/rte_pci.h 
b/lib/librte_eal/common/include/rte_pci.h
index 3027adf..06508fa 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -82,6 +82,7 @@ extern "C" {
 #include 
 #include 

+#include 
 #include 

 TAILQ_HEAD(pci_device_list, rte_pci_device); /**< PCI devices in D-linked Q. */
@@ -95,6 +96,7 @@ const char *pci_get_sysfs_path(void);

 /** Formatting string for PCI device identifier: Ex: :00:01.0 */
 #define PCI_PRI_FMT "%.4" PRIx16 ":%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
+#define PCI_PRI_STR_SIZE sizeof(":XX:XX.X")

 /** Short formatting string, without domain, for PCI device: Ex: 00:01.0 */
 #define PCI_SHORT_PRI_FMT "%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
@@ -308,6 +310,29 @@ eal_parse_pci_DomBDF(const char *input, struct 
rte_pci_addr *dev_addr)
 }
 #undef GET_PCIADDR_FIELD

+/**
+ * Utility function to write a pci device name, this device name can later be
+ * used to retrieve the corresponding rte_pci_addr using above functions.
+ *
+ * @param addr
+ * The PCI Bus-Device-Function address
+ * @param output
+ * The output buffer string
+ * @param size
+ * The output buffer size
+ * @return
+ *  0 on success, negative on error.
+ */
+static inline void
+rte_eal_pci_device_name(const struct rte_pci_addr *addr,
+   char *output, size_t size)
+{
+   RTE_VERIFY(size >= PCI_PRI_STR_SIZE);
+   RTE_VERIFY(snprintf(output, size, PCI_PRI_FMT,
+   addr->domain, addr->bus,
+   addr->devid, addr->function) >= 0);
+}
+
 /* Compare two PCI device addresses. */
 /**
  * Utility function to compare two PCI device addresses.
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 89c7b31..147b26f 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -220,20 +220,6 @@ rte_eth_dev_allocate(const char *name, enum 
rte_eth_dev_type type)
return eth_dev;
 }

-static int
-rte_eth_dev_create_unique_device_name(char *name, size_t size,
-   struct rte_pci_device *pci_dev)
-{
-   int ret;
-
-   ret = snprintf(name, size, "%d:%d.%d",
-   pci_dev->addr.bus, pci_dev->addr.devid,
-   pci_dev->addr.function);
-   if (ret < 0)
-   return ret;
-   return 0;
-}
-
 int
 rte_eth_dev_release_port(struct rte_eth_dev *eth_dev)
 {
@@ -257,9 +243,8 @@ rte_eth_dev_pci_probe(struct rte_pci_driver *pci_drv,

eth_drv = (struct eth_driver *)pci_drv;

-   /* Create 

[dpdk-dev] [PATCH v6 11/17] eal/linux: move back interrupt thread init before setting affinity

2016-07-12 Thread Shreyansh Jain
Now that virtio pci driver is initialized in a constructor, iopl() stuff
happens early enough so that interrupt thread can be created right after
plugin loading.
This way, chelsio driver should be happy again [1].

[1] http://dpdk.org/ml/archives/dev/2015-November/028289.html

Signed-off-by: David Marchand 
Tested-by: Rahul Lakkireddy 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_eal/linuxapp/eal/eal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index fe9c704..259a7e4 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -834,6 +834,9 @@ rte_eal_init(int argc, char **argv)
if (eal_plugins_init() < 0)
rte_panic("Cannot init plugins\n");

+   if (rte_eal_intr_init() < 0)
+   rte_panic("Cannot init interrupt-handling thread\n");
+
eal_thread_init_master(rte_config.master_lcore);

ret = eal_thread_dump_affinity(cpuset, RTE_CPU_AFFINITY_STR_LEN);
@@ -845,9 +848,6 @@ rte_eal_init(int argc, char **argv)
if (rte_eal_dev_init() < 0)
rte_panic("Cannot init pmd devices\n");

-   if (rte_eal_intr_init() < 0)
-   rte_panic("Cannot init interrupt-handling thread\n");
-
RTE_LCORE_FOREACH_SLAVE(i) {

/*
-- 
2.7.4



[dpdk-dev] [PATCH v6 10/17] ethdev: get rid of eth driver register callback

2016-07-12 Thread Shreyansh Jain
Now that all pdev are pci drivers, we don't need to register ethdev drivers
through a dedicated channel.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_ether/rte_ethdev.c  | 22 --
 lib/librte_ether/rte_ethdev.h  | 12 
 lib/librte_ether/rte_ether_version.map |  1 -
 3 files changed, 35 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 25eb032..89c7b31 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -340,28 +340,6 @@ rte_eth_dev_pci_remove(struct rte_pci_device *pci_dev)
return 0;
 }

-/**
- * Register an Ethernet [Poll Mode] driver.
- *
- * Function invoked by the initialization function of an Ethernet driver
- * to simultaneously register itself as a PCI driver and as an Ethernet
- * Poll Mode Driver.
- * Invokes the rte_eal_pci_register() function to register the *pci_drv*
- * structure embedded in the *eth_drv* structure, after having stored the
- * address of the rte_eth_dev_init() function in the *devinit* field of
- * the *pci_drv* structure.
- * During the PCI probing phase, the rte_eth_dev_init() function is
- * invoked for each PCI [Ethernet device] matching the embedded PCI
- * identifiers provided by the driver.
- */
-void
-rte_eth_driver_register(struct eth_driver *eth_drv)
-{
-   eth_drv->pci_drv.devinit = rte_eth_dev_pci_probe;
-   eth_drv->pci_drv.devuninit = rte_eth_dev_pci_remove;
-   rte_eal_pci_register(_drv->pci_drv);
-}
-
 int
 rte_eth_dev_is_valid_port(uint8_t port_id)
 {
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index a2ec9d1..d2718b5 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1871,18 +1871,6 @@ struct eth_driver {
 };

 /**
- * @internal
- * A function invoked by the initialization function of an Ethernet driver
- * to simultaneously register itself as a PCI driver and as an Ethernet
- * Poll Mode Driver (PMD).
- *
- * @param eth_drv
- *   The pointer to the *eth_driver* structure associated with
- *   the Ethernet driver.
- */
-void rte_eth_driver_register(struct eth_driver *eth_drv);
-
-/**
  * Convert a numerical speed in Mbps to a bitmap flag that can be used in
  * the bitmap link_speeds of the struct rte_eth_conf
  *
diff --git a/lib/librte_ether/rte_ether_version.map 
b/lib/librte_ether/rte_ether_version.map
index c5ef869..27d8161 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -78,7 +78,6 @@ DPDK_2.2 {
rte_eth_dev_vlan_filter;
rte_eth_dev_wd_timeout_store;
rte_eth_dma_zone_reserve;
-   rte_eth_driver_register;
rte_eth_led_off;
rte_eth_led_on;
rte_eth_link;
-- 
2.7.4



[dpdk-dev] [PATCH v6 09/17] crypto: get rid of crypto driver register callback

2016-07-12 Thread Shreyansh Jain
Now that all pdev are pci drivers, we don't need to register crypto drivers
through a dedicated channel.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_cryptodev/rte_cryptodev.c   | 22 ---
 lib/librte_cryptodev/rte_cryptodev_pmd.h   | 30 --
 lib/librte_cryptodev/rte_cryptodev_version.map |  1 -
 3 files changed, 53 deletions(-)

diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index 3a75f2c..d7be111 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -535,28 +535,6 @@ rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev)
return 0;
 }

-int
-rte_cryptodev_pmd_driver_register(struct rte_cryptodev_driver *cryptodrv,
-   enum pmd_type type)
-{
-   /* Call crypto device initialization directly if device is virtual */
-   if (type == PMD_VDEV)
-   return rte_cryptodev_pci_probe((struct rte_pci_driver 
*)cryptodrv,
-   NULL);
-
-   /*
-* Register PCI driver for physical device intialisation during
-* PCI probing
-*/
-   cryptodrv->pci_drv.devinit = rte_cryptodev_pci_probe;
-   cryptodrv->pci_drv.devuninit = rte_cryptodev_pci_remove;
-
-   rte_eal_pci_register(>pci_drv);
-
-   return 0;
-}
-
-
 uint16_t
 rte_cryptodev_queue_pair_count(uint8_t dev_id)
 {
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h 
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index 3fb7c7c..99fd69e 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -491,36 +491,6 @@ rte_cryptodev_pmd_virtual_dev_init(const char *name, 
size_t dev_private_size,
 extern int
 rte_cryptodev_pmd_release_device(struct rte_cryptodev *cryptodev);

-
-/**
- * Register a Crypto [Poll Mode] driver.
- *
- * Function invoked by the initialization function of a Crypto driver
- * to simultaneously register itself as Crypto Poll Mode Driver and to either:
- *
- * a - register itself as PCI driver if the crypto device is a physical
- * device, by invoking the rte_eal_pci_register() function to
- * register the *pci_drv* structure embedded in the *crypto_drv*
- * structure, after having stored the address of the
- * rte_cryptodev_init() function in the *devinit* field of the
- * *pci_drv* structure.
- *
- * During the PCI probing phase, the rte_cryptodev_init()
- * function is invoked for each PCI [device] matching the
- * embedded PCI identifiers provided by the driver.
- *
- * b, complete the initialization sequence if the device is a virtual
- * device by calling the rte_cryptodev_init() directly passing a
- * NULL parameter for the rte_pci_device structure.
- *
- *   @param crypto_drv crypto_driver structure associated with the crypto
- * driver.
- *   @param type   pmd type
- */
-extern int
-rte_cryptodev_pmd_driver_register(struct rte_cryptodev_driver *crypto_drv,
-   enum pmd_type type);
-
 /**
  * Executes all the user application registered callbacks for the specific
  * device.
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map 
b/lib/librte_cryptodev/rte_cryptodev_version.map
index 7aa7f4e..be016d9 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -14,7 +14,6 @@ DPDK_16.04 {
rte_cryptodev_info_get;
rte_cryptodev_pmd_allocate;
rte_cryptodev_pmd_callback_process;
-   rte_cryptodev_pmd_driver_register;
rte_cryptodev_pmd_release_device;
rte_cryptodev_pmd_virtual_dev_init;
rte_cryptodev_sym_session_create;
-- 
2.7.4



[dpdk-dev] [PATCH v6 08/17] drivers: convert all pdev drivers as pci drivers

2016-07-12 Thread Shreyansh Jain
Simplify crypto and ethdev pci drivers init by using newly introduced
init macros and helpers.
Those drivers then don't need to register as "rte_driver"s anymore.

Exceptions:
- virtio and mlx* use RTE_INIT directly as they have custom initialization
  steps.
- VDEV devices are not modified - they continue to use PMD_REGISTER_DRIVER.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 drivers/crypto/qat/rte_qat_cryptodev.c  | 16 +++-
 drivers/net/bnx2x/bnx2x_ethdev.c| 34 +---
 drivers/net/bnxt/bnxt_ethdev.c  | 16 +++-
 drivers/net/cxgbe/cxgbe_ethdev.c| 24 +++--
 drivers/net/e1000/em_ethdev.c   | 16 +++-
 drivers/net/e1000/igb_ethdev.c  | 39 +---
 drivers/net/ena/ena_ethdev.c| 17 +++-
 drivers/net/enic/enic_ethdev.c  | 23 +++--
 drivers/net/fm10k/fm10k_ethdev.c| 23 +++--
 drivers/net/i40e/i40e_ethdev.c  | 24 +++--
 drivers/net/i40e/i40e_ethdev_vf.c   | 25 +++---
 drivers/net/ixgbe/ixgbe_ethdev.c| 46 +
 drivers/net/mlx4/mlx4.c | 15 +++
 drivers/net/mlx5/mlx5.c | 14 +++---
 drivers/net/nfp/nfp_net.c   | 21 +++
 drivers/net/qede/qede_ethdev.c  | 40 ++--
 drivers/net/szedata2/rte_eth_szedata2.c | 24 +++--
 drivers/net/thunderx/nicvf_ethdev.c | 20 +++---
 drivers/net/virtio/virtio_ethdev.c  | 25 +-
 drivers/net/vmxnet3/vmxnet3_ethdev.c| 23 +++--
 20 files changed, 78 insertions(+), 407 deletions(-)

diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c 
b/drivers/crypto/qat/rte_qat_cryptodev.c
index 1e9e0ba..4c215a6 100644
--- a/drivers/crypto/qat/rte_qat_cryptodev.c
+++ b/drivers/crypto/qat/rte_qat_cryptodev.c
@@ -116,23 +116,13 @@ static struct rte_cryptodev_driver rte_qat_pmd = {
.pci_drv = {
.id_table = pci_id_qat_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING,
+   .devinit = rte_cryptodev_pci_probe,
+   .devuninit = rte_cryptodev_pci_remove,
},
.cryptodev_init = crypto_qat_dev_init,
.dev_private_size = sizeof(struct qat_pmd_private),
 };

-static int
-rte_qat_pmd_init(const char *name __rte_unused, const char *params 
__rte_unused)
-{
-   PMD_INIT_FUNC_TRACE();
-   return rte_cryptodev_pmd_driver_register(_qat_pmd, PMD_PDEV);
-}
-
-static struct rte_driver pmd_qat_drv = {
-   .type = PMD_PDEV,
-   .init = rte_qat_pmd_init,
-};
-
-PMD_REGISTER_DRIVER(pmd_qat_drv, CRYPTODEV_NAME_QAT_SYM_PMD);
+DRIVER_REGISTER_PCI(CRYPTODEV_NAME_QAT_SYM_PMD, rte_qat_pmd);
 DRIVER_REGISTER_PCI_TABLE(CRYPTODEV_NAME_QAT_SYM_PMD, pci_id_qat_map);

diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index c8d2bf2..dc7c893 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -621,6 +621,8 @@ static struct eth_driver rte_bnx2x_pmd = {
.name = "rte_bnx2x_pmd",
.id_table = pci_id_bnx2x_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC,
+   .devinit = rte_eth_dev_pci_probe,
+   .devuninit = rte_eth_dev_pci_remove,
},
.eth_dev_init = eth_bnx2x_dev_init,
.dev_private_size = sizeof(struct bnx2x_softc),
@@ -634,38 +636,14 @@ static struct eth_driver rte_bnx2xvf_pmd = {
.name = "rte_bnx2xvf_pmd",
.id_table = pci_id_bnx2xvf_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING,
+   .devinit = rte_eth_dev_pci_probe,
+   .devuninit = rte_eth_dev_pci_remove,
},
.eth_dev_init = eth_bnx2xvf_dev_init,
.dev_private_size = sizeof(struct bnx2x_softc),
 };

-static int rte_bnx2x_pmd_init(const char *name __rte_unused, const char 
*params __rte_unused)
-{
-   PMD_INIT_FUNC_TRACE();
-   rte_eth_driver_register(_bnx2x_pmd);
-
-   return 0;
-}
-
-static int rte_bnx2xvf_pmd_init(const char *name __rte_unused, const char 
*params __rte_unused)
-{
-   PMD_INIT_FUNC_TRACE();
-   rte_eth_driver_register(_bnx2xvf_pmd);
-
-   return 0;
-}
-
-static struct rte_driver rte_bnx2x_driver = {
-   .type = PMD_PDEV,
-   .init = rte_bnx2x_pmd_init,
-};
-
-static struct rte_driver rte_bnx2xvf_driver = {
-   .type = PMD_PDEV,
-   .init = rte_bnx2xvf_pmd_init,
-};
-
-PMD_REGISTER_DRIVER(rte_bnx2x_driver, bnx2x);
+DRIVER_REGISTER_PCI(bnx2x, rte_bnx2x_pmd);
 DRIVER_REGISTER_PCI_TABLE(bnx2x, pci_id_bnx2x_map);
-PMD_REGISTER_DRIVER(rte_bnx2xvf_driver, bnx2xvf);
+DRIVER_REGISTER_PCI(bnx2xvf, rte_bnx2xvf_pmd);
 DRIVER_REGISTER_PCI_TABLE(bnx2xvf, pci_id_bnx2xvf_map);
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 3795fac..607f88c 

[dpdk-dev] [PATCH v6 07/17] ethdev: export init/uninit common wrappers for pci drivers

2016-07-12 Thread Shreyansh Jain
Preparing for getting rid of eth_drv, here are two wrappers that can be
used by pci drivers that assume a 1 to 1 association between pci resource and
upper interface.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_ether/rte_ethdev.c  | 14 +++---
 lib/librte_ether/rte_ethdev.h  | 13 +
 lib/librte_ether/rte_ether_version.map |  3 +++
 3 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 0a6e3f1..25eb032 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -245,9 +245,9 @@ rte_eth_dev_release_port(struct rte_eth_dev *eth_dev)
return 0;
 }

-static int
-rte_eth_dev_init(struct rte_pci_driver *pci_drv,
-struct rte_pci_device *pci_dev)
+int
+rte_eth_dev_pci_probe(struct rte_pci_driver *pci_drv,
+ struct rte_pci_device *pci_dev)
 {
struct eth_driver*eth_drv;
struct rte_eth_dev *eth_dev;
@@ -299,8 +299,8 @@ rte_eth_dev_init(struct rte_pci_driver *pci_drv,
return diag;
 }

-static int
-rte_eth_dev_uninit(struct rte_pci_device *pci_dev)
+int
+rte_eth_dev_pci_remove(struct rte_pci_device *pci_dev)
 {
const struct eth_driver *eth_drv;
struct rte_eth_dev *eth_dev;
@@ -357,8 +357,8 @@ rte_eth_dev_uninit(struct rte_pci_device *pci_dev)
 void
 rte_eth_driver_register(struct eth_driver *eth_drv)
 {
-   eth_drv->pci_drv.devinit = rte_eth_dev_init;
-   eth_drv->pci_drv.devuninit = rte_eth_dev_uninit;
+   eth_drv->pci_drv.devinit = rte_eth_dev_pci_probe;
+   eth_drv->pci_drv.devuninit = rte_eth_dev_pci_remove;
rte_eal_pci_register(_drv->pci_drv);
 }

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 4dac364..a2ec9d1 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -4369,6 +4369,19 @@ rte_eth_dev_get_port_by_name(const char *name, uint8_t 
*port_id);
 int
 rte_eth_dev_get_name_by_port(uint8_t port_id, char *name);

+/**
+ * Wrapper for use by pci drivers as a .devinit function to attach to a ethdev
+ * interface.
+ */
+int rte_eth_dev_pci_probe(struct rte_pci_driver *pci_drv,
+ struct rte_pci_device *pci_dev);
+
+/**
+ * Wrapper for use by pci drivers as a .devuninit function to detach a ethdev
+ * interface.
+ */
+int rte_eth_dev_pci_remove(struct rte_pci_device *pci_dev);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_ether/rte_ether_version.map 
b/lib/librte_ether/rte_ether_version.map
index 45ddf44..c5ef869 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -138,4 +138,7 @@ DPDK_16.07 {
rte_eth_dev_get_name_by_port;
rte_eth_dev_get_port_by_name;
rte_eth_xstats_get_names;
+   rte_eth_dev_pci_probe;
+   rte_eth_dev_pci_remove;
+
 } DPDK_16.04;
-- 
2.7.4



[dpdk-dev] [PATCH v6 06/17] crypto: export init/uninit common wrappers for pci drivers

2016-07-12 Thread Shreyansh Jain
Preparing for getting rid of rte_cryptodev_driver, here are two wrappers
that can be used by pci drivers that assume a 1 to 1 association between
pci resource and upper interface.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_cryptodev/rte_cryptodev.c   | 16 
 lib/librte_cryptodev/rte_cryptodev_pmd.h   | 12 
 lib/librte_cryptodev/rte_cryptodev_version.map |  2 ++
 3 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index c3cc3e9..3a75f2c 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -431,9 +431,9 @@ rte_cryptodev_pmd_virtual_dev_init(const char *name, size_t 
dev_private_size,
return cryptodev;
 }

-static int
-rte_cryptodev_init(struct rte_pci_driver *pci_drv,
-   struct rte_pci_device *pci_dev)
+int
+rte_cryptodev_pci_probe(struct rte_pci_driver *pci_drv,
+   struct rte_pci_device *pci_dev)
 {
struct rte_cryptodev_driver *cryptodrv;
struct rte_cryptodev *cryptodev;
@@ -492,8 +492,8 @@ rte_cryptodev_init(struct rte_pci_driver *pci_drv,
return -ENXIO;
 }

-static int
-rte_cryptodev_uninit(struct rte_pci_device *pci_dev)
+int
+rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev)
 {
const struct rte_cryptodev_driver *cryptodrv;
struct rte_cryptodev *cryptodev;
@@ -541,15 +541,15 @@ rte_cryptodev_pmd_driver_register(struct 
rte_cryptodev_driver *cryptodrv,
 {
/* Call crypto device initialization directly if device is virtual */
if (type == PMD_VDEV)
-   return rte_cryptodev_init((struct rte_pci_driver *)cryptodrv,
+   return rte_cryptodev_pci_probe((struct rte_pci_driver 
*)cryptodrv,
NULL);

/*
 * Register PCI driver for physical device intialisation during
 * PCI probing
 */
-   cryptodrv->pci_drv.devinit = rte_cryptodev_init;
-   cryptodrv->pci_drv.devuninit = rte_cryptodev_uninit;
+   cryptodrv->pci_drv.devinit = rte_cryptodev_pci_probe;
+   cryptodrv->pci_drv.devuninit = rte_cryptodev_pci_remove;

rte_eal_pci_register(>pci_drv);

diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h 
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index c977c61..3fb7c7c 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -534,6 +534,18 @@ rte_cryptodev_pmd_driver_register(struct 
rte_cryptodev_driver *crypto_drv,
 void rte_cryptodev_pmd_callback_process(struct rte_cryptodev *dev,
enum rte_cryptodev_event_type event);

+/**
+ * Wrapper for use by pci drivers as a .devinit function to attach to a crypto
+ * interface.
+ */
+int rte_cryptodev_pci_probe(struct rte_pci_driver *pci_drv,
+   struct rte_pci_device *pci_dev);
+
+/**
+ * Wrapper for use by pci drivers as a .devuninit function to detach a crypto
+ * interface.
+ */
+int rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev);

 #ifdef __cplusplus
 }
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map 
b/lib/librte_cryptodev/rte_cryptodev_version.map
index a08fd20..7aa7f4e 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -37,5 +37,7 @@ DPDK_16.07 {
global:

rte_cryptodev_parse_vdev_init_params;
+   rte_cryptodev_pci_probe;
+   rte_cryptodev_pci_remove;

 } DPDK_16.04;
-- 
2.7.4



[dpdk-dev] [PATCH v6 05/17] eal: introduce init macros

2016-07-12 Thread Shreyansh Jain
Introduce a RTE_INIT macro used to mark an init function as a constructor.
Current eal macros have been converted to use this (no functional impact).
DRIVER_REGISTER_PCI is added as a helper for pci drivers.

Suggested-by: Jan Viktorin 
Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_eal/common/include/rte_dev.h   | 4 ++--
 lib/librte_eal/common/include/rte_eal.h   | 3 +++
 lib/librte_eal/common/include/rte_pci.h   | 8 
 lib/librte_eal/common/include/rte_tailq.h | 4 ++--
 4 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_dev.h 
b/lib/librte_eal/common/include/rte_dev.h
index 95789f9..994650b 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -185,8 +185,8 @@ static const char DRIVER_EXPORT_NAME_ARRAY(this_pmd_name, 
idx) \
 __attribute__((used)) = RTE_STR(name)

 #define PMD_REGISTER_DRIVER(drv, nm)\
-void devinitfn_ ##drv(void);\
-void __attribute__((constructor, used)) devinitfn_ ##drv(void)\
+RTE_INIT(devinitfn_ ##drv);\
+static void devinitfn_ ##drv(void)\
 {\
(drv).name = RTE_STR(nm);\
rte_eal_driver_register();\
diff --git a/lib/librte_eal/common/include/rte_eal.h 
b/lib/librte_eal/common/include/rte_eal.h
index a71d6f5..186f3c6 100644
--- a/lib/librte_eal/common/include/rte_eal.h
+++ b/lib/librte_eal/common/include/rte_eal.h
@@ -252,6 +252,9 @@ static inline int rte_gettid(void)
return RTE_PER_LCORE(_thread_id);
 }

+#define RTE_INIT(func) \
+static void __attribute__((constructor, used)) func(void)
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_eal/common/include/rte_pci.h 
b/lib/librte_eal/common/include/rte_pci.h
index fa74962..3027adf 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -470,6 +470,14 @@ void rte_eal_pci_dump(FILE *f);
  */
 void rte_eal_pci_register(struct rte_pci_driver *driver);

+/** Helper for PCI device registeration from driver (eth, crypto) instance */
+#define DRIVER_REGISTER_PCI(nm, drv) \
+RTE_INIT(pciinitfn_ ##nm); \
+static void pciinitfn_ ##nm(void) \
+{ \
+   rte_eal_pci_register(_drv); \
+}
+
 /**
  * Unregister a PCI driver.
  *
diff --git a/lib/librte_eal/common/include/rte_tailq.h 
b/lib/librte_eal/common/include/rte_tailq.h
index 4a686e6..71ed3bb 100644
--- a/lib/librte_eal/common/include/rte_tailq.h
+++ b/lib/librte_eal/common/include/rte_tailq.h
@@ -148,8 +148,8 @@ struct rte_tailq_head *rte_eal_tailq_lookup(const char 
*name);
 int rte_eal_tailq_register(struct rte_tailq_elem *t);

 #define EAL_REGISTER_TAILQ(t) \
-void tailqinitfn_ ##t(void); \
-void __attribute__((constructor, used)) tailqinitfn_ ##t(void) \
+RTE_INIT(tailqinitfn_ ##t); \
+static void tailqinitfn_ ##t(void) \
 { \
if (rte_eal_tailq_register() < 0) \
rte_panic("Cannot initialize tailq: %s\n", t.name); \
-- 
2.7.4



[dpdk-dev] [PATCH v6 04/17] eal: remove duplicate function declaration

2016-07-12 Thread Shreyansh Jain
rte_eal_dev_init is declared in both eal_private.h and rte_dev.h since its
introduction.
This function has been exported in ABI, so remove it from eal_private.h

Fixes: e57f20e05177 ("eal: make vdev init path generic for both virtual and pci 
devices")
Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_eal/common/eal_private.h | 7 ---
 lib/librte_eal/linuxapp/eal/eal.c   | 1 +
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/lib/librte_eal/common/eal_private.h 
b/lib/librte_eal/common/eal_private.h
index 857dc3e..06a68f6 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -259,13 +259,6 @@ int rte_eal_intr_init(void);
 int rte_eal_alarm_init(void);

 /**
- * This function initialises any virtual devices
- *
- * This function is private to the EAL.
- */
-int rte_eal_dev_init(void);
-
-/**
  * Function is to check if the kernel module(like, vfio, vfio_iommu_type1,
  * etc.) loaded.
  *
diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index 3fb2188..fe9c704 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -70,6 +70,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.7.4



[dpdk-dev] [PATCH v6 00/17] Prepare for rte_device / rte_driver

2016-07-12 Thread Shreyansh Jain
* Original patch series is from David Marchand [1], [2].
* Link with patch series [4] from Jan Viktorin for a more complete picture
  of proposed EAL device heirarchy changes.
* This might not be in-sync with pmdinfogen as PMD_REGISTER_DRIVER is
  removed [7].

David created the original patchset based on the discussions on list [3].
Being a large piece of work, this patchset introduces first level of changes
for generalizing the driver-device relationship for supporting hotplug.

This patchset is based on master (11c5e45d8)

Overview of this work as per David [3], as well as notes from Thomas, Jan:
- pdev -> PCI registeration using helpers (introduced in this series)
- removal of eth/crypto driver registeration callbacks. These are now handled
  by PCI registeration helpers (this patch)
- rte_device=>pci/vdev device heirarchy (by this [4] series)
- removal of PMD_PDEV type (this patch) and PMD_VDEV (by this [4] series)
- Support for hotplugging

In [5], Neil had NACK'd previous series due to removal of symbol from map file
without proper process. I continue with the same patch in this series as I
was not clear after Thomas's reponse [6] whether it is OK to remove these
(rte_cryptodev_pmd_driver_register, rte_eth_driver_register) or not - probably
some procedure of deprecation that I am skipping.

Changes since v5:
- Rebase over master (11c5e45d8)
- Rename RTE_EAL_PCI_REGISTER helper macro to DRIVER_REGISTER_PCI to be in sync
  with DRIVER_REGISTER_PCI_TABLE. [Probably, in future, both can be merged]
- Modifications to bnxt and thunderx driver PMD registeration files for
  using the simplified PCI device registeration helper macro

Changes since v4:
- Fix compilation issue after rebase on HEAD (913154e) in previous series
- Retain rte_eth_dev_get_port_by_name and rte_eth_dev_get_name_by_port which
  were removed by previous patchset. These are being used by pdump library

Changes since v3:
- rebase over HEAD (913154e)
- Update arguments to RTE_EAL_PCI_REGISTER macro as per Jan's suggestion
- modify qede driver to use RTE_EAL_PCI_REGISTER
- Argument check in hotplug functions

Changes since v2:
- rebase over HEAD (d76c193)
- Move SYSFS_PCI_DRIVERS macro to rte_pci.h to avoid compilation issue

Changes since v1:
- rebased on HEAD, new drivers should be okay
- patches have been split into smaller pieces
- RTE_INIT macro has been added, but in the end, I am not sure it is useful
- device type has been removed from ethdev, as it was used only by hotplug
- getting rid of pmd type in eal patch (patch 5 of initial series) has been
  dropped for now, we can do this once vdev drivers have been converted

[1] http://dpdk.org/ml/archives/dev/2016-January/032387.html
[2] http://dpdk.org/ml/archives/dev/2016-April/037686.html
[3] http://dpdk.org/ml/archives/dev/2016-January/031390.html
[4] http://dpdk.org/ml/archives/dev/2016-July/043645.html
[5] http://dpdk.org/ml/archives/dev/2016-June/042439.html
[6] http://dpdk.org/ml/archives/dev/2016-June/042444.html
[7] http://dpdk.org/ml/archives/dev/2016-July/043172.html

David Marchand, Shreyansh Jain (17):
  pci: no need for dynamic tailq init
  crypto: no need for a crypto pmd type
  drivers: align pci driver definitions
  eal: remove duplicate function declaration
  eal: introduce init macros
  crypto: export init/uninit common wrappers for pci drivers
  ethdev: export init/uninit common wrappers for pci drivers
  drivers: convert all pdev drivers as pci drivers
  crypto: get rid of crypto driver register callback
  ethdev: get rid of eth driver register callback
  eal/linux: move back interrupt thread init before setting affinity
  pci: add a helper for device name
  pci: add a helper to update a device
  ethdev: do not scan all pci devices on attach
  eal: add hotplug operations for pci and vdev
  ethdev: convert to eal hotplug
  ethdev: get rid of device type

 app/test/virtual_pmd.c  |   2 +-
 drivers/crypto/qat/rte_qat_cryptodev.c  |  18 +-
 drivers/net/af_packet/rte_eth_af_packet.c   |   2 +-
 drivers/net/bnx2x/bnx2x_ethdev.c|  34 +--
 drivers/net/bnxt/bnxt_ethdev.c  |  16 +-
 drivers/net/bonding/rte_eth_bond_api.c  |   2 +-
 drivers/net/cxgbe/cxgbe_ethdev.c|  24 +--
 drivers/net/cxgbe/cxgbe_main.c  |   2 +-
 drivers/net/e1000/em_ethdev.c   |  16 +-
 drivers/net/e1000/igb_ethdev.c  |  39 +---
 drivers/net/ena/ena_ethdev.c|  19 +-
 drivers/net/enic/enic_ethdev.c  |  23 +-
 drivers/net/fm10k/fm10k_ethdev.c|  23 +-
 drivers/net/i40e/i40e_ethdev.c  |  24 +--
 drivers/net/i40e/i40e_ethdev_vf.c   |  25 +--
 drivers/net/ixgbe/ixgbe_ethdev.c|  46 +---
 drivers/net/mlx4/mlx4.c |  17 +-
 drivers/net/mlx5/mlx5.c |  16 +-
 drivers/net/mpipe/mpipe_tilegx.c|   2 +-
 

[dpdk-dev] [PATCH] net/virtio-user: Fix missing brackets in if condition

2016-07-12 Thread Maxime Coquelin
The error is reported using test build script:

$ scripts/test-build.sh x86_64-native-linuxapp-gcc
...
drivers/net/virtio/virtio_user_ethdev.c: In function ?virtio_user_pmd_devinit?:
drivers/net/virtio/virtio_user_ethdev.c:345:2: error: this ?if? clause does not 
guard... [-Werror=misleading-indentation]
  if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_PATH) == 1)
^~

Fixes: 404bd6bfe360 ("net/virtio-user: fix return value not checked")

Cc: Jianfeng Tan 
Signed-off-by: Maxime Coquelin 
---
 drivers/net/virtio/virtio_user_ethdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/virtio/virtio_user_ethdev.c 
b/drivers/net/virtio/virtio_user_ethdev.c
index 782d7d3..6b4f66e 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -342,7 +342,7 @@ virtio_user_pmd_devinit(const char *name, const char 
*params)
goto end;
}

-   if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_PATH) == 1)
+   if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_PATH) == 1) {
ret = rte_kvargs_process(kvlist, VIRTIO_USER_ARG_PATH,
 _string_arg, );
if (ret < 0) {
@@ -350,7 +350,7 @@ virtio_user_pmd_devinit(const char *name, const char 
*params)
 VIRTIO_USER_ARG_PATH);
goto end;
}
-   else {
+   } else {
PMD_INIT_LOG(ERR, "arg %s is mandatory for virtio-user\n",
  VIRTIO_USER_ARG_QUEUE_SIZE);
goto end;
-- 
2.7.4



[dpdk-dev] [PATCH] mk: fix default rule of test subdirectory

2016-07-12 Thread Pattan, Reshma
Hi,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Tuesday, July 12, 2016 11:22 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] mk: fix default rule of test subdirectory
> 
> When using "make -C app/test" (with RTE_SDK/RTE_TARGET adjusted) without
> specifying the rule (all), the build is not done.
> Indeed the default rule is not "all" anymore since there are some rules added 
> for
> external resources link.
> 
> It is fixed by adding a reference to "all" at the top of the file which makes 
> it the
> default rule.
> 
> Note that make app/test_sub (without environment variable) is preffered.
> 

What is test_sub here? I could not execute the command make 
app/test_sub(without environment variable) . 

Thanks,
Reshma


[dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct location

2016-07-12 Thread Ananyev, Konstantin

Hi Juhamatti,

> 
> Hello,
> 
> > > > > -Original Message-
> > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Juhamatti
> > > > > Kuusisaari
> > > > > Sent: Monday, July 11, 2016 11:21 AM
> > > > > To: dev at dpdk.org
> > > > > Subject: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to
> > > > > correct location
> > > > >
> > > > > Fix the location of the rte_ring data dependency read barrier.
> > > > > It needs to be called before accessing indexed data to ensure that
> > > > > the data itself is guaranteed to be correctly updated.
> > > > >
> > > > > See more details at kernel/Documentation/memory-barriers.txt
> > > > > section 'Data dependency barriers'.
> > > >
> > > >
> > > > Any explanation why?
> > > > From my point smp_rmb()s are on the proper places here :) Konstantin
> > >
> > > The problem here is that on a weak memory model system the CPU is
> > > allowed to load the address data out-of-order in advance.
> > > If the read barrier is after the DEQUEUE, you might end up having the
> > > old data there on a race situation when the buffer is continuously full.
> > > Having it before the DEQUEUE guarantees that the load is not done in
> > > advance.
> >
> > Sorry, still didn't see any race condition in the current code.
> > Can you provide any particular example?
> > From other side, moving smp_rmb() before dequeueing the objects, could
> > introduce a race condition, on cpus where later writes can be reordered with
> > earlier reads.
> 
> Here is a simplified example sequence from time perspective:
> 1. Consumer CPU (CCPU) loads value y from r->ring[x] out-of-order
> (the key of the problem)

To read the value of ring[x] cpu has to calculate x first.
And to calculate x it needs to read cons.head and prod.tail first.
Are you saying that some modern cpu can:
 -'speculate' value of cons.head and  prod.tail
  (based on what?)
 -calculate x based on these speculated values.
- read ring[x]
- read cons.head and prod.tail
- if read values are not equal to speculated ones , then
  re-caluclate x and re-read ring[x]
- else use speculatively read ring[x] 
?
If such thing is possible  (is it really? and if yes on which cpu?),
then yes, we might need an extra  smp_rmb() before DEQUEUE_PTRS()
for __rte_ring_sc_do_dequeue().
For __rte_ring_mc_do_dequeue(), I think we are ok, as
there is CAS just before DEQUEUE_PTRS().

> 2. Producer CPU (PCPU) updates r->ring[x] to value be z
> 3. PCPU updates prod_tail to be x
> 4. CCPU updates cons_head to be x
> 5. CCPU loads r->ring[x] by using out-of-order loaded value y [is z in 
> reality]
> 
> The problem here is that on weak memory model, the CCPU is allowed to load
> r->ring[x] value in advance, if it decides to do so (CCPU needs to be able to 
> see
> in advance that x will be an interesting index worth loading). The index 
> value x
> is updated atomically,  but it does not matter here. Also, the write barrier 
> on PCPU
> side guarantees that CCPU cannot see update of x before PCPU has really 
> updated
> the r->ring[x] to z and moved the tail, but still allows to do the 
> out-of-order loads
> without proper read barrier.
> 
> When the read barrier is moved between steps 4 and 5, it disallows to use
> any out-of-order loads so far and forces to drop r->ring[x] y value and
> load current value z.
> 
> The ring queue appears to work well as this is a rare corner case. Due to the
> head,tail-structure the problem needs queue to be full and also CCPU needs
> to see r->ring[x] update later than it does the out-of-order load. In 
> addition,
> the HW needs to be able to predict and choose the load to the future index
> (which should be quite possible, considering modern CPUs). If you have seen
> in the past problems and noticed that a larger ring queue works better as a
> workaround, you may have encountered the problem already.

I don't understand what means 'larger rings works better' here. 
What we are talking about is  race condition, that if hit, would
cause data corruption and most likely a crash.

> 
> It is quite safe to move the barrier before DEQUEUE because after the DEQUEUE
> there is nothing really that we would want to protect with a read barrier.

I don't think so.
If you remove barrier after DEQUEUE(), that means on systems with relaxed 
memory ordering
cons.tail could be updated before DEQUEUE() will be finished and producer can 
overwrite
queue entries that were not yet dequeued.
So if cpu can really do such speculative out of order loads,
then we do need for  __rte_ring_sc_do_dequeue() something like:

rte_smp_rmb();
DEQUEUE_PTRS();
rte_smp_rmb();

Konstantin

> The read
> barrier is mapped to a compiler barrier on strong memory model systems and 
> this
> works fine too as the order of the head,tail updates is still guaranteed on 
> the new
> location. Even if the problem would be theoretical on most systems, it is 
> worth fixing
> as the risk for problems is very low.
> 
> --
>  Juhamatti
> 
> > Konstantin
> 
> 
> 
> 
> > 

[dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add sample configuration files

2016-07-12 Thread Fan Zhang
This patch adds two sample configuration files to ipsec-secgw sample
application. The sample configuration files shows how to set-up systems
back-to-back that would forward traffic through an IPsec tunnel.

Signed-off-by: Fan Zhang 
---
 examples/ipsec-secgw/ep0.cfg | 119 +++
 examples/ipsec-secgw/ep1.cfg | 119 +++
 2 files changed, 238 insertions(+)
 create mode 100644 examples/ipsec-secgw/ep0.cfg
 create mode 100644 examples/ipsec-secgw/ep1.cfg

diff --git a/examples/ipsec-secgw/ep0.cfg b/examples/ipsec-secgw/ep0.cfg
new file mode 100644
index 000..c10e22b
--- /dev/null
+++ b/examples/ipsec-secgw/ep0.cfg
@@ -0,0 +1,119 @@
+###
+#   IPSEC-SECGW Endpoint sample configuration
+#
+#   The main purpose of this file is to show how to configure two systems
+#   back-to-back that would forward traffic through an IPsec tunnel. This
+#   file is the Endpoint 0 configuration. To use this configuration file,
+#   add the following command-line option:
+#
+#   -f ./ep0.cfg
+#
+###
+
+#SP IPv4 rules
+sp ipv4 out esp protect 5 pri 1 dst 192.168.105.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp protect 6 pri 1 dst 192.168.106.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp protect 10 pri 1 dst 192.168.175.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp protect 11 pri 1 dst 192.168.176.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp protect 15 pri 1 dst 192.168.200.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp protect 16 pri 1 dst 192.168.201.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp protect 25 pri 1 dst 192.168.55.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp protect 26 pri 1 dst 192.168.56.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp bypass pri 1 dst 192.168.240.0/24 sport 0:65535 dport 0:65535
+sp ipv4 out esp bypass pri 1 dst 192.168.241.0/24 sport 0:65535 dport 0:65535
+
+sp ipv4 in esp protect 105 pri 1 dst 192.168.115.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 106 pri 1 dst 192.168.116.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 110 pri 1 dst 192.168.185.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 111 pri 1 dst 192.168.186.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 115 pri 1 dst 192.168.210.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 116 pri 1 dst 192.168.211.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 115 pri 1 dst 192.168.210.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 125 pri 1 dst 192.168.65.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 125 pri 1 dst 192.168.65.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 126 pri 1 dst 192.168.66.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp bypass pri 1 dst 192.168.245.0/24 sport 0:65535 dport 0:65535
+sp ipv4 in esp bypass pri 1 dst 192.168.246.0/24 sport 0:65535 dport 0:65535
+
+#SP IPv6 rules
+sp ipv6 out esp protect 5 pri 1 dst :::::::/96 
\
+sport 0:65535 dport 0:65535
+sp ipv6 out esp protect 6 pri 1 dst :::::::/96 
\
+sport 0:65535 dport 0:65535
+sp ipv6 out esp protect 10 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+sp ipv6 out esp protect 11 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+sp ipv6 out esp protect 25 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+sp ipv6 out esp protect 26 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+
+sp ipv6 in esp protect 15 pri 1 dst :::::::/96 
\
+sport 0:65535 dport 0:65535
+sp ipv6 in esp protect 16 pri 1 dst :::::::/96 
\
+sport 0:65535 dport 0:65535
+sp ipv6 in esp protect 110 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+sp ipv6 in esp protect 111 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+sp ipv6 in esp protect 125 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+sp ipv6 in esp protect 126 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+
+#SA rules
+sa out 5 aes-128-cbc sha1-hmac ipv4-tunnel src 172.16.1.5 dst 172.16.2.5
+sa out 6 aes-128-cbc sha1-hmac ipv4-tunnel src 172.16.1.6 dst 172.16.2.6
+sa out 10 aes-128-cbc sha1-hmac transport
+sa out 11 aes-128-cbc sha1-hmac transport
+sa out 15 null null ipv4-tunnel src 172.16.1.5 dst 172.16.2.5
+sa out 16 null null ipv4-tunnel src 172.16.1.6 dst 172.16.2.6
+sa out 25 aes-128-cbc sha1-hmac ipv6-tunnel \
+src ::::::: \
+dst :::::::
+sa out 26 aes-128-cbc sha1-hmac ipv6-tunnel \
+src 

[dpdk-dev] [PATCH v3 1/2] examples/ipsec-secgw: add configuration file support

2016-07-12 Thread Fan Zhang
This patch adds the configuration file support to ipsec_secgw
sample application. Instead of hard-coded rules, the users can
specify their own SP, SA, and routing rules in the configuration
file. An command line option "-f" is added to pass the
configuration file location to the application.

Configuration item formats:

SP rule format:
sp   esp \
  

SA rule format:
sa   

Routing rule format:
rt

Signed-off-by: Fan Zhang 
---
 doc/guides/sample_app_ug/ipsec_secgw.rst | 809 ---
 examples/ipsec-secgw/Makefile|   1 +
 examples/ipsec-secgw/ipsec-secgw.c   |  58 +--
 examples/ipsec-secgw/ipsec.h |   8 +-
 examples/ipsec-secgw/parser.c| 599 +++
 examples/ipsec-secgw/parser.h| 116 +
 examples/ipsec-secgw/rt.c| 255 +-
 examples/ipsec-secgw/sa.c| 462 ++
 examples/ipsec-secgw/sp4.c   | 539 +++-
 examples/ipsec-secgw/sp6.c   | 540 ++---
 10 files changed, 2116 insertions(+), 1271 deletions(-)
 create mode 100644 examples/ipsec-secgw/parser.c
 create mode 100644 examples/ipsec-secgw/parser.h

diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst 
b/doc/guides/sample_app_ug/ipsec_secgw.rst
index fcb33c2..2757df5 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -122,7 +122,7 @@ The application has a number of command line options::
 -p PORTMASK -P -u PORTMASK
 --config (port,queue,lcore)[,(port,queue,lcore]
 --single-sa SAIDX
-   --ep0|--ep1
+-f CONFIG_FILE_PATH

 Where:

@@ -142,14 +142,11 @@ Where:
 on both Inbound and Outbound. This option is meant for 
debugging/performance
 purposes.

-*   ``--ep0``: configure the app as Endpoint 0.
+*   ``-f CONFIG_FILE_PATH``: the full path of text-based file containing all
+configuration items for running the application (See Configuration file
+syntax section below). ``-f CONFIG_FILE_PATH`` **must** be specified.
+**ONLY** the UNIX format configuration file is accepted.

-*   ``--ep1``: configure the app as Endpoint 1.
-
-Either one of ``--ep0`` or ``--ep1`` **must** be specified.
-The main purpose of these options is to easily configure two systems
-back-to-back that would forward traffic through an IPsec tunnel (see
-:ref:`figure_ipsec_endpoints`).

 The mapping of lcores to port/queues is similar to other l3fwd applications.

@@ -157,7 +154,8 @@ For example, given the following command line::

 ./build/ipsec-secgw -l 20,21 -n 4 --socket-mem 0,2048   \
--vdev "cryptodev_null_pmd" -- -p 0xf -P -u 0x3  \
-   --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)" --ep0 \
+   --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)"   \
+   -f /path/to/config_file  \

 where each options means:

@@ -194,8 +192,12 @@ where each options means:
 |  |   |   |   
|
 
+--+---+---+---+

-*   The ``--ep0`` options configures the app with a given set of SP, SA and 
Routing
-entries as explained below in more detail.
+*   The ``-f /path/to/config_file`` option enables the application read and
+parse the configuration file specified, and configures the application
+with a given set of SP, SA and Routing entries accordingly. The syntax of
+the configuration file will be explained below in more detail. Please
+**note** the parser only accepts UNIX format text file. Other formats
+such as DOS/MAC format will cause a parse error.

 Refer to the *DPDK Getting Started Guide* for general information on running
 applications and the Environment Abstraction Layer (EAL) options.
@@ -219,496 +221,321 @@ For example, something like the following command line:
 --vdev "cryptodev_aesni_mb_pmd" --vdev "cryptodev_null_pmd" \
-- \
 -p 0xf -P -u 0x3 --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)" \
---ep0
+-f sample.cfg


 Configurations
 --

-The following sections provide some details on the default values used to
-initialize the SP, SA and Routing tables.
-Currently all configuration information is hard coded into the application.
+The following sections provide the syntax of configurations to initialize
+your SP, SA and Routing tables.
+Configurations shall be specified in the configuration file to be passed to
+the application. The file is then parsed by the application. The successful
+parsing will result in the appropriate rules being applied to the tables
+accordingly.

-The following image illustrate a few of the concepts regarding IPSec, such
-as protected/unprotected and inbound/outbound traffic, from the 

[dpdk-dev] [PATCH v3 0/2] examples/ipsec_secgw: add configuration file support

2016-07-12 Thread Fan Zhang
This patchset adds the configuration file supported to ipsec_secgw
sample application. Two sample configuration files, ep0.cfg and ep1.cfg
are also added to show how to configure two systems back-to-back that 
would forward traffic through an IPsec tunnel

v3 change:
- fix 32-bit compilation error

v2 changes:
- fix configuration file parsing error.
- update doc to remove whitespace tailing errors.

Fan Zhang (2):
  examples/ipsec-secgw: add configuration file support
  examples/ipsec-secgw: add sample configuration files

 doc/guides/sample_app_ug/ipsec_secgw.rst | 809 ---
 examples/ipsec-secgw/Makefile|   1 +
 examples/ipsec-secgw/ep0.cfg | 119 +
 examples/ipsec-secgw/ep1.cfg | 119 +
 examples/ipsec-secgw/ipsec-secgw.c   |  58 +--
 examples/ipsec-secgw/ipsec.h |   8 +-
 examples/ipsec-secgw/parser.c| 599 +++
 examples/ipsec-secgw/parser.h| 116 +
 examples/ipsec-secgw/rt.c| 255 +-
 examples/ipsec-secgw/sa.c| 462 ++
 examples/ipsec-secgw/sp4.c   | 539 +++-
 examples/ipsec-secgw/sp6.c   | 540 ++---
 12 files changed, 2354 insertions(+), 1271 deletions(-)
 create mode 100644 examples/ipsec-secgw/ep0.cfg
 create mode 100644 examples/ipsec-secgw/ep1.cfg
 create mode 100644 examples/ipsec-secgw/parser.c
 create mode 100644 examples/ipsec-secgw/parser.h

-- 
2.5.5



[dpdk-dev] [PATCH] vhost: fix segfault on bad descriptor address.

2016-07-12 Thread Yuanhan Liu
On Mon, Jul 11, 2016 at 02:47:56PM +0300, Ilya Maximets wrote:
> On 11.07.2016 14:05, Yuanhan Liu wrote:
> > On Mon, Jul 11, 2016 at 12:50:24PM +0300, Ilya Maximets wrote:
> >> On 11.07.2016 11:38, Yuanhan Liu wrote:
> >>> On Sun, Jul 10, 2016 at 09:17:31PM +0800, Yuanhan Liu wrote:
>  On Fri, Jul 08, 2016 at 02:48:56PM +0300, Ilya Maximets wrote:
> >
> > Another point is that crash constantly happens on queue_id=3 (second RX 
> > queue) in
> > my scenario. It is newly allocated virtqueue while reconfiguration from 
> > rxq=1 to
> > rxq=2.
> 
>  That's a valuable message: what's your DPDK HEAD commit while triggering
>  this issue?
> >>
> >> fbfd99551ca3 ("mbuf: add raw allocation function")
> >>
> >>>
> >>> I guess I have understood what goes wrong in you case.
> >>>
> >>> I would guess that your vhost has 2 queues (here I mean queue-pairs,
> >>> including one Tx and Rx queue; below usage is the same) configured,
> >>> so does to your QEMU. However, you just enabled 1 queue while starting
> >>> testpmd inside the guest, and you want to enable 2 queues by running
> >>> following testpmd commands:
> >>>
> >>> stop
> >>> port stop all
> >>> port config all rxq 2
> >>> port config all txq 2
> >>> port start all
> >>>
> >>> Badly, that won't work for current virtio PMD implementation, and what's
> >>> worse, it triggers a vhost crash, the one you saw.
> >>>
> >>> Here is how it comes. Since you just enabled 1 queue while starting
> >>> testpmd, it will setup 1 queue only, meaning only one queue's **valid**
> >>> information will be sent to vhost. You might see SET_VRING_ADDR
> >>> (and related vhost messages) for the other queue as well, but they
> >>> are just the dummy messages: they don't include any valid/real
> >>> information about the 2nd queue: the driver don't setup it after all.
> >>>
> >>> So far, so good. It became broken when you run above commands. Those
> >>> commands do setup for the 2nd queue, however, they failed to trigger
> >>> the QEMU virtio device to start the vhost-user negotiation, meaning
> >>> no SET_VRING_ADDR will be sent for the 2nd queue, leaving vhost
> >>> untold and not updated.
> >>>
> >>> What's worse, above commands trigger the QEMU to send SET_VRING_ENABLE
> >>> messages, to enable all the vrings. And since the vrings for the 2nd
> >>> queue are not properly configured, the crash happens.
> >>
> >> Hmm, why 2nd queue works properly with my fix to vhost in this case?
> > 
> > Hmm, really? You are sure that data flows in your 2nd queue after those
> > commands? From what I know is that your patch just avoid a crash, but
> > does not fix it.
> 
> Oh, sorry. Yes, it doesn't work. With my patch applied I have a QEMU hang.

The crash actually could be avoided by commit 0823c1cb0a73 ("vhost:
workaround stale vring base"), accidentally. That's why I asked you
above the HEAD commit you were using.

> >>> So maybe we should do virtio reset on port start?
> >>
> >> I guess it was removed by this patch:
> >> a85786dc816f ("virtio: fix states handling during initialization").
> > 
> > Seems yes.

Actually, we should not do that: do reset on port start. The right fix
should be allocating MAX queues virtio device supports (2 here). This
would allow us changing the queue number dynamically.

But this doesn't sound a simple fix; it involves many code changes, due
to it was not designed this way before. Therefore, we will not fix it
in this release, due to it's too late. Let's fix it in the next release
instead. For the crash issue, it will not happen with the latest HEAD.
Though it's accident fix, I think we are fine here.

--yliu


[dpdk-dev] Compiling DPDK is not working on Red Hat 6.7

2016-07-12 Thread Raslan Darawsheh
Hi,

When trying to compile DPDK on Red Hat Enterprise Linux Server release 6.7 
(Santiago) it fails to compile.

This is the compilation error that is being seen:
LD test
/download/dpdk/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_timer.o): In 
function `get_tsc_freq':
eal_timer.c:(.text+0x152): undefined reference to `clock_gettime'
eal_timer.c:(.text+0x190): undefined reference to `clock_gettime'
/download/dpdk/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_alarm.o): In 
function `rte_eal_alarm_set':
eal_alarm.c:(.text+0x382): undefined reference to `clock_gettime'
/download/dpdk/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_alarm.o): In 
function `eal_alarm_callback':
eal_alarm.c:(.text+0x5e2): undefined reference to `clock_gettime'
collect2: ld returned 1 exit status
make[5]: *** [test] Error 1
make[4]: *** [test] Error 2
make[3]: *** [app] Error 2
make[2]: *** [all] Error 2
make[1]: *** [pre_install] Error 2
make: *** [install] Error 2

Kindest regards
Raslan Darawsheh


[dpdk-dev] [PATCH 10/10] bnx2x: Merge debug register operations into headers

2016-07-12 Thread Chas Williams
The register read/writes should just be static inline instead of
alternately defined as routines or macros depending on the status of
debugging.

Fix bnx2x_reg_read32() returning 0 during debug unaligned reads.

Fixes: b5bf7719221d ("bnx2x: driver support routines")

Signed-off-by: Chas Williams <3chas3 at gmail.com>
---
 drivers/net/bnx2x/Makefile |  1 -
 drivers/net/bnx2x/bnx2x.h  | 99 +-
 drivers/net/bnx2x/debug.c  | 96 
 3 files changed, 80 insertions(+), 116 deletions(-)
 delete mode 100644 drivers/net/bnx2x/debug.c

diff --git a/drivers/net/bnx2x/Makefile b/drivers/net/bnx2x/Makefile
index 6f1f385..0b4778b 100644
--- a/drivers/net/bnx2x/Makefile
+++ b/drivers/net/bnx2x/Makefile
@@ -24,7 +24,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x_ethdev.c
 SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += ecore_sp.c
 SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += elink.c
 SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x_vfpf.c
-SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC) += debug.c

 # this lib depends upon:
 DEPDIRS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += lib/librte_eal lib/librte_ether 
lib/librte_hash
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index d0d5b65..0ff3bf7 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -1412,34 +1412,95 @@ struct bnx2x_func_init_params {
 #define BAR1 2
 #define BAR2 4

+static inline void
+bnx2x_reg_write8(struct bnx2x_softc *sc, size_t offset, uint8_t val)
+{
+   PMD_DEBUG_PERIODIC_LOG(DEBUG, "offset=0x%08lx val=0x%02x",
+  (unsigned long)offset, val);
+   *((volatile uint8_t*)
+ ((uintptr_t)sc->bar[BAR0].base_addr + offset)) = val;
+}
+
+static inline void
+bnx2x_reg_write16(struct bnx2x_softc *sc, size_t offset, uint16_t val)
+{
+#ifdef RTE_LIBRTE_BNX2X_DEBUG_PERIODIC
+   if ((offset % 2) != 0)
+   PMD_DRV_LOG(NOTICE, "Unaligned 16-bit write to 0x%08lx",
+   (unsigned long)offset);
+#endif
+   PMD_DEBUG_PERIODIC_LOG(DEBUG, "offset=0x%08lx val=0x%04x",
+  (unsigned long)offset, val);
+   *((volatile uint16_t*)
+ ((uintptr_t)sc->bar[BAR0].base_addr + offset)) = val;
+}
+
+static inline void
+bnx2x_reg_write32(struct bnx2x_softc *sc, size_t offset, uint32_t val)
+{
 #ifdef RTE_LIBRTE_BNX2X_DEBUG_PERIODIC
-uint8_t bnx2x_reg_read8(struct bnx2x_softc *sc, size_t offset);
-uint16_t bnx2x_reg_read16(struct bnx2x_softc *sc, size_t offset);
-uint32_t bnx2x_reg_read32(struct bnx2x_softc *sc, size_t offset);
+   if ((offset % 4) != 0)
+   PMD_DRV_LOG(NOTICE, "Unaligned 32-bit write to 0x%08lx",
+   (unsigned long)offset);
+#endif

-void bnx2x_reg_write8(struct bnx2x_softc *sc, size_t offset, uint8_t val);
-void bnx2x_reg_write16(struct bnx2x_softc *sc, size_t offset, uint16_t val);
-void bnx2x_reg_write32(struct bnx2x_softc *sc, size_t offset, uint32_t val);
-#else
-#define bnx2x_reg_write8(sc, offset, val)\
-   *((volatile uint8_t*)((uintptr_t)sc->bar[BAR0].base_addr + offset)) = 
val
+   PMD_DEBUG_PERIODIC_LOG(DEBUG, "offset=0x%08lx val=0x%08x",
+  (unsigned long)offset, val);
+   *((volatile uint32_t*)
+ ((uintptr_t)sc->bar[BAR0].base_addr + offset)) = val;
+}
+
+static inline uint8_t
+bnx2x_reg_read8(struct bnx2x_softc *sc, size_t offset)
+{
+   uint8_t val;
+
+   val = (uint8_t)(*((volatile uint8_t*)
+ ((uintptr_t) sc->bar[BAR0].base_addr + offset)));
+   PMD_DEBUG_PERIODIC_LOG(DEBUG, "offset=0x%08lx val=0x%02x",
+  (unsigned long)offset, val);
+
+   return val;
+}
+
+static inline uint16_t
+bnx2x_reg_read16(struct bnx2x_softc *sc, size_t offset)
+{
+   uint16_t val;

-#define bnx2x_reg_write16(sc, offset, val)\
-   *((volatile uint16_t*)((uintptr_t)sc->bar[BAR0].base_addr + offset)) = 
val
+#ifdef RTE_LIBRTE_BNX2X_DEBUG_PERIODIC
+   if ((offset % 2) != 0)
+   PMD_DRV_LOG(NOTICE, "Unaligned 16-bit read from 0x%08lx",
+   (unsigned long)offset);
+#endif

-#define bnx2x_reg_write32(sc, offset, val)\
-   *((volatile uint32_t*)((uintptr_t)sc->bar[BAR0].base_addr + offset)) = 
val
+   val = (uint16_t)(*((volatile uint16_t*)
+  ((uintptr_t) sc->bar[BAR0].base_addr + offset)));
+   PMD_DEBUG_PERIODIC_LOG(DEBUG, "offset=0x%08lx val=0x%08x",
+  (unsigned long)offset, val);

-#define bnx2x_reg_read8(sc, offset)\
-   (*((volatile uint8_t*)((uintptr_t)sc->bar[BAR0].base_addr + offset)))
+   return val;
+}

-#define bnx2x_reg_read16(sc, offset)\
-   (*((volatile uint16_t*)((uintptr_t)sc->bar[BAR0].base_addr + offset)))
+static inline uint32_t
+bnx2x_reg_read32(struct bnx2x_softc *sc, size_t offset)
+{
+   uint32_t val;

-#define bnx2x_reg_read32(sc, offset)\
-   

[dpdk-dev] [PATCH 09/10] bnx2x: Don't return structs

2016-07-12 Thread Chas Williams
bnx2x_loop_obtain_resources() returns a struct.  This routine either
succeeds or fails -- We don't need a struct for that.

Fixes: 540a211084a7 ("bnx2x: driver core")

Signed-off-by: Chas Williams <3chas3 at gmail.com>
---
 drivers/net/bnx2x/bnx2x_vfpf.c | 51 --
 1 file changed, 19 insertions(+), 32 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x_vfpf.c b/drivers/net/bnx2x/bnx2x_vfpf.c
index 70622db..5fa4845 100644
--- a/drivers/net/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/bnx2x/bnx2x_vfpf.c
@@ -186,31 +186,23 @@ static inline int bnx2x_read_vf_id(struct bnx2x_softc *sc)
 #define BNX2X_VF_OBTAIN_MAC_FILTERS 1
 #define BNX2X_VF_OBTAIN_MC_FILTERS 10

-struct bnx2x_obtain_status {
-   int success;
-   int err_code;
-};
-
 static
-struct bnx2x_obtain_status bnx2x_loop_obtain_resources(struct bnx2x_softc *sc)
+int bnx2x_loop_obtain_resources(struct bnx2x_softc *sc)
 {
-   int tries = 0;
struct vf_acquire_resp_tlv *resp = >vf2pf_mbox->resp.acquire_resp,
-*sc_resp = 
>acquire_resp;
-   struct vf_resource_query*res_query;
-   struct vf_resc*resc;
-   struct bnx2x_obtain_status status;
+  *sc_resp = >acquire_resp;
+   struct vf_resource_query   *res_query;
+   struct vf_resc *resc;
int res_obtained = false;
+   int tries = 0;
+   int rc;

do {
PMD_DRV_LOG(DEBUG, "trying to get resources");

-   if (bnx2x_do_req4pf(sc, sc->vf2pf_mbox_mapping.paddr)) {
-   /* timeout */
-   status.success = 0;
-   status.err_code = -EAGAIN;
-   return status;
-   }
+   rc = bnx2x_do_req4pf(sc, sc->vf2pf_mbox_mapping.paddr);
+   if (rc)
+   return rc;

memcpy(sc_resp, resp, sizeof(sc->acquire_resp));

@@ -221,12 +213,12 @@ struct bnx2x_obtain_status 
bnx2x_loop_obtain_resources(struct bnx2x_softc *sc)
PMD_DRV_LOG(DEBUG, "resources obtained successfully");
res_obtained = true;
} else if (sc_resp->status == BNX2X_VF_STATUS_NO_RESOURCES &&
-   tries < BNX2X_VF_OBTAIN_MAX_TRIES) {
+  tries < BNX2X_VF_OBTAIN_MAX_TRIES) {
PMD_DRV_LOG(DEBUG,
   "PF cannot allocate requested amount of resources");

res_query = >vf2pf_mbox->query[0].acquire.res_query;
-   resc = _resp->resc;
+   resc  = _resp->resc;

/* PF refused our request. Try to decrease request 
params */
res_query->num_txqs = min(res_query->num_txqs, 
resc->num_txqs);
@@ -238,24 +230,21 @@ struct bnx2x_obtain_status 
bnx2x_loop_obtain_resources(struct bnx2x_softc *sc)

memset(>vf2pf_mbox->resp, 0, sizeof(union 
resp_tlvs));
} else {
-   PMD_DRV_LOG(ERR, "Resources cannot be obtained. Status 
of handling: %d. Aborting",
-   sc_resp->status);
-   status.success = 0;
-   status.err_code = -EAGAIN;
-   return status;
+   PMD_DRV_LOG(ERR, "Failed to get the requested "
+"amount of resources: %d.",
+sc_resp->status);
+   return -EINVAL;
}
} while (!res_obtained);

-   status.success = 1;
-   return status;
+   return 0;
 }

 int bnx2x_vf_get_resources(struct bnx2x_softc *sc, uint8_t tx_count, uint8_t 
rx_count)
 {
struct vf_acquire_tlv *acq = >vf2pf_mbox->query[0].acquire;
int vf_id;
-   struct bnx2x_obtain_status obtain_status;
-   int rc = 0;
+   int rc;

bnx2x_vf_close(sc);
bnx2x_vf_prep(sc, >first_tlv, BNX2X_VF_TLV_ACQUIRE, sizeof(*acq));
@@ -287,11 +276,9 @@ int bnx2x_vf_get_resources(struct bnx2x_softc *sc, uint8_t 
tx_count, uint8_t rx_
  sizeof(struct channel_list_end_tlv));

/* requesting the resources in loop */
-   obtain_status = bnx2x_loop_obtain_resources(sc);
-   if (!obtain_status.success) {
-   rc = obtain_status.err_code;
+   rc = bnx2x_loop_obtain_resources(sc);
+   if (rc)
goto out;
-   }

struct vf_acquire_resp_tlv sc_resp = sc->acquire_resp;

-- 
2.5.5



[dpdk-dev] [PATCH 08/10] bnx2x: Check return codes during VF mailbox operation

2016-07-12 Thread Chas Williams
Refactor bnx2x_do_req4pf() to be easier to read and return errors when
the transaction fails -- Previously, it could succeed when the control
channel was down.

Fixes: 540a211084a7 ("bnx2x: driver core")

Signed-off-by: Chas Williams <3chas3 at gmail.com>
---
 drivers/net/bnx2x/bnx2x_vfpf.c | 110 +++--
 1 file changed, 61 insertions(+), 49 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x_vfpf.c b/drivers/net/bnx2x/bnx2x_vfpf.c
index 46b56b4..70622db 100644
--- a/drivers/net/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/bnx2x/bnx2x_vfpf.c
@@ -118,39 +118,36 @@ bnx2x_do_req4pf(struct bnx2x_softc *sc, phys_addr_t 
phys_addr)
uint8_t *status = >vf2pf_mbox->resp.common_reply.status;
uint8_t i;

-   if (!*status) {
-   bnx2x_check_bull(sc);
-   if (sc->old_bulletin.valid_bitmap & (1 << CHANNEL_DOWN)) {
-   PMD_DRV_LOG(ERR, "channel is down. Aborting message 
sending");
-   *status = BNX2X_VF_STATUS_SUCCESS;
-   return 0;
-   }
+   if (*status) {
+   PMD_DRV_LOG(ERR, "status should be zero before message"
+" to pf was sent");
+   return -EINVAL;
+   }

-   REG_WR(sc, BNX2X_VF_CMD_ADDR_LO, U64_LO(phys_addr));
-   REG_WR(sc, BNX2X_VF_CMD_ADDR_HI, U64_HI(phys_addr));
+   bnx2x_check_bull(sc);
+   if (sc->old_bulletin.valid_bitmap & (1 << CHANNEL_DOWN)) {
+   PMD_DRV_LOG(ERR, "channel is down. Aborting message sending");
+   return -EINVAL;
+   }

-   /* memory barrier to ensure that FW can read phys_addr */
-   wmb();
+   REG_WR(sc, BNX2X_VF_CMD_ADDR_LO, U64_LO(phys_addr));
+   REG_WR(sc, BNX2X_VF_CMD_ADDR_HI, U64_HI(phys_addr));

-   REG_WR8(sc, BNX2X_VF_CMD_TRIGGER, 1);
+   /* memory barrier to ensure that FW can read phys_addr */
+   wmb();

-   /* Do several attempts until PF completes
-* "." is used to show progress
-*/
-   for (i = 0; i < BNX2X_VF_CHANNEL_TRIES; i++) {
-   DELAY_MS(BNX2X_VF_CHANNEL_DELAY);
-   if (*status)
-   break;
-   }
+   REG_WR8(sc, BNX2X_VF_CMD_TRIGGER, 1);

-   if (!*status) {
-   PMD_DRV_LOG(ERR, "Response from PF timed out");
-   return -EAGAIN;
-   }
-   } else {
-   PMD_DRV_LOG(ERR, "status should be zero before message"
-   "to pf was sent");
-   return -EINVAL;
+   /* Do several attempts until PF completes */
+   for (i = 0; i < BNX2X_VF_CHANNEL_TRIES; i++) {
+   DELAY_MS(BNX2X_VF_CHANNEL_DELAY);
+   if (*status)
+   break;
+   }
+
+   if (!*status) {
+   PMD_DRV_LOG(ERR, "Response from PF timed out");
+   return -EAGAIN;
}

PMD_DRV_LOG(DEBUG, "Response from PF was received");
@@ -337,6 +334,7 @@ bnx2x_vf_close(struct bnx2x_softc *sc)
struct vf_release_tlv *query;
struct vf_common_reply_tlv *reply = >vf2pf_mbox->resp.common_reply;
int vf_id = bnx2x_read_vf_id(sc);
+   int rc;

if (vf_id >= 0) {
query = >vf2pf_mbox->query[0].release;
@@ -348,8 +346,8 @@ bnx2x_vf_close(struct bnx2x_softc *sc)
  BNX2X_VF_TLV_LIST_END,
  sizeof(struct channel_list_end_tlv));

-   bnx2x_do_req4pf(sc, sc->vf2pf_mbox_mapping.paddr);
-   if (reply->status != BNX2X_VF_STATUS_SUCCESS)
+   rc = bnx2x_do_req4pf(sc, sc->vf2pf_mbox_mapping.paddr);
+   if (rc || reply->status != BNX2X_VF_STATUS_SUCCESS)
PMD_DRV_LOG(ERR, "Failed to release VF");

bnx2x_vf_finalize(sc, >first_tlv);
@@ -362,7 +360,7 @@ bnx2x_vf_init(struct bnx2x_softc *sc)
 {
struct vf_init_tlv *query;
struct vf_common_reply_tlv *reply = >vf2pf_mbox->resp.common_reply;
-   int i, rc = 0;
+   int i, rc;

query = >vf2pf_mbox->query[0].init;
bnx2x_vf_prep(sc, >first_tlv, BNX2X_VF_TLV_INIT,
@@ -380,7 +378,9 @@ bnx2x_vf_init(struct bnx2x_softc *sc)
  BNX2X_VF_TLV_LIST_END,
  sizeof(struct channel_list_end_tlv));

-   bnx2x_do_req4pf(sc, sc->vf2pf_mbox_mapping.paddr);
+   rc = bnx2x_do_req4pf(sc, sc->vf2pf_mbox_mapping.paddr);
+   if (rc)
+   goto out;
if (reply->status != BNX2X_VF_STATUS_SUCCESS) {
PMD_DRV_LOG(ERR, "Failed to init VF");
rc = -EINVAL;
@@ -399,7 +399,7 @@ bnx2x_vf_unload(struct bnx2x_softc *sc)
struct vf_close_tlv *query;
struct vf_common_reply_tlv *reply = >vf2pf_mbox->resp.common_reply;
struct vf_q_op_tlv 

[dpdk-dev] [PATCH 07/10] bnx2x: Serialize access to pf2vf mailbox

2016-07-12 Thread Chas Williams
The pf2vf mailbox can only be used by one thread at a time.

Fixes: 540a211084a7 ("bnx2x: driver core")

Signed-off-by: Chas Williams <3chas3 at gmail.com>
---
 drivers/net/bnx2x/bnx2x.h|  12 +++--
 drivers/net/bnx2x/bnx2x_ethdev.c |   2 +
 drivers/net/bnx2x/bnx2x_vfpf.c   | 113 +++
 3 files changed, 88 insertions(+), 39 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 2746562..d0d5b65 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -17,6 +17,7 @@
 #define __BNX2X_H__

 #include 
+#include 

 #if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
 #ifndef __LITTLE_ENDIAN
@@ -1026,12 +1027,13 @@ struct bnx2x_softc {
struct bnx2x_mac_ops mac_ops;

/* structures for VF mbox/response/bulletin */
-   struct bnx2x_vf_mbx_msg *vf2pf_mbox;
-   struct bnx2x_dmavf2pf_mbox_mapping;
-   struct vf_acquire_resp_tlv acquire_resp;
+   struct bnx2x_vf_mbx_msg *vf2pf_mbox;
+   struct bnx2x_dma vf2pf_mbox_mapping;
+   struct vf_acquire_resp_tlv   acquire_resp;
struct bnx2x_vf_bulletin*pf2vf_bulletin;
-   struct bnx2x_dmapf2vf_bulletin_mapping;
-   struct bnx2x_vf_bulletinold_bulletin;
+   struct bnx2x_dma pf2vf_bulletin_mapping;
+   struct bnx2x_vf_bulletin old_bulletin;
+   rte_spinlock_t   vf2pf_lock;

int media;

diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 047b782..88be036 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -460,6 +460,8 @@ bnx2x_common_dev_init(struct rte_eth_dev *eth_dev, int 
is_vf)
eth_dev->data->port_id, pci_dev->id.vendor_id, 
pci_dev->id.device_id);

if (IS_VF(sc)) {
+   rte_spinlock_init(>vf2pf_lock);
+
if (bnx2x_dma_alloc(sc, sizeof(struct bnx2x_vf_mbx_msg),
>vf2pf_mbox_mapping, "vf2pf_mbox",
RTE_CACHE_LINE_SIZE) != 0)
diff --git a/drivers/net/bnx2x/bnx2x_vfpf.c b/drivers/net/bnx2x/bnx2x_vfpf.c
index 46bf739..46b56b4 100644
--- a/drivers/net/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/bnx2x/bnx2x_vfpf.c
@@ -78,10 +78,13 @@ bnx2x_add_tlv(__rte_unused struct bnx2x_softc *sc, void 
*tlvs_list,

 /* Initiliaze header of the first tlv and clear mailbox*/
 static void
-bnx2x_init_first_tlv(struct bnx2x_softc *sc, struct vf_first_tlv *first_tlv,
-   uint16_t type, uint16_t length)
+bnx2x_vf_prep(struct bnx2x_softc *sc, struct vf_first_tlv *first_tlv,
+ uint16_t type, uint16_t length)
 {
struct bnx2x_vf_mbx_msg *mbox = sc->vf2pf_mbox;
+
+   rte_spinlock_lock(>vf2pf_lock);
+
PMD_DRV_LOG(DEBUG, "Preparing %d tlv for sending", type);

memset(mbox, 0, sizeof(struct bnx2x_vf_mbx_msg));
@@ -92,6 +95,17 @@ bnx2x_init_first_tlv(struct bnx2x_softc *sc, struct 
vf_first_tlv *first_tlv,
first_tlv->reply_offset = sizeof(mbox->query);
 }

+/* releases the mailbox */
+static void
+bnx2x_vf_finalize(struct bnx2x_softc *sc,
+ __rte_unused struct vf_first_tlv *first_tlv)
+{
+   PMD_DRV_LOG(DEBUG, "done sending [%d] tlv over vf pf channel",
+   first_tlv->tl.type);
+
+   rte_spinlock_unlock(>vf2pf_lock);
+}
+
 #define BNX2X_VF_CMD_ADDR_LO PXP_VF_ADDR_CSDM_GLOBAL_START
 #define BNX2X_VF_CMD_ADDR_HI BNX2X_VF_CMD_ADDR_LO + 4
 #define BNX2X_VF_CMD_TRIGGER BNX2X_VF_CMD_ADDR_HI + 4
@@ -244,13 +258,16 @@ int bnx2x_vf_get_resources(struct bnx2x_softc *sc, 
uint8_t tx_count, uint8_t rx_
struct vf_acquire_tlv *acq = >vf2pf_mbox->query[0].acquire;
int vf_id;
struct bnx2x_obtain_status obtain_status;
+   int rc = 0;

bnx2x_vf_close(sc);
-   bnx2x_init_first_tlv(sc, >first_tlv, BNX2X_VF_TLV_ACQUIRE, 
sizeof(*acq));
+   bnx2x_vf_prep(sc, >first_tlv, BNX2X_VF_TLV_ACQUIRE, sizeof(*acq));

vf_id = bnx2x_read_vf_id(sc);
-   if (vf_id < 0)
-   return -EAGAIN;
+   if (vf_id < 0) {
+   rc = -EAGAIN;
+   goto out;
+   }

acq->vf_id = vf_id;

@@ -274,8 +291,10 @@ int bnx2x_vf_get_resources(struct bnx2x_softc *sc, uint8_t 
tx_count, uint8_t rx_

/* requesting the resources in loop */
obtain_status = bnx2x_loop_obtain_resources(sc);
-   if (!obtain_status.success)
-   return obtain_status.err_code;
+   if (!obtain_status.success) {
+   rc = obtain_status.err_code;
+   goto out;
+   }

struct vf_acquire_resp_tlv sc_resp = sc->acquire_resp;

@@ -305,7 +324,10 @@ int bnx2x_vf_get_resources(struct bnx2x_softc *sc, uint8_t 
tx_count, uint8_t rx_
   sc_resp.resc.current_mac_addr,
   ETH_ALEN);

-   return 0;
+out:
+   bnx2x_vf_finalize(sc, 

[dpdk-dev] [PATCH 06/10] bnx2x: Replace macro with static function

2016-07-12 Thread Chas Williams
Replace BNX2X_TLV_APPEND() with the clearer and safer bnx2x_add_tlv().
bnx2x_add_tlv() was previously prototyped at some point but can be static.

Fixes: 540a211084a7 ("bnx2x: driver core")

Signed-off-by: Chas Williams <3chas3 at gmail.com>
---
 drivers/net/bnx2x/bnx2x_vfpf.c | 80 +-
 drivers/net/bnx2x/bnx2x_vfpf.h | 10 ++
 2 files changed, 50 insertions(+), 40 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x_vfpf.c b/drivers/net/bnx2x/bnx2x_vfpf.c
index 1b4899f..46bf739 100644
--- a/drivers/net/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/bnx2x/bnx2x_vfpf.c
@@ -64,25 +64,32 @@ bnx2x_check_bull(struct bnx2x_softc *sc)
return TRUE;
 }

-/* add tlv to a buffer */
-#define BNX2X_TLV_APPEND(_tlvs, _offset, _type, _length) \
-   ((struct vf_first_tlv *)((unsigned long)_tlvs + _offset))->type   = 
_type; \
-   ((struct vf_first_tlv *)((unsigned long)_tlvs + _offset))->length = 
_length
+/* place a given tlv on the tlv buffer at a given offset */
+static void
+bnx2x_add_tlv(__rte_unused struct bnx2x_softc *sc, void *tlvs_list,
+ uint16_t offset, uint16_t type, uint16_t length)
+{
+   struct channel_tlv *tl = (struct channel_tlv *)
+   ((unsigned long)tlvs_list + offset);
+
+   tl->type = type;
+   tl->length = length;
+}

 /* Initiliaze header of the first tlv and clear mailbox*/
 static void
-bnx2x_init_first_tlv(struct bnx2x_softc *sc, struct vf_first_tlv *tlv,
-   uint16_t type, uint16_t len)
+bnx2x_init_first_tlv(struct bnx2x_softc *sc, struct vf_first_tlv *first_tlv,
+   uint16_t type, uint16_t length)
 {
struct bnx2x_vf_mbx_msg *mbox = sc->vf2pf_mbox;
PMD_DRV_LOG(DEBUG, "Preparing %d tlv for sending", type);

memset(mbox, 0, sizeof(struct bnx2x_vf_mbx_msg));

-   BNX2X_TLV_APPEND(tlv, 0, type, len);
+   bnx2x_add_tlv(sc, _tlv->tl, 0, type, length);

/* Initialize header of the first tlv */
-   tlv->reply_offset = sizeof(mbox->query);
+   first_tlv->reply_offset = sizeof(mbox->query);
 }

 #define BNX2X_VF_CMD_ADDR_LO PXP_VF_ADDR_CSDM_GLOBAL_START
@@ -256,14 +263,14 @@ int bnx2x_vf_get_resources(struct bnx2x_softc *sc, 
uint8_t tx_count, uint8_t rx_
acq->bulletin_addr = sc->pf2vf_bulletin_mapping.paddr;

/* Request physical port identifier */
-   BNX2X_TLV_APPEND(acq, acq->first_tlv.length,
-BNX2X_VF_TLV_PHYS_PORT_ID,
-sizeof(struct channel_tlv));
+   bnx2x_add_tlv(sc, acq, acq->first_tlv.tl.length,
+ BNX2X_VF_TLV_PHYS_PORT_ID,
+ sizeof(struct channel_tlv));

-   BNX2X_TLV_APPEND(acq,
-(acq->first_tlv.length + sizeof(struct channel_tlv)),
-BNX2X_VF_TLV_LIST_END,
-sizeof(struct channel_list_end_tlv));
+   bnx2x_add_tlv(sc, acq,
+ (acq->first_tlv.tl.length + sizeof(struct channel_tlv)),
+ BNX2X_VF_TLV_LIST_END,
+ sizeof(struct channel_list_end_tlv));

/* requesting the resources in loop */
obtain_status = bnx2x_loop_obtain_resources(sc);
@@ -315,8 +322,9 @@ bnx2x_vf_close(struct bnx2x_softc *sc)
sizeof(*query));

query->vf_id = vf_id;
-   BNX2X_TLV_APPEND(query, query->first_tlv.length, 
BNX2X_VF_TLV_LIST_END,
-   sizeof(struct channel_list_end_tlv));
+   bnx2x_add_tlv(sc, query, query->first_tlv.tl.length,
+ BNX2X_VF_TLV_LIST_END,
+ sizeof(struct channel_list_end_tlv));

bnx2x_do_req4pf(sc, sc->vf2pf_mbox_mapping.paddr);
if (reply->status != BNX2X_VF_STATUS_SUCCESS)
@@ -344,8 +352,9 @@ bnx2x_vf_init(struct bnx2x_softc *sc)
query->stats_addr = sc->fw_stats_data_mapping +
offsetof(struct bnx2x_fw_stats_data, queue_stats);

-   BNX2X_TLV_APPEND(query, query->first_tlv.length, BNX2X_VF_TLV_LIST_END,
-   sizeof(struct channel_list_end_tlv));
+   bnx2x_add_tlv(sc, query, query->first_tlv.tl.length,
+ BNX2X_VF_TLV_LIST_END,
+ sizeof(struct channel_list_end_tlv));

bnx2x_do_req4pf(sc, sc->vf2pf_mbox_mapping.paddr);
if (reply->status != BNX2X_VF_STATUS_SUCCESS) {
@@ -375,9 +384,10 @@ bnx2x_vf_unload(struct bnx2x_softc *sc)

query_op->vf_qid = i;

-   BNX2X_TLV_APPEND(query_op, query_op->first_tlv.length,
-   BNX2X_VF_TLV_LIST_END,
-   sizeof(struct channel_list_end_tlv));
+   bnx2x_add_tlv(sc, query_op,
+ query_op->first_tlv.tl.length,
+ BNX2X_VF_TLV_LIST_END,
+

[dpdk-dev] [PATCH 05/10] bnx2x: Restrict RX mask flags sent to the PF

2016-07-12 Thread Chas Williams
Don't use bnx2x_fill_accept_flags() to fill the RX mask in the VF
since the PF only handles a subset of the existing flags.  now,
bnx2x_fill_accept_flags() can be static.

Fixes: 540a211084a7 ("bnx2x: driver core")

Signed-off-by: Chas Williams <3chas3 at gmail.com>
---
 drivers/net/bnx2x/bnx2x.c  |  6 +++---
 drivers/net/bnx2x/bnx2x.h  |  2 --
 drivers/net/bnx2x/bnx2x_vfpf.c | 23 +--
 drivers/net/bnx2x/bnx2x_vfpf.h |  7 +++
 4 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 7599e9c..6ca6ede 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -1396,10 +1396,10 @@ bnx2x_del_all_macs(struct bnx2x_softc *sc, struct 
ecore_vlan_mac_obj *mac_obj,
return rc;
 }

-int
+static int
 bnx2x_fill_accept_flags(struct bnx2x_softc *sc, uint32_t rx_mode,
- unsigned long *rx_accept_flags,
- unsigned long *tx_accept_flags)
+   unsigned long *rx_accept_flags,
+   unsigned long *tx_accept_flags)
 {
/* Clear the flags first */
*rx_accept_flags = 0;
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 852ec94..2746562 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -1878,8 +1878,6 @@ int bnx2x_vf_setup_queue(struct bnx2x_softc *sc, struct 
bnx2x_fastpath *fp,
int leading);
 void bnx2x_free_hsi_mem(struct bnx2x_softc *sc);
 int bnx2x_vf_set_rx_mode(struct bnx2x_softc *sc);
-int bnx2x_fill_accept_flags(struct bnx2x_softc *sc, uint32_t rx_mode,
-   unsigned long *rx_accept_flags, unsigned long *tx_accept_flags);
 int bnx2x_check_bull(struct bnx2x_softc *sc);

 //#define BNX2X_PULSE
diff --git a/drivers/net/bnx2x/bnx2x_vfpf.c b/drivers/net/bnx2x/bnx2x_vfpf.c
index 14b1d10..1b4899f 100644
--- a/drivers/net/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/bnx2x/bnx2x_vfpf.c
@@ -575,7 +575,6 @@ bnx2x_vf_set_rx_mode(struct bnx2x_softc *sc)
 {
struct vf_set_q_filters_tlv *query;
struct vf_common_reply_tlv *reply = >vf2pf_mbox->resp.common_reply;
-   unsigned long tx_mask;

query = >vf2pf_mbox->query[0].set_q_filters;
bnx2x_init_first_tlv(sc, >first_tlv, BNX2X_VF_TLV_SET_Q_FILTERS,
@@ -584,7 +583,27 @@ bnx2x_vf_set_rx_mode(struct bnx2x_softc *sc)
query->vf_qid = 0;
query->flags = BNX2X_VF_RX_MASK_CHANGED;

-   if (bnx2x_fill_accept_flags(sc, sc->rx_mode, >rx_mask, 
_mask)) {
+   switch (sc->rx_mode) {
+   case BNX2X_RX_MODE_NONE: /* no Rx */
+   query->rx_mask = VFPF_RX_MASK_ACCEPT_NONE;
+   break;
+   case BNX2X_RX_MODE_NORMAL:
+   query->rx_mask = VFPF_RX_MASK_ACCEPT_MATCHED_MULTICAST;
+   query->rx_mask |= VFPF_RX_MASK_ACCEPT_MATCHED_UNICAST;
+   query->rx_mask |= VFPF_RX_MASK_ACCEPT_BROADCAST;
+   break;
+   case BNX2X_RX_MODE_ALLMULTI:
+   query->rx_mask = VFPF_RX_MASK_ACCEPT_ALL_MULTICAST;
+   query->rx_mask |= VFPF_RX_MASK_ACCEPT_MATCHED_UNICAST;
+   query->rx_mask |= VFPF_RX_MASK_ACCEPT_BROADCAST;
+   break;
+   case BNX2X_RX_MODE_PROMISC:
+   query->rx_mask = VFPF_RX_MASK_ACCEPT_ALL_UNICAST;
+   query->rx_mask |= VFPF_RX_MASK_ACCEPT_ALL_MULTICAST;
+   query->rx_mask |= VFPF_RX_MASK_ACCEPT_BROADCAST;
+   break;
+   default:
+   PMD_DRV_LOG(ERR, "BAD rx mode (%d)", mode);
return -EINVAL;
}

diff --git a/drivers/net/bnx2x/bnx2x_vfpf.h b/drivers/net/bnx2x/bnx2x_vfpf.h
index 966240c..62e1d60 100644
--- a/drivers/net/bnx2x/bnx2x_vfpf.h
+++ b/drivers/net/bnx2x/bnx2x_vfpf.h
@@ -40,6 +40,13 @@ struct vf_resource_query {

 #define TLV_BUFFER_SIZE1024

+#define VFPF_RX_MASK_ACCEPT_NONE   0x
+#define VFPF_RX_MASK_ACCEPT_MATCHED_UNICAST0x0001
+#define VFPF_RX_MASK_ACCEPT_MATCHED_MULTICAST  0x0002
+#define VFPF_RX_MASK_ACCEPT_ALL_UNICAST0x0004
+#define VFPF_RX_MASK_ACCEPT_ALL_MULTICAST  0x0008
+#define VFPF_RX_MASK_ACCEPT_BROADCAST  0x0010
+
 /* general tlv header (used for both vf->pf request and pf->vf response) */
 struct channel_tlv {
uint16_t type;
-- 
2.5.5



[dpdk-dev] [PATCH 04/10] bnx2x: Remove unused RX queue code

2016-07-12 Thread Chas Williams
Fixes: 540a211084a7 ("bnx2x: driver core")

Signed-off-by: Chas Williams <3chas3 at gmail.com>
---
 drivers/net/bnx2x/bnx2x_rxtx.c | 13 +++--
 drivers/net/bnx2x/bnx2x_rxtx.h |  6 --
 2 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x_rxtx.c b/drivers/net/bnx2x/bnx2x_rxtx.c
index 55d2bd7..2bd48d9 100644
--- a/drivers/net/bnx2x/bnx2x_rxtx.c
+++ b/drivers/net/bnx2x/bnx2x_rxtx.c
@@ -59,7 +59,7 @@ bnx2x_dev_rx_queue_setup(struct rte_eth_dev *dev,
   uint16_t queue_idx,
   uint16_t nb_desc,
   unsigned int socket_id,
-  const struct rte_eth_rxconf *rx_conf,
+  __rte_unused const struct rte_eth_rxconf *rx_conf,
   struct rte_mempool *mp)
 {
uint16_t j, idx;
@@ -84,7 +84,6 @@ bnx2x_dev_rx_queue_setup(struct rte_eth_dev *dev,
rxq->mb_pool = mp;
rxq->queue_id = queue_idx;
rxq->port_id = dev->data->port_id;
-   rxq->crc_len = (uint8_t)((dev->data->dev_conf.rxmode.hw_strip_crc) ? 0 
: ETHER_CRC_LEN);

rxq->nb_rx_pages = 1;
while (USABLE_RX_BD(rxq) < nb_desc)
@@ -94,13 +93,9 @@ bnx2x_dev_rx_queue_setup(struct rte_eth_dev *dev,
sc->rx_ring_size = USABLE_RX_BD(rxq);
rxq->nb_cq_pages = RCQ_BD_PAGES(rxq);

-   rxq->rx_free_thresh = rx_conf->rx_free_thresh ?
-   rx_conf->rx_free_thresh : DEFAULT_RX_FREE_THRESH;
-
-   PMD_INIT_LOG(DEBUG, "fp[%02d] req_bd=%u, thresh=%u, usable_bd=%lu, "
+   PMD_INIT_LOG(DEBUG, "fp[%02d] req_bd=%u, usable_bd=%lu, "
   "total_bd=%lu, rx_pages=%u, cq_pages=%u",
-  queue_idx, nb_desc, rxq->rx_free_thresh,
-  (unsigned long)USABLE_RX_BD(rxq),
+  queue_idx, nb_desc, (unsigned long)USABLE_RX_BD(rxq),
   (unsigned long)TOTAL_RX_BD(rxq), rxq->nb_rx_pages,
   rxq->nb_cq_pages);

@@ -135,7 +130,6 @@ bnx2x_dev_rx_queue_setup(struct rte_eth_dev *dev,
}

/* Initialize software ring entries */
-   rxq->rx_mbuf_alloc = 0;
for (idx = 0; idx < rxq->nb_rx_desc; idx = NEXT_RX_BD(idx)) {
mbuf = rte_mbuf_raw_alloc(mp);
if (NULL == mbuf) {
@@ -146,7 +140,6 @@ bnx2x_dev_rx_queue_setup(struct rte_eth_dev *dev,
}
rxq->sw_ring[idx] = mbuf;
rxq->rx_ring[idx] = mbuf->buf_physaddr;
-   rxq->rx_mbuf_alloc++;
}
rxq->pkt_first_seg = NULL;
rxq->pkt_last_seg = NULL;
diff --git a/drivers/net/bnx2x/bnx2x_rxtx.h b/drivers/net/bnx2x/bnx2x_rxtx.h
index ccb22fc..dd251aa 100644
--- a/drivers/net/bnx2x/bnx2x_rxtx.h
+++ b/drivers/net/bnx2x/bnx2x_rxtx.h
@@ -11,8 +11,6 @@
 #ifndef _BNX2X_RXTX_H_
 #define _BNX2X_RXTX_H_

-
-#define DEFAULT_RX_FREE_THRESH   0
 #define DEFAULT_TX_FREE_THRESH   512
 #define RTE_PMD_BNX2X_TX_MAX_BURST 1

@@ -42,13 +40,9 @@ struct bnx2x_rx_queue {
uint16_t   rx_bd_tail;   /**< Index of last rx 
bd. */
uint16_t   rx_cq_head;   /**< Index of current 
rcq bd. */
uint16_t   rx_cq_tail;   /**< Index of last rcq 
bd. */
-   uint16_t   nb_rx_hold;   /**< number of held 
free RX desc. */
-   uint16_t   rx_free_thresh;   /**< max free RX desc 
to hold. */
uint16_t   queue_id; /**< RX queue index. */
uint8_tport_id;  /**< Device port 
identifier. */
-   uint8_tcrc_len;  /**< 0 if CRC 
stripped, 4 otherwise. */
struct bnx2x_softc   *sc;  /**< Ptr to 
dev_private data. */
-   uint64_t   rx_mbuf_alloc;/**< Number of 
allocated mbufs. */
 };

 /**
-- 
2.5.5



[dpdk-dev] [PATCH 03/10] bnx2x: Remove delay during device startup

2016-07-12 Thread Chas Williams
This 2.5s delay doesn't seem to serve any purpose other than a being a
pause after logging the device configuration.

Fixes: 540a211084a7 ("bnx2x: driver core")

Signed-off-by: Chas Williams <3chas3 at gmail.com>
---
 drivers/net/bnx2x/bnx2x_ethdev.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 071b44f..047b782 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -154,8 +154,6 @@ bnx2x_dev_start(struct rte_eth_dev *dev)
/* Print important adapter info for the user. */
bnx2x_print_adapter_info(sc);

-   DELAY_MS(2500);
-
return ret;
 }

-- 
2.5.5



[dpdk-dev] [PATCH 02/10] bnx2x: Remove unused preprocessor symbols and code

2016-07-12 Thread Chas Williams
ELINK_INCLUDE_EMUL and ELINK_INCLUDE_FPGA are never defined.  Remove them
along with enumeration constants dependent on their inclusion.

Fixes: 540a211084a7 ("bnx2x: driver core")

Signed-off-by: Chas Williams <3chas3 at gmail.com>
---
 drivers/net/bnx2x/bnx2x.c |  28 
 drivers/net/bnx2x/elink.c | 392 --
 drivers/net/bnx2x/elink.h |   4 -
 3 files changed, 64 insertions(+), 360 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 6edb2f9..7599e9c 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -7035,34 +7035,6 @@ static int bnx2x_initial_phy_init(struct bnx2x_softc 
*sc, int load_mode)

bnx2x_set_requested_fc(sc);

-   if (CHIP_REV_IS_SLOW(sc)) {
-   uint32_t bond = CHIP_BOND_ID(sc);
-   uint32_t feat = 0;
-
-   if (CHIP_IS_E2(sc) && CHIP_IS_MODE_4_PORT(sc)) {
-   feat |= ELINK_FEATURE_CONFIG_EMUL_DISABLE_BMAC;
-   } else if (bond & 0x4) {
-   if (CHIP_IS_E3(sc)) {
-   feat |= ELINK_FEATURE_CONFIG_EMUL_DISABLE_XMAC;
-   } else {
-   feat |= ELINK_FEATURE_CONFIG_EMUL_DISABLE_BMAC;
-   }
-   } else if (bond & 0x8) {
-   if (CHIP_IS_E3(sc)) {
-   feat |= ELINK_FEATURE_CONFIG_EMUL_DISABLE_UMAC;
-   } else {
-   feat |= ELINK_FEATURE_CONFIG_EMUL_DISABLE_EMAC;
-   }
-   }
-
-/* disable EMAC for E3 and above */
-   if (bond & 0x2) {
-   feat |= ELINK_FEATURE_CONFIG_EMUL_DISABLE_EMAC;
-   }
-
-   sc->link_params.feature_config_flags |= feat;
-   }
-
if (load_mode == LOAD_DIAG) {
lp->loopback_mode = ELINK_LOOPBACK_XGXS;
 /* Prefer doing PHY loopback at 10G speed, if possible */
diff --git a/drivers/net/bnx2x/elink.c b/drivers/net/bnx2x/elink.c
index b9149b8..3a3bb30 100644
--- a/drivers/net/bnx2x/elink.c
+++ b/drivers/net/bnx2x/elink.c
@@ -1586,26 +1586,6 @@ static elink_status_t elink_emac_enable(struct 
elink_params *params,
/* enable emac and not bmac */
REG_WR(sc, NIG_REG_EGRESS_EMAC0_PORT + port * 4, 1);

-#ifdef ELINK_INCLUDE_EMUL
-   /* for paladium */
-   if (CHIP_REV_IS_EMUL(sc)) {
-   /* Use lane 1 (of lanes 0-3) */
-   REG_WR(sc, NIG_REG_XGXS_LANE_SEL_P0 + port * 4, 1);
-   REG_WR(sc, NIG_REG_XGXS_SERDES0_MODE_SEL + port * 4, 1);
-   }
-   /* for fpga */
-   else
-#endif
-#ifdef ELINK_INCLUDE_FPGA
-   if (CHIP_REV_IS_FPGA(sc)) {
-   /* Use lane 1 (of lanes 0-3) */
-   PMD_DRV_LOG(DEBUG, "elink_emac_enable: Setting FPGA");
-
-   REG_WR(sc, NIG_REG_XGXS_LANE_SEL_P0 + port * 4, 1);
-   REG_WR(sc, NIG_REG_XGXS_SERDES0_MODE_SEL + port * 4, 0);
-   } else
-#endif
-   /* ASIC */
if (vars->phy_flags & PHY_XGXS_FLAG) {
uint32_t ser_lane = ((params->lane_config &
  PORT_HW_CFG_LANE_SWAP_CFG_MASTER_MASK) >>
@@ -1628,39 +1608,28 @@ static elink_status_t elink_emac_enable(struct 
elink_params *params,
elink_bits_en(sc, emac_base + EMAC_REG_EMAC_TX_MODE,
  EMAC_TX_MODE_RESET);

-#if defined(ELINK_INCLUDE_EMUL) || defined(ELINK_INCLUDE_FPGA)
-   if (CHIP_REV_IS_SLOW(sc)) {
-   /* config GMII mode */
-   val = REG_RD(sc, emac_base + EMAC_REG_EMAC_MODE);
-   elink_cb_reg_write(sc, emac_base + EMAC_REG_EMAC_MODE,
-  (val | EMAC_MODE_PORT_GMII));
-   } else {/* ASIC */
-#endif
-   /* pause enable/disable */
-   elink_bits_dis(sc, emac_base + EMAC_REG_EMAC_RX_MODE,
-  EMAC_RX_MODE_FLOW_EN);
+   /* pause enable/disable */
+   elink_bits_dis(sc, emac_base + EMAC_REG_EMAC_RX_MODE,
+  EMAC_RX_MODE_FLOW_EN);

-   elink_bits_dis(sc, emac_base + EMAC_REG_EMAC_TX_MODE,
-  (EMAC_TX_MODE_EXT_PAUSE_EN |
-   EMAC_TX_MODE_FLOW_EN));
-   if (!(params->feature_config_flags &
- ELINK_FEATURE_CONFIG_PFC_ENABLED)) {
-   if (vars->flow_ctrl & ELINK_FLOW_CTRL_RX)
-   elink_bits_en(sc, emac_base +
- EMAC_REG_EMAC_RX_MODE,
- EMAC_RX_MODE_FLOW_EN);
-
-   if (vars->flow_ctrl & ELINK_FLOW_CTRL_TX)
-   elink_bits_en(sc, emac_base +
- EMAC_REG_EMAC_TX_MODE,
- 

[dpdk-dev] mutli process C/S model example init failed on xen dom0 with dpdk-16.07 rc2 package

2016-07-12 Thread Xu, HuilongX
Hi all,
I run mutli procee C/S model example failed on xen dom0. Does anyone give me 
some suggest how to debug it?
Thanks a lot

test environment:
  OS: 3.17.4-301.fc21.x86_64
Gcc version: gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC)
Package :dpdk.16.07-rc1.tar.gz
Target: x86_64-native-linuxapp-gcc
Compile switch: enable CONFIG_RTE_LIBRTE_XEN_DOM0
Xen version:4.4.1
Test cmdline and result:
/examples/multi_process/client_server_mp/mp_server/mp_server/x86_64-native-linuxapp-gcc/mp_server
 -c f -n 4 --xen-dom0 -- -p 0x3 -n 2
EAL: Detected 72 lcore(s)
EAL: Probing VFIO support...
PMD: bnxt_rte_pmd_init() called for (null)
EAL: PCI device :01:00.0 on NUMA socket 0
EAL: probe driver: 8086:1521 rte_igb_pmd
EAL: PCI device :01:00.1 on NUMA socket 0
EAL: probe driver: 8086:1521 rte_igb_pmd
EAL: PCI device :04:00.0 on NUMA socket 0
EAL: probe driver: 8086:10fb rte_ixgbe_pmd
EAL: PCI device :04:00.1 on NUMA socket 0
EAL: probe driver: 8086:10fb rte_ixgbe_pmd
Creating mbuf pool 'MProc_pktmbuf_pool' [6144 mbufs] ...
Port 0 init ... Segmentation fault (core dumped)


[dpdk-dev] No RX frames on Intel 82599 VF

2016-07-12 Thread Garik E
On Tue, Jul 12, 2016 at 7:48 AM, Garik E  wrote:

> Hi,
>
> On the S2600WT2 server, when DPDK is bound to VF, there is no incoming
> traffic.
> But when the same VF is bound to ixgbevf driver and configured as Linux
> interface,
> it works normally. I was able to run ping and ssh through that VF.
> So my guess is that the RX issue is not due to malfunction hardware.
>
> The same binary works correctly on S2600WTTR server with 82599 VF
> I also tested the application with Mellanox ConnectX-4 on both servers
> There were no issues with CX-4 PF and VF
>
> For some reason DPDK 82599 VF RX functionality does not work on S2600WT2.
>
>
>
>
>
> On Tue, Jul 12, 2016 at 4:24 AM, Lu, Wenzhuo  wrote:
>
>> Hi Garik,
>>
>> > -Original Message-
>> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Garik E
>> > Sent: Tuesday, July 12, 2016 2:22 AM
>> > To: dev at dpdk.org
>> > Subject: [dpdk-dev] No RX frames on Intel 82599 VF
>> >
>> > Hello,
>> >
>> >
>> > I have two Intel servers S2600WTTR and S2600WT2 both with 82599 10G
>> > Ethernet Controllers
>> >
>> > I run the same DPDK application on both servers.
>> >
>> > The application works with one interface bound to physical or virtual
>> PCI
>> > function depending on configuration
>> >
>> > The S2600WTTR server receives incoming traffic on physical and virtual
>> > functions
>> S2600WTTR is working right?
>>
>> >
>> > The S2600WT2 server receives traffic only on physical function
>> >
>> > When I bind S2600WT2 VF to ixgbevf driver and configure it as Linux ETH
>> > interface, it works normally.
>> Don't understand what you're doing here. And you say *works*? Is S2600WT2
>> the one not working?
>>
>> >
>> >
>> > Network sniffer shows that Ethernet frames arrive to S2600WT2 port and
>> > frames are valid,
>> >
>> > however DPDK does not receive them.
>> >
>> >
>> > Where can I start to debug this issue ?
>> >
>> >
>> > OS: RHEL 6.6 x86-64
>> >
>> > DPDK: 16-07-rc1
>>
>
>


[dpdk-dev] [PATCH] vhost: fix segfault on bad descriptor address.

2016-07-12 Thread Ilya Maximets
On 12.07.2016 05:43, Yuanhan Liu wrote:
> On Mon, Jul 11, 2016 at 02:47:56PM +0300, Ilya Maximets wrote:
>> On 11.07.2016 14:05, Yuanhan Liu wrote:
>>> On Mon, Jul 11, 2016 at 12:50:24PM +0300, Ilya Maximets wrote:
 On 11.07.2016 11:38, Yuanhan Liu wrote:
> On Sun, Jul 10, 2016 at 09:17:31PM +0800, Yuanhan Liu wrote:
>> On Fri, Jul 08, 2016 at 02:48:56PM +0300, Ilya Maximets wrote:
>>>
>>> Another point is that crash constantly happens on queue_id=3 (second RX 
>>> queue) in
>>> my scenario. It is newly allocated virtqueue while reconfiguration from 
>>> rxq=1 to
>>> rxq=2.
>>
>> That's a valuable message: what's your DPDK HEAD commit while triggering
>> this issue?

 fbfd99551ca3 ("mbuf: add raw allocation function")

>
> I guess I have understood what goes wrong in you case.
>
> I would guess that your vhost has 2 queues (here I mean queue-pairs,
> including one Tx and Rx queue; below usage is the same) configured,
> so does to your QEMU. However, you just enabled 1 queue while starting
> testpmd inside the guest, and you want to enable 2 queues by running
> following testpmd commands:
>
> stop
> port stop all
> port config all rxq 2
> port config all txq 2
> port start all
>
> Badly, that won't work for current virtio PMD implementation, and what's
> worse, it triggers a vhost crash, the one you saw.
>
> Here is how it comes. Since you just enabled 1 queue while starting
> testpmd, it will setup 1 queue only, meaning only one queue's **valid**
> information will be sent to vhost. You might see SET_VRING_ADDR
> (and related vhost messages) for the other queue as well, but they
> are just the dummy messages: they don't include any valid/real
> information about the 2nd queue: the driver don't setup it after all.
>
> So far, so good. It became broken when you run above commands. Those
> commands do setup for the 2nd queue, however, they failed to trigger
> the QEMU virtio device to start the vhost-user negotiation, meaning
> no SET_VRING_ADDR will be sent for the 2nd queue, leaving vhost
> untold and not updated.
>
> What's worse, above commands trigger the QEMU to send SET_VRING_ENABLE
> messages, to enable all the vrings. And since the vrings for the 2nd
> queue are not properly configured, the crash happens.

 Hmm, why 2nd queue works properly with my fix to vhost in this case?
>>>
>>> Hmm, really? You are sure that data flows in your 2nd queue after those
>>> commands? From what I know is that your patch just avoid a crash, but
>>> does not fix it.
>>
>> Oh, sorry. Yes, it doesn't work. With my patch applied I have a QEMU hang.
> 
> The crash actually could be avoided by commit 0823c1cb0a73 ("vhost:
> workaround stale vring base"), accidentally. That's why I asked you
> above the HEAD commit you were using.

Thanks for pointing this. I'll check it.

> So maybe we should do virtio reset on port start?

 I guess it was removed by this patch:
 a85786dc816f ("virtio: fix states handling during initialization").
>>>
>>> Seems yes.
> 
> Actually, we should not do that: do reset on port start. The right fix
> should be allocating MAX queues virtio device supports (2 here). This
> would allow us changing the queue number dynamically.

Yes, I agree that this is the right way to fix this issue.

> But this doesn't sound a simple fix; it involves many code changes, due
> to it was not designed this way before. Therefore, we will not fix it
> in this release, due to it's too late. Let's fix it in the next release
> instead. For the crash issue, it will not happen with the latest HEAD.
> Though it's accident fix, I think we are fine here.
> 
>   --yliu
> 
> 


[dpdk-dev] No RX frames on Intel 82599 VF

2016-07-12 Thread Lu, Wenzhuo
From: Garik E [mailto:kira...@gmail.com]
Sent: Tuesday, July 12, 2016 12:48 PM
To: Lu, Wenzhuo
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] No RX frames on Intel 82599 VF

Hi,

On the S2600WT2 server, when DPDK is bound to VF, there is no incoming traffic.
But when the same VF is bound to ixgbevf driver and configured as Linux 
interface,
it works normally. I was able to run ping and ssh through that VF.
So my guess is that the RX issue is not due to malfunction hardware.

The same binary works correctly on S2600WTTR server with 82599 VF
I also tested the application with Mellanox ConnectX-4 on both servers
There were no issues with CX-4 PF and VF

For some reason DPDK VF RX functionality does not work on S2600WT2.
[Wenzhuo] No clue now. But I think you can compare what?s the difference 
between S2600WT2 and S2600WTTR.



On Tue, Jul 12, 2016 at 4:24 AM, Lu, Wenzhuo mailto:wenzhuo.lu at intel.com>> wrote:
Hi Garik,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On 
> Behalf Of Garik E
> Sent: Tuesday, July 12, 2016 2:22 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] No RX frames on Intel 82599 VF
>
> Hello,
>
>
> I have two Intel servers S2600WTTR and S2600WT2 both with 82599 10G
> Ethernet Controllers
>
> I run the same DPDK application on both servers.
>
> The application works with one interface bound to physical or virtual PCI
> function depending on configuration
>
> The S2600WTTR server receives incoming traffic on physical and virtual
> functions
S2600WTTR is working right?

>
> The S2600WT2 server receives traffic only on physical function
>
> When I bind S2600WT2 VF to ixgbevf driver and configure it as Linux ETH
> interface, it works normally.
Don't understand what you're doing here. And you say *works*? Is S2600WT2 the 
one not working?

>
>
> Network sniffer shows that Ethernet frames arrive to S2600WT2 port and
> frames are valid,
>
> however DPDK does not receive them.
>
>
> Where can I start to debug this issue ?
>
>
> OS: RHEL 6.6 x86-64
>
> DPDK: 16-07-rc1



[dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct location

2016-07-12 Thread Kuusisaari, Juhamatti

Hello,

> > > > -Original Message-
> > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Juhamatti
> > > > Kuusisaari
> > > > Sent: Monday, July 11, 2016 11:21 AM
> > > > To: dev at dpdk.org
> > > > Subject: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to
> > > > correct location
> > > >
> > > > Fix the location of the rte_ring data dependency read barrier.
> > > > It needs to be called before accessing indexed data to ensure that
> > > > the data itself is guaranteed to be correctly updated.
> > > >
> > > > See more details at kernel/Documentation/memory-barriers.txt
> > > > section 'Data dependency barriers'.
> > >
> > >
> > > Any explanation why?
> > > From my point smp_rmb()s are on the proper places here :) Konstantin
> >
> > The problem here is that on a weak memory model system the CPU is
> > allowed to load the address data out-of-order in advance.
> > If the read barrier is after the DEQUEUE, you might end up having the
> > old data there on a race situation when the buffer is continuously full.
> > Having it before the DEQUEUE guarantees that the load is not done in
> > advance.
> 
> Sorry, still didn't see any race condition in the current code.
> Can you provide any particular example?
> From other side, moving smp_rmb() before dequeueing the objects, could
> introduce a race condition, on cpus where later writes can be reordered with
> earlier reads.

Here is a simplified example sequence from time perspective:
1. Consumer CPU (CCPU) loads value y from r->ring[x] out-of-order 
(the key of the problem)
2. Producer CPU (PCPU) updates r->ring[x] to value be z
3. PCPU updates prod_tail to be x
4. CCPU updates cons_head to be x
5. CCPU loads r->ring[x] by using out-of-order loaded value y [is z in reality]

The problem here is that on weak memory model, the CCPU is allowed to load
r->ring[x] value in advance, if it decides to do so (CCPU needs to be able to 
see
in advance that x will be an interesting index worth loading). The index value 
x 
is updated atomically,  but it does not matter here. Also, the write barrier on 
PCPU 
side guarantees that CCPU cannot see update of x before PCPU has really updated 
the r->ring[x] to z and moved the tail, but still allows to do the out-of-order 
loads 
without proper read barrier. 

When the read barrier is moved between steps 4 and 5, it disallows to use 
any out-of-order loads so far and forces to drop r->ring[x] y value and
load current value z. 

The ring queue appears to work well as this is a rare corner case. Due to the 
head,tail-structure the problem needs queue to be full and also CCPU needs 
to see r->ring[x] update later than it does the out-of-order load. In addition,
the HW needs to be able to predict and choose the load to the future index 
(which should be quite possible, considering modern CPUs). If you have seen 
in the past problems and noticed that a larger ring queue works better as a 
workaround, you may have encountered the problem already.

It is quite safe to move the barrier before DEQUEUE because after the DEQUEUE 
there is nothing really that we would want to protect with a read barrier. The 
read 
barrier is mapped to a compiler barrier on strong memory model systems and this 
works fine too as the order of the head,tail updates is still guaranteed on the 
new 
location. Even if the problem would be theoretical on most systems, it is worth 
fixing 
as the risk for problems is very low.

--
 Juhamatti

> Konstantin




> > > >
> > > > Signed-off-by: Juhamatti Kuusisaari
> > > > 
> > > > ---
> > > >  lib/librte_ring/rte_ring.h | 6 --
> > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/lib/librte_ring/rte_ring.h
> > > > b/lib/librte_ring/rte_ring.h index eb45e41..a923e49 100644
> > > > --- a/lib/librte_ring/rte_ring.h
> > > > +++ b/lib/librte_ring/rte_ring.h
> > > > @@ -662,9 +662,10 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r,
> > > void **obj_table,
> > > >   cons_next);
> > > > } while (unlikely(success == 0));
> > > >
> > > > +   rte_smp_rmb();
> > > > +
> > > > /* copy in table */
> > > > DEQUEUE_PTRS();
> > > > -   rte_smp_rmb();
> > > >
> > > > /*
> > > >  * If there are other dequeues in progress that preceded
> > > > us, @@ -746,9 +747,10 @@ __rte_ring_sc_do_dequeue(struct rte_ring
> > > > *r,
> > > void **obj_table,
> > > > cons_next = cons_head + n;
> > > > r->cons.head = cons_next;
> > > >
> > > > +   rte_smp_rmb();
> > > > +
> > > > /* copy in table */
> > > > DEQUEUE_PTRS();
> > > > -   rte_smp_rmb();
> > > >
> > > > __RING_STAT_ADD(r, deq_success, n);
> > > > r->cons.tail = cons_next;
> > > > --
> > > > 2.9.0
> > > >
> > > >
> > > >
> > >
> ==
> > > ==
> > > > The information contained in this message may be privileged and
> > > > confidential and 

[dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct location

2016-07-12 Thread Kuusisaari, Juhamatti
Hello,

> >>> -Original Message-
> >>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Juhamatti
> >>> Kuusisaari
> >>> Sent: Monday, July 11, 2016 11:21 AM
> >>> To: dev at dpdk.org
> >>> Subject: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to
> >>> correct location
> >>>
> >>> Fix the location of the rte_ring data dependency read barrier.
> >>> It needs to be called before accessing indexed data to ensure that
> >>> the data itself is guaranteed to be correctly updated.
> >>>
> >>> See more details at kernel/Documentation/memory-barriers.txt
> >>> section 'Data dependency barriers'.
> >>
> >>
> >> Any explanation why?
> >> From my point smp_rmb()s are on the proper places here :) Konstantin
> >
> > The problem here is that on a weak memory model system the CPU is
> > allowed to load the address data out-of-order in advance.
> > If the read barrier is after the DEQUEUE, you might end up having the
> > old data there on a race situation when the buffer is continuously full.
> > Having it before the DEQUEUE guarantees that the load is not done in
> > advance.
> >
> > On Intel, it should not matter due to different memory model, so this
> > is limited to weak memory model systems.
> 
> 
> I agree with Juhamatti. To me, the reading of consumer_head must occur
> before the reading of objects ptrs.
> 
> That was the case before, and this is something I already noticed when I sent
> that mail:
> http://dpdk.org/ml/archives/dev/2014-March/001742.html
> 
> At that time, only Intel CPUs were supported, so it did not make any
> difference.
> 
> Juhamatti, do you have a setup where you can trigger the issue or is it
> something you've seen by code review?

This was found on a code review when we investigated a problem that could have 
caused issues that this kind of bug would introduce. I suppose one would be 
able to see this with very short ring queue lengths and high load, but it 
depends
on the HW used of course too. 

BR,
--
 Juhamatti

> Thanks,
> Olivier


[dpdk-dev] [PATCH] ethdev: ensure consistent port id assignment

2016-07-12 Thread Tootoonchian, Amin
The rte_eth_dev_allocate() code has an implicit assumption that the port
id assignment in the secondary process is consistent with that of the
primary. The current code breaks if the enumeration of ethdevs in
primary and secondary processes are not identical (e.g., when the
black/whitelist and vdev args of the primary and secondary do not match,
or when the primary dynamically adds/removes ethdevs).

To fix this problem, rte_eth_dev_allocate() now looks up port id by name
in a secondary process (making it explicit that ethdevs can only be
created and initialized by the primary process). Upon releasing a port,
the primary process zeros out eth_dev->data to avoid false positives in
port id lookup by rte_eth_dev_get_port_by_name().

Signed-off-by: Amin Tootoonchian 
---
 lib/librte_ether/rte_ethdev.c | 44 +--
 1 file changed, 30 insertions(+), 14 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 0a6e3f1..1801f57 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -195,25 +195,37 @@ rte_eth_dev_allocate(const char *name, enum 
rte_eth_dev_type type)
uint8_t port_id;
struct rte_eth_dev *eth_dev;

-   port_id = rte_eth_dev_find_free_port();
-   if (port_id == RTE_MAX_ETHPORTS) {
-   RTE_PMD_DEBUG_TRACE("Reached maximum number of Ethernet 
ports\n");
-   return NULL;
-   }
-
if (rte_eth_dev_data == NULL)
rte_eth_dev_data_alloc();

-   if (rte_eth_dev_allocated(name) != NULL) {
-   RTE_PMD_DEBUG_TRACE("Ethernet Device with name %s already 
allocated!\n",
-   name);
-   return NULL;
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+   port_id = rte_eth_dev_find_free_port();
+   if (port_id == RTE_MAX_ETHPORTS) {
+   RTE_PMD_DEBUG_TRACE("Reached maximum number of Ethernet 
ports\n");
+   return NULL;
+   }
+
+   if (rte_eth_dev_allocated(name) != NULL) {
+   RTE_PMD_DEBUG_TRACE("Ethernet Device with name %s 
already allocated!\n",
+   name);
+   return NULL;
+   }
+   } else {
+   if (rte_eth_dev_get_port_by_name(name, _id) != 0) {
+   RTE_PMD_DEBUG_TRACE("Ethernet Device with name %s could 
not be found!\n",
+   name);
+   return NULL;
+   }
}

eth_dev = _eth_devices[port_id];
eth_dev->data = _eth_dev_data[port_id];
-   snprintf(eth_dev->data->name, sizeof(eth_dev->data->name), "%s", name);
-   eth_dev->data->port_id = port_id;
+
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+   snprintf(eth_dev->data->name, sizeof(eth_dev->data->name), 
"%s", name);
+   eth_dev->data->port_id = port_id;
+   }
+
eth_dev->attached = DEV_ATTACHED;
eth_dev->dev_type = type;
nb_ports++;
@@ -293,8 +305,10 @@ rte_eth_dev_init(struct rte_pci_driver *pci_drv,
pci_drv->name,
(unsigned) pci_dev->id.vendor_id,
(unsigned) pci_dev->id.device_id);
-   if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
rte_free(eth_dev->data->dev_private);
+   memset(eth_dev->data, 0, sizeof(*rte_eth_dev_data));
+   }
rte_eth_dev_release_port(eth_dev);
return diag;
 }
@@ -330,8 +344,10 @@ rte_eth_dev_uninit(struct rte_pci_device *pci_dev)
/* free ether device */
rte_eth_dev_release_port(eth_dev);

-   if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
rte_free(eth_dev->data->dev_private);
+   memset(eth_dev->data, 0, sizeof(*rte_eth_dev_data));
+   }

eth_dev->pci_dev = NULL;
eth_dev->driver = NULL;
-- 
2.8.1



[dpdk-dev] No RX frames on Intel 82599 VF

2016-07-12 Thread Lu, Wenzhuo
Hi Garik,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Garik E
> Sent: Tuesday, July 12, 2016 2:22 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] No RX frames on Intel 82599 VF
> 
> Hello,
> 
> 
> I have two Intel servers S2600WTTR and S2600WT2 both with 82599 10G
> Ethernet Controllers
> 
> I run the same DPDK application on both servers.
> 
> The application works with one interface bound to physical or virtual PCI
> function depending on configuration
> 
> The S2600WTTR server receives incoming traffic on physical and virtual
> functions
S2600WTTR is working right?

> 
> The S2600WT2 server receives traffic only on physical function
> 
> When I bind S2600WT2 VF to ixgbevf driver and configure it as Linux ETH
> interface, it works normally.
Don't understand what you're doing here. And you say *works*? Is S2600WT2 the 
one not working?

> 
> 
> Network sniffer shows that Ethernet frames arrive to S2600WT2 port and
> frames are valid,
> 
> however DPDK does not receive them.
> 
> 
> Where can I start to debug this issue ?
> 
> 
> OS: RHEL 6.6 x86-64
> 
> DPDK: 16-07-rc1


[dpdk-dev] [PATCH v6 0/4] support reset of VF link

2016-07-12 Thread Lu, Wenzhuo
> -Original Message-
> From: Luca Boccassi [mailto:lboccass at Brocade.com]
> Sent: Monday, July 11, 2016 11:43 PM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link
> 
> On Mon, 2016-07-11 at 13:02 +0100, Luca Boccassi wrote:
> > On Mon, 2016-07-11 at 01:32 +, Lu, Wenzhuo wrote:
> > > >
> > > > Unfortunately I found one issue: if PF is down, and then the VF on
> > > > the guest is down as well (ip link down) and then goes back up
> > > > before the PF, then calling rte_eth_dev_reset will return 0
> > > > (success), even though the PF is still down and it should fail. This is 
> > > > with
> ixgbe. Any idea what could be the problem?
> > > I've found this interesting thing. I believe it?s the HW difference 
> > > between igb
> and ixgbe. When the link is down, ixgbe VF can be reset successfully but igb 
> VF
> cannot. The expression is the  registers of the ixgbe VF can be accessed when
> the PF link is down but igb VF cannot.
> > > It means, on ixgbe, when PF link is down, we reset the VF link. Then PF 
> > > link is
> up, we receive the message again and reset the VF link again.
> >
> > What message do you refer to here? I am seeing the RESET callback only
> > when the PF goes down, not when it goes up.
> >
> > At the moment, with ixgbe, this happens:
> >
> > PF down -> reset notification, rte_eth_dev_reset keeps failing -> VF
> > down -> VF up -> rte_eth_dev_reset in a loop/timer succeeds -> PF up
> > -> VF link has no-carrier, and traffic does NOT go through
> >
> > The problem is that there is just no way of being notified that PF is
> > up, and if rte_eth_dev_reset succeeds I have no way of knowing that I
> > need to run it again.
> 
> I was now able to solve this use case, by having the rte_eth_dev_reset
> implementations return -EAGAIN if the dev is not up. This way I know, in the
> application, that I have to try again. What do you think?
> 
> IMHO it makes sense, as the reset does not actually succeeds, and the caller
> should try again. The diff is very trivial, and attached for reference.
Yes, I think the change is reasonable. Sorry, I didn?t realize you're talking 
about the code you have changed. Maybe we're not on the same page when 
discussing before :)

> 
> --
> Kind regards,
> Luca Boccassi
> 
> 
> Make rte_eth_dev_reset return EAGAIN if VF down
> 
> If VF is down the reset will not happen, so the driver should return
> EAGAIN to signal the application that it needs to call again
> rte_eth_dev_reset.
> 
> Signed-off-by: Luca Boccassi  ---
>  drivers/net/e1000/igb_ethdev.c|2 +-
>  drivers/net/i40e/i40e_ethdev_vf.c |2 +-
>  drivers/net/ixgbe/ixgbe_ethdev.c  |2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -6235,7 +6235,7 @@ ixgbevf_dev_reset(struct rte_eth_dev *de
> 
>   /* Nothing needs to be done if the device is not started. */
>   if (!dev->data->dev_started)
> -  return 0;
> +  return -EAGAIN;
> 
>   PMD_DRV_LOG(DEBUG, "Link up/down event detected.");
> 
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -1504,7 +1504,7 @@ i40evf_handle_vf_reset(struct rte_eth_de
>I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
> 
>   if (!dev->data->dev_started)
> -  return 0;
> +  return -EAGAIN;
> 
>   adapter->reset_number = 1;
>   i40e_vf_reset_dev(dev);
> --- a/drivers/net/e1000/igb_ethdev.c
> +++ b/drivers/net/e1000/igb_ethdev.c
> @@ -2609,7 +2609,7 @@ igbvf_dev_reset(struct rte_eth_dev *dev,
> 
>   /* Nothing needs to be done if the device is not started. */
>   if (!dev->data->dev_started)
> -  return 0;
> +  return -EAGAIN;
> 
>   PMD_DRV_LOG(DEBUG, "Link up/down event detected.");
> 


[dpdk-dev] [PATCH 0/4] fix mempool creation with Xen Dom0

2016-07-12 Thread Chen, WeichunX
Add huilong

-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: Tuesday, July 12, 2016 1:10 AM
To: Olivier Matz 
Cc: dev at dpdk.org; Xu, HuilongX ; Cao, Waterman 
; Liu, Yuanhan ; Chen, 
WeichunX ; Liu, Yu Y 
Subject: Re: [PATCH 0/4] fix mempool creation with Xen Dom0

2016-07-11 12:20, Olivier Matz:
> Since the recent mempool rework [1], Xen Dom0 is broken.
> This series aims at fixing it. I think it should be integrated in 
> 16.07.
> 
> As I don't have a full testing platform, any help in validating this 
> patchset would be appreciated.
> 
> [1] http://www.dpdk.org/ml/archives/dev/2016-May/039229.html
> 
> Olivier Matz (4):
>   eal: fix typo in Xen Dom0 specific code
>   mbuf: set errno on pool creation error
>   eal: fix retrieval of phys address with Xen Dom0
>   mempool: fix creation with Xen Dom0

Applied with an additional fix:

xen: fix build as shared library

When building as shared library, the compiler complains for
undefined reference to `rte_xen_mem_phy2mch'

The symbol rte_xen_mem_phy2mch was introduced in DPDK 2.2
and has been called in mempool recently via rte_mem_phy2mch.

Fixes: c042ba20674a ("mempool: rework support of Xen dom0")