[dpdk-dev] Ring PMD: why are stats counters atomic?

[Mauricio Vásquez]

Finally I have some time to have a look to it.

On Mon, May 16, 2016 at 3:16 PM, Bruce Richardson
 wrote:
> On Mon, May 16, 2016 at 03:12:10PM +0200, Mauricio V?squez wrote:
>> Hello Bruce,
>>
>> Although having this support does not harm anyone, I am not convinced that
>> it is useful, mainly because there exists the single-thread limitation in
>> other PMDs. Then, if an application has to use different kind of NICs (i.e,
>> different PMDs) it has to implement the locking strategies. On the other
>> hand, if an application  only uses rte_rings, it could just use the
>> rte_ring library.
>>
>> Thanks, Mauricio V
>>
> I agree.
> If you want, please submit a patch to remove this behaviour and see
> if anyone objects to it. If there are no objections, I have no problem 
> accepting
> the patch.
>
> However, since this is a behaviour change to existing functionality, we may
> need to implement function versionning for this for ABI compatibility. Please
> take that into account when drafting any patch.
>

Do you think that versioning is required in this case?
If anyone is using a functionality that is not supposed to work in
that way, should we care about it?

I am not against versioning, I just want to know if it is worthy to do.

> Regards,
> /Bruce
>
>> On Tue, May 10, 2016 at 11:36 AM, Bruce Richardson <
>> bruce.richardson at intel.com> wrote:
>>
>> > On Tue, May 10, 2016 at 11:13:08AM +0200, Mauricio V?squez wrote:
>> > > Hello,
>> > >
>> > > Per-queue stats counters are defined as rte_atomic64_t, in the tx/rx
>> > > functions, they are atomically increased if the rings have the multiple
>> > > consumers/producer flag enabled.
>> > >
>> > > According to the design principles, the application should not invoke
>> > those
>> > > functions on the same queue on different cores, then I think that atomic
>> > > increasing is not necessary.
>> > >
>> > > Is there something wrong with my reasoning?, If not, I am willing to
>> > send a
>> > > patch.
>> > >
>> > > Thank you very much,
>> > >
>> > Since the rte_rings, on which the ring pmd is obviously based, have
>> > multi-producer
>> > and multi-consumer support built-in, I thought it might be useful in the
>> > ring
>> > PMD itself to allow multiple threads to access the ring queues at the same
>> > time,
>> > if the underlying rings are marked as MP/MC safe. When doing enqueues and
>> > dequeue
>> > from the ring, the stats are either incremented atomically, or
>> > non-atomically,
>> > depending on the underlying queue type.
>> >
>> > const uint16_t nb_rx = (uint16_t)rte_ring_dequeue_burst(r->rng,
>> > ptrs, nb_bufs);
>> > if (r->rng->flags & RING_F_SC_DEQ)
>> > r->rx_pkts.cnt += nb_rx;
>> > else
>> > rte_atomic64_add(&(r->rx_pkts), nb_rx);
>> >
>> > If people don't think this behaviour is worthwhile keeping, I'm ok with
>> > removing
>> > it, since all other PMDs have the restriction that the queues are
>> > single-thread
>> > only.
>> >
>> > Regards,
>> > /Bruce
>> >

Regards,

Mauricio V

[dpdk-dev] Redirect all packets to a specific VM pool

[Mauricio Vásquez]

Hello,

To be more specific, what I am trying to do it to setup an environment
where I have a physical NIC that has some Virtual Functions configured,
then all the incoming traffic to the NIC should be forwarded to a specific
Virtual Function.

I was able to modify the "VMDQ and DCB Forwarding Sample Application" in
order to forward all the traffic that does not match the filters to a
specific rx queue, unfortunately when I try it with SR-IOV all the traffic
goes the the physical function.

My big question is:
Is it possible to forward all the traffic to a specific Virtual Function?
At least, is it supported by any NIC?

Thank you very much for your help.

PD: I CC'ed the ixgbe and i40e maintainers because those are the drivers
that I am using.

On Mon, Jul 4, 2016 at 11:03 AM, Mauricio V?squez <
mauricio.vasquezbernal at studenti.polito.it> wrote:

> Hello,
>
> I have a setup with SR-IOV where I want to forward all the packets to a
> specific VM pool. I found that in some Intel NICs it is possible to set a
> field called default pool. (Flag DEF_PL within the  PFVTCTL register). In
> order to setup this using DPDK, I used the default_pool field in the
> rte_eth_vmdq_rx_conf structure, something like this:
>
> .vmdq_rx_conf =
>  {
> .nb_queue_pools = ETH_8_POOLS,
> .enable_default_pool = 1,
> .default_pool = 5,
> .nb_pool_maps = 1,
> .pool_map = {{0, 0},},
> },
>
> However it appears not to be working, all the packets are being forwarded
> to the host pool.
>
> Am I missing something?
> Is there a better approach to reach my goal?
>
> Thank you very much for your help.
>
> Mauricio V.
>

[dpdk-dev] Redirect all packets to a specific VM pool

[Mauricio Vásquez]

Hello,

I have a setup with SR-IOV where I want to forward all the packets to a
specific VM pool. I found that in some Intel NICs it is possible to set a
field called default pool. (Flag DEF_PL within the  PFVTCTL register). In
order to setup this using DPDK, I used the default_pool field in the
rte_eth_vmdq_rx_conf structure, something like this:

.vmdq_rx_conf =
 {
.nb_queue_pools = ETH_8_POOLS,
.enable_default_pool = 1,
.default_pool = 5,
.nb_pool_maps = 1,
.pool_map = {{0, 0},},
},

However it appears not to be working, all the packets are being forwarded
to the host pool.

Am I missing something?
Is there a better approach to reach my goal?

Thank you very much for your help.

Mauricio V.

[dpdk-dev] queue to VF assigment in SR-IOV

[Mauricio Vásquez]

Hello Alexander,


On Mon, Jun 13, 2016 at 6:02 PM, Alexander Duyck 
wrote:

> On Mon, Jun 13, 2016 at 4:56 AM, Mauricio V?squez
>  wrote:
> > Hello Alexander,
> >
> > On Tue, Jun 7, 2016 at 11:31 PM, Alexander Duyck <
> alexander.duyck at gmail.com>
> > wrote:
> >>
> >> On Tue, Jun 7, 2016 at 1:49 PM, Mauricio V?squez
> >>  wrote:
> >> > Dear All,
> >> >
> >> > I implemented a program that uses flow director to forward packets to
> a
> >> > specific virtual function, however I faced the problem that I did not
> >> > know
> >> > which queue belongs to a VF. I found in [1] that in the case of Intel
> >> > 82599, queues 0-7 belongs to VF0, 8-15 to VF1 and so on, I tested it
> but
> >> > it
> >> > did not work, using the trial and error method I found that queue 0 is
> >> > in
> >> > VF0, queue 4 in VF1 and so on.
> >> >
> >> > My question is: is there a standard way to know which queues belong
> to a
> >> > specific VF?
> >> >
> >> > Thanks in advance
> >> >
> >> > Mauricio V,
> >> >
> >> > [1]
> >> >
> >> >
> http://www.intel.it/content/dam/www/public/us/en/documents/datasheets/82599-10-gbe-controller-datasheet.pdf
> ,
> >> > Table 7-72
> >>
> >> If you are using the kernel driver the way the queues are laid out
> >> depends on the number of VFs allocated and what features are enabled
> >> in the kernel.
> >
> >
> > I forgot to mention that I am using the DPDK ixgbe PMD.
> >
> >>
> >> Assuming you are not using DCB you should be able to
> >> figure out how many queues are being allocated via VF by looking at
> >> the output of "ethtool -l ".  The upper limit on RSS is t he
> >> number of queues each pool is allocated.
> >>
> >> So for example if you only enable up to 31 VFs then the PF driver
> >> allocates 4 queues per VF so you would have queues 0 - 3 allocated to
> >> VF0, queues 4-7 allocated to VF1, etc all the way through to the PF
> >> occupying (num_vfs * 4) to 127.  If you enable 32 or more VFs then the
> >> number of queues drops to 2 per VF and RSS on the PF will be limited
> >> to the 2 queues following the block reserved for the VFs.
> >>
> >
> > I found that the behavior of the DPDK PMD is almost the same you
> described:
> > 1 - 15 VFs -> 8 queues per VF
> > 16 - 31 VFs -> 4 queues per VF
> >>= 32 VFs -> 2 queues per VF
> >
> > But, according to the datasheet it should be
> > 16 VFs -> 8 queues per VF
> > 32 VFs -> 4 queues per VF
> > 64 VFs -> 2 queues per VF
> >
> > Am I missing something?
>
> The datasheet should be referring to "VM pools".  The PF consumes one
> pool for any queues it is using.  As such VFs + 1 is the total number
> of pools in use if the PF is active.
>
> > One extra thing that I am not understanding, in the case I assign the
> > maximum number of possible VFs, the PF remains without queues?
>
> The device can support at most 64 pools.  So if you are allocating 64
> VFs then there are no resources left for the PF to allocate queues
> from.
>
> I hope this helps to make it a bit clearer.
>

This made everything clear for me, thanks.


>
> - Alex
>

Mauricio V,

[dpdk-dev] queue to VF assigment in SR-IOV

[Mauricio Vásquez]

Hello Alexander,

On Tue, Jun 7, 2016 at 11:31 PM, Alexander Duyck 
wrote:

> On Tue, Jun 7, 2016 at 1:49 PM, Mauricio V?squez
>  wrote:
> > Dear All,
> >
> > I implemented a program that uses flow director to forward packets to a
> > specific virtual function, however I faced the problem that I did not
> know
> > which queue belongs to a VF. I found in [1] that in the case of Intel
> > 82599, queues 0-7 belongs to VF0, 8-15 to VF1 and so on, I tested it but
> it
> > did not work, using the trial and error method I found that queue 0 is in
> > VF0, queue 4 in VF1 and so on.
> >
> > My question is: is there a standard way to know which queues belong to a
> > specific VF?
> >
> > Thanks in advance
> >
> > Mauricio V,
> >
> > [1]
> >
> http://www.intel.it/content/dam/www/public/us/en/documents/datasheets/82599-10-gbe-controller-datasheet.pdf
> ,
> > Table 7-72
>
> If you are using the kernel driver the way the queues are laid out
> depends on the number of VFs allocated and what features are enabled
> in the kernel.


I forgot to mention that I am using the DPDK ixgbe PMD.


> Assuming you are not using DCB you should be able to
> figure out how many queues are being allocated via VF by looking at
> the output of "ethtool -l ".  The upper limit on RSS is t he
> number of queues each pool is allocated.
>
> So for example if you only enable up to 31 VFs then the PF driver
> allocates 4 queues per VF so you would have queues 0 - 3 allocated to
> VF0, queues 4-7 allocated to VF1, etc all the way through to the PF
> occupying (num_vfs * 4) to 127.  If you enable 32 or more VFs then the
> number of queues drops to 2 per VF and RSS on the PF will be limited
> to the 2 queues following the block reserved for the VFs.
>
>
I found that the behavior of the DPDK PMD is almost the same you described:
1 - 15 VFs -> 8 queues per VF
16 - 31 VFs -> 4 queues per VF
>= 32 VFs -> 2 queues per VF

But, according to the datasheet it should be
16 VFs -> 8 queues per VF
32 VFs -> 4 queues per VF
64 VFs -> 2 queues per VF

Am I missing something?

One extra thing that I am not understanding, in the case I assign the
maximum number of possible VFs, the PF remains without queues?

There are a few other configurations such as if DCB is enabled I
> believe it is possible to get 8 queues per VF if less than 16 VFs are
> allocated but in such a case you would not have access to RSS.  In
> this case if the maximum combined queue count reported is 1 you would
> need to check to see how many TCs are being supported by the PF in
> order to determine if the queue count is 4 or 8 per VF.
>
> - Alex
>

Thank you very much,

Mauricio V,

[dpdk-dev] queue to VF assigment in SR-IOV

[Mauricio Vásquez]

Dear All,

I implemented a program that uses flow director to forward packets to a
specific virtual function, however I faced the problem that I did not know
which queue belongs to a VF. I found in [1] that in the case of Intel
82599, queues 0-7 belongs to VF0, 8-15 to VF1 and so on, I tested it but it
did not work, using the trial and error method I found that queue 0 is in
VF0, queue 4 in VF1 and so on.

My question is: is there a standard way to know which queues belong to a
specific VF?

Thanks in advance

Mauricio V,

[1]
http://www.intel.it/content/dam/www/public/us/en/documents/datasheets/82599-10-gbe-controller-datasheet.pdf,
Table 7-72

[dpdk-dev] [PATCH] librte_ether: use RTE_ETH_VALID_PORTID_OR_ERR_RET to check port_id

[Mauricio Vásquez]

On Wed, May 18, 2016 at 5:01 PM, Thomas Monjalon 
wrote:

> 2016-05-18 16:41, Mauricio V?squez:
> > On Wed, May 18, 2016 at 10:15 AM, Thomas Monjalon <
> thomas.monjalon at 6wind.com
> > > wrote:
> >
> > > 2016-05-17 22:02, Mauricio V?squez:
> > > > On Fri, May 13, 2016 at 6:20 PM, Thomas Monjalon <
> > > thomas.monjalon at 6wind.com>
> > > > wrote:
> > > > > 2016-04-29 17:23, Mauricio Vasquez B:
> > > > > > The RTE_ETH_VALID_PORTID_OR_ERR_RET macro is used in some places
> > > > > > to check if a port id is valid or not. This commit makes use of
> it in
> > > > > > some new parts of the code.
> > > > >
> > > > > There are other occurences:
> > > > > rte_eth_dev_socket_id
> > > > >
> > > > I missed it.
> > > >
> > > > > rte_eth_add_rx_callback
> > > > > rte_eth_add_tx_callback
> > > > > rte_eth_remove_rx_callback
> > > > > rte_eth_remove_tx_callback
> > > > >
> > > > The macro can not be used on those ones because they set the
> rte_errno
> > > > variable before returning.
> > >
> > > It may be a good idea to set rte_errno to EINVAL in these macros.
> > >
> > > Generally speaking, rte_errno is not used a lot currently.
> >
> >
> > I noticed that both EINVAL and ENODEV are used. I think that returning
> > ENODEV and setting rte_errno to EINVAL would be strange, what do you
> think
> > about always using ENODEV?
>
> Why EINVAL is used?
>
Why not using retval to set errno?
>

If we do it, the macro could no be used in
 rte_eth_dev_socket_id
 rte_eth_dev_get_device_type
 rte_eth_add_rx_callback
 rte_eth_add_tx_callback
 rte_eth_remove_rx_callback
 rte_eth_remove_tx_callback
as they do not return an error number.

I feel ENODEV would be better but it is an API change, so we should discuss
> it later for another patch.
>

I agree

[dpdk-dev] [PATCH] librte_ether: use RTE_ETH_VALID_PORTID_OR_ERR_RET to check port_id

[Mauricio Vásquez]

On Wed, May 18, 2016 at 10:15 AM, Thomas Monjalon  wrote:

> 2016-05-17 22:02, Mauricio V?squez:
> > On Fri, May 13, 2016 at 6:20 PM, Thomas Monjalon <
> thomas.monjalon at 6wind.com>
> > wrote:
> > > 2016-04-29 17:23, Mauricio Vasquez B:
> > > > The RTE_ETH_VALID_PORTID_OR_ERR_RET macro is used in some places
> > > > to check if a port id is valid or not. This commit makes use of it in
> > > > some new parts of the code.
> > >
> > > There are other occurences:
> > > rte_eth_dev_socket_id
> > >
> > I missed it.
> >
> > > rte_eth_add_rx_callback
> > > rte_eth_add_tx_callback
> > > rte_eth_remove_rx_callback
> > > rte_eth_remove_tx_callback
> > >
> > The macro can not be used on those ones because they set the rte_errno
> > variable before returning.
>
> It may be a good idea to set rte_errno to EINVAL in these macros.
>
> Generally speaking, rte_errno is not used a lot currently.


I noticed that both EINVAL and ENODEV are used. I think that returning
ENODEV and setting rte_errno to EINVAL would be strange, what do you think
about always using ENODEV?

[dpdk-dev] [PATCH] librte_ether: use RTE_ETH_VALID_PORTID_OR_ERR_RET to check port_id

[Mauricio Vásquez]

Hello Thomas,



On Fri, May 13, 2016 at 6:20 PM, Thomas Monjalon 
wrote:

> 2016-04-29 17:23, Mauricio Vasquez B:
> > The RTE_ETH_VALID_PORTID_OR_ERR_RET macro is used in some places
> > to check if a port id is valid or not. This commit makes use of it in
> > some new parts of the code.
>
> There are other occurences:
> rte_eth_dev_socket_id
>
I missed it.

> rte_eth_add_rx_callback
> rte_eth_add_tx_callback
> rte_eth_remove_rx_callback
> rte_eth_remove_tx_callback
>
The macro can not be used on those ones because they set the rte_errno
variable before returning.

> I think it could be done also in examples/ethtool/lib.
>
I'll send v2 including that one.

Mauricio V,

[dpdk-dev] Ring PMD: why are stats counters atomic?

[Mauricio Vásquez]

Hello Bruce,

Although having this support does not harm anyone, I am not convinced that
it is useful, mainly because there exists the single-thread limitation in
other PMDs. Then, if an application has to use different kind of NICs (i.e,
different PMDs) it has to implement the locking strategies. On the other
hand, if an application  only uses rte_rings, it could just use the
rte_ring library.

Thanks, Mauricio V

On Tue, May 10, 2016 at 11:36 AM, Bruce Richardson <
bruce.richardson at intel.com> wrote:

> On Tue, May 10, 2016 at 11:13:08AM +0200, Mauricio V?squez wrote:
> > Hello,
> >
> > Per-queue stats counters are defined as rte_atomic64_t, in the tx/rx
> > functions, they are atomically increased if the rings have the multiple
> > consumers/producer flag enabled.
> >
> > According to the design principles, the application should not invoke
> those
> > functions on the same queue on different cores, then I think that atomic
> > increasing is not necessary.
> >
> > Is there something wrong with my reasoning?, If not, I am willing to
> send a
> > patch.
> >
> > Thank you very much,
> >
> Since the rte_rings, on which the ring pmd is obviously based, have
> multi-producer
> and multi-consumer support built-in, I thought it might be useful in the
> ring
> PMD itself to allow multiple threads to access the ring queues at the same
> time,
> if the underlying rings are marked as MP/MC safe. When doing enqueues and
> dequeue
> from the ring, the stats are either incremented atomically, or
> non-atomically,
> depending on the underlying queue type.
>
> const uint16_t nb_rx = (uint16_t)rte_ring_dequeue_burst(r->rng,
> ptrs, nb_bufs);
> if (r->rng->flags & RING_F_SC_DEQ)
> r->rx_pkts.cnt += nb_rx;
> else
> rte_atomic64_add(&(r->rx_pkts), nb_rx);
>
> If people don't think this behaviour is worthwhile keeping, I'm ok with
> removing
> it, since all other PMDs have the restriction that the queues are
> single-thread
> only.
>
> Regards,
> /Bruce
>

[dpdk-dev] Ring PMD: why are stats counters atomic?

[Mauricio Vásquez]

Hello,

Per-queue stats counters are defined as rte_atomic64_t, in the tx/rx
functions, they are atomically increased if the rings have the multiple
consumers/producer flag enabled.

According to the design principles, the application should not invoke those
functions on the same queue on different cores, then I think that atomic
increasing is not necessary.

Is there something wrong with my reasoning?, If not, I am willing to send a
patch.

Thank you very much,

Mauricio V,

[dpdk-dev] ivshmem is secure or not ? why ?

[Mauricio Vásquez]

Hello Yangyongqiang,

On Fri, Apr 22, 2016 at 9:55 AM, Yangyongqiang (Tony, Shannon) <
yangyongqiang at huawei.com> wrote:

> From http://dpdk.org/doc/guides/prog_guide/ivshmem_lib.html,  I get this
> : different vms can use different metadatas, so different vms can have
> different memory shared with host.
>
> For example:
> If vm1 shares MZ1 with host, and vm2 shares MZ2 with host, then vm1 can
> not look MZ2.  If this is true, then I think ivshmem is secured.
>

It is not true. In order to share a memzone, the current implementation of
ivshmem shares the whole hugepages that contain that memzone, then, in the
case MZ1 and MZ2 are in the same hugepage, both guest could access both
memory zones.


>
> But "9.3. Best Practices for Writing IVSHMEM Applications"section say :
> "While the IVSHMEM library tries to share as little memory as possible, it
> is quite probable that data designated for one VM might also be present in
> an IVSMHMEM device designated for another VM. "
>
> * I can not understand why this insecurity
> happened, can anyone explain this for me ?
>

Mauricio Vasquez,

[dpdk-dev] [PATCH] mem: fix freeing of memzone used by ivshmem

[Mauricio Vásquez]

This patch does not compile when ivshmem is disabled:

compile error:
  CC malloc_heap.o

/home/patchWorkOrg/compilation/lib/librte_eal/common/eal_common_memzone.c(353):
error #177: label "error" was declared but never referenced
error:
  ^

I'll send a v2 solving this issue


On Thu, Apr 14, 2016 at 4:48 PM, Sergio Gonzalez Monroy <
sergio.gonzalez.monroy at intel.com> wrote:

> On 14/04/2016 14:48, Mauricio Vasquez B wrote:
>
>> although previous implementation returned an error when trying to release
>> a
>> memzone assigned to an ivshmem device, it stills freed it.
>>
>> Fixes: cd10c42eb5bc ("mem: fix ivshmem freeing")
>>
>> Signed-off-by: Mauricio Vasquez B <
>> mauricio.vasquezbernal at studenti.polito.it>
>> ---
>>   lib/librte_eal/common/eal_common_memzone.c | 12 ++--
>>   1 file changed, 10 insertions(+), 2 deletions(-)
>>
>>
>>
> Thanks for the fix (not sure what I was thinking at the time).
>
> Acked-by: Sergio Gonzalez Monroy 
>
>

[dpdk-dev] [PATCH] ivshmem: fix race condition

[Mauricio Vásquez]

Hi Anatoly,

On Fri, Apr 1, 2016 at 11:01 AM, Burakov, Anatoly  wrote:

> Hi Mauricio,
>
> > The memory zone could be freed just after adding it to the metadata
> > file and just before marking it as not freeable.
> > This patch changes the locking logic in order to prevent it.
>
> Just a nit: if the stated purpose of the patch is to prevent the memzone
> free
> before adding it to metadata, then it probably should check if the memzone
> wasn't freed before we got the lock (or if it's a valid memzone in the
> first place).
> Probably just checking if the virtual address of the memzone isn't 0 would
> be
> enough. Otherwise looks fine to me.
>
>
The purpose of this patch is to avoid a memzone be freed after it has been
added to the metadata but
before it is marked as not freeable. (that small time interval where it is
possible).

Avoid adding an already freed memzone is another case, I will send a v2
that addresses it.
I used the length of the memzone to check whether the memzone is valid or
not.


> Thanks,
> Anatoly
>

Mauricio Vasquez,

[dpdk-dev] Question about cd10c42eb5bc ("mem: fix ivshmem freeing")

[Mauricio Vásquez]

Sure: http://dpdk.org/ml/archives/dev/2016-April/036884.html,

On Wed, Mar 30, 2016 at 2:10 PM, Burakov, Anatoly  wrote:

> Hi Mauricio,
>
>
>
> Good points. Would you be willing to prepare a patch to fix these issues?
>
>
>
> Thanks,
>
> Anatoly
>
>
>
> *From:* Mauricio V?squez [mailto:mauricio.vasquezbernal at studenti.polito.it]
>
> *Sent:* Wednesday, March 30, 2016 10:13 AM
> *To:* Burakov, Anatoly 
> *Cc:* dev at dpdk.org; Gonzalez Monroy, Sergio <
> sergio.gonzalez.monroy at intel.com>; Richardson, Bruce <
> bruce.richardson at intel.com>
> *Subject:* Re: Question about cd10c42eb5bc ("mem: fix ivshmem freeing")
>
>
>
> Hi Anatoly,
>
> Thank you very much, I did not take into account that detail.
>
> I have two additional concerns about it:
>
> 1. I think it is possible to have a race condition. The memzone is marked
> as not freeable after it has been added to the ivshmem device, then it is
> possible to free the memzone just after it has been  added to the metadata
> but before it is marked as not freeable.
>
> Shouldn't the memzone be marked before adding the memzone to the ivshmem
> device?
>
>
>
> 2. Are the #ifdefs necessary?, we already are in  a file that will only
> compiled when ivshmem is enabled.
>
> Thanks,
>
> Mauricio Vasquez,
>
>
>
>
>
> On Wed, Mar 30, 2016 at 10:29 AM, Burakov, Anatoly <
> anatoly.burakov at intel.com> wrote:
>
> Hi Mauricio,
>
>
>
> You?re not missing anything. It would be done this way, if the memzone
> parameter wasn?t const. But it is const, so we have to find the memzone in
> config to edit it.
>
>
>
> Thanks,
>
> Anatoly
>
>
>
> *From:* Mauricio V?squez [mailto:mauricio.vasquezbernal at studenti.polito.it]
>
> *Sent:* Wednesday, March 30, 2016 9:22 AM
> *To:* dev at dpdk.org
> *Cc:* Gonzalez Monroy, Sergio ;
> Richardson, Bruce ; Burakov, Anatoly <
> anatoly.burakov at intel.com>
> *Subject:* Question about cd10c42eb5bc ("mem: fix ivshmem freeing")
>
>
>
> Dear All,
>
> I was looking at that patch, I can understand its functionality but not
> its implementation..
>
> Why to calculate idx?, Just doing "mz->ioremap_addr = mz->phys_addr" would
> not be sufficient? After all, the goal is to mark the memzone as used by
> ivshmem to forbid  freeing it.
>
> Please corrected if I am missing something.
>
> Thank you,
>
> Mauricio Vasquez,
>
>
>

[dpdk-dev] Question about cd10c42eb5bc ("mem: fix ivshmem freeing")

[Mauricio Vásquez]

Hi Anatoly,

Thank you very much, I did not take into account that detail.

I have two additional concerns about it:

1. I think it is possible to have a race condition. The memzone is marked
as not freeable after it has been added to the ivshmem device, then it is
possible to free the memzone just after it has been  added to the metadata
but before it is marked as not freeable.
Shouldn't the memzone be marked before adding the memzone to the ivshmem
device?

2. Are the #ifdefs necessary?, we already are in  a file that will only
compiled when ivshmem is enabled.

Thanks,

Mauricio Vasquez,


On Wed, Mar 30, 2016 at 10:29 AM, Burakov, Anatoly <
anatoly.burakov at intel.com> wrote:

> Hi Mauricio,
>
>
>
> You?re not missing anything. It would be done this way, if the memzone
> parameter wasn?t const. But it is const, so we have to find the memzone in
> config to edit it.
>
>
>
> Thanks,
>
> Anatoly
>
>
>
> *From:* Mauricio V?squez [mailto:mauricio.vasquezbernal at studenti.polito.it]
>
> *Sent:* Wednesday, March 30, 2016 9:22 AM
> *To:* dev at dpdk.org
> *Cc:* Gonzalez Monroy, Sergio ;
> Richardson, Bruce ; Burakov, Anatoly <
> anatoly.burakov at intel.com>
> *Subject:* Question about cd10c42eb5bc ("mem: fix ivshmem freeing")
>
>
>
> Dear All,
>
> I was looking at that patch, I can understand its functionality but not
> its implementation..
>
> Why to calculate idx?, Just doing "mz->ioremap_addr = mz->phys_addr" would
> not be sufficient? After all, the goal is to mark the memzone as used by
> ivshmem to forbid  freeing it.
>
> Please corrected if I am missing something.
>
> Thank you,
>
> Mauricio Vasquez,
>

[dpdk-dev] Question about cd10c42eb5bc ("mem: fix ivshmem freeing")

[Mauricio Vásquez]

Dear All,

I was looking at that patch, I can understand its functionality but not its
implementation..

Why to calculate idx?, Just doing "mz->ioremap_addr = mz->phys_addr" would
not be sufficient? After all, the goal is to mark the memzone as used by
ivshmem to forbid  freeing it.

Please corrected if I am missing something.

Thank you,

Mauricio Vasquez,

[dpdk-dev] [PATCH] mempool: allow for user-owned mempool caches

[Mauricio Vásquez]

Hello to everybody,

I find this proposal very interesting as It could be used to solve an issue
that has not been mentioned yet: using memory pools shared with ivshmem.
Currently, due to the per lcore cache, it is not possible to allocate and
deallocate packets from the guest as it will cause cache corruption because
DPDK processes in the guest and in the host share some lcores_id.

If there is an API to register caches, the EAL could create and register
its own caches during the ivshmem initialization in the guest, avoiding
possible cache corruption problems.

I look forward to V2 in order to get a clear idea of how can it be used to
solve this issue.

Mauricio V,

On Fri, Mar 25, 2016 at 11:55 AM, Olivier Matz 
wrote:

> Hi Venky,
>
> >> The main benefit of having an external cache is to allow mempool users
> >> (threads) to maintain a local cache even though they don't have a valid
> >> lcore_id (non-EAL threads). The fact that cache access is done by
> indexing
> >> with the lcore_id is what makes it difficult...
> >
> > Hi Lazaros,
> >
> > Alternative suggestion: This could actually be very simply done via
> creating an EAL API to register and return an lcore_id for a thread wanting
> to use DPDK services. That way, you could simply create your pthread, call
> the eal_register_thread() function that assigns an lcore_id to the caller
> (and internally sets up the per_lcore variable.
> >
> > The advantage of doing it this way is that you could extend it to other
> things other than the mempool that may need an lcore_id setup.
>
> From my opinion, externalize the cache structure as Lazaros suggests
> would make things simpler, especially in case of dynamic threads
> allocation/destruction.
>
> If a lcore_id regristration API is added in EAL, we still need a
> max lcore value when the mempool is created so the cache can be
> allocated. Moreover, the API would not be as simple, especially
> if it needs to support secondary processes.
>
>
> Regards,
> Olivier
>

[dpdk-dev] [PATCH v2] ring: check for zero objects mc dequeue / mp enqueue

[Mauricio Vásquez]

Hi,


On Fri, Mar 18, 2016 at 11:35 AM, Thomas Monjalon  wrote:

> 2016-03-18 11:27, Olivier Matz:
> > On 03/18/2016 11:18 AM, Bruce Richardson wrote:
> > >>> +   /* Avoid the unnecessary cmpset operation below, which is
> also
> > >>> +* potentially harmful when n equals 0. */
> > >>> +   if (n == 0)
> > >>>
> > >>
> > >> What about using unlikely here?
> > >>
> > >
> > > Unless there is a measurable performance increase by adding in
> likely/unlikely
> > > I'd suggest avoiding it's use. In general, likely/unlikely should only
> be used
> > > for things like catestrophic errors because the penalty for taking the
> unlikely
> > > leg of the code can be quite severe. For normal stuff, where the code
> nearly
> > > always goes one way in the branch but occasionally goes the other, the
> hardware
> > > branch predictors generally do a good enough job.
> >
> > Do you mean using likely/unlikely could be worst than not using it
> > in this case?
> >
> > To me, using unlikely here is not a bad idea: it shows to the compiler
> > and to the reader of the code that is case is not the usual case.
>
> It would be nice to have a guideline section about likely/unlikely in
> doc/guides/contributing/design.rst
>
> Bruce gave a talk at Dublin about this kind of things.
> I'm sure he could contribute more design guidelines ;)
>

There is a small explanation in the section "Branch Prediction" of
doc/guides/contributing/coding_style.rst, but I do not know if that is
enough to understand when to use them.

I've made a fast check and there are many PMDs that use them to check if
number of packets is zero in the transmission function.

[dpdk-dev] [PATCH v2] ring: check for zero objects mc dequeue / mp enqueue

[Mauricio Vásquez]

Hi Lazaros,

On Thu, Mar 17, 2016 at 4:49 PM, Lazaros Koromilas 
wrote:

> Issuing a zero objects dequeue with a single consumer has no effect.
> Doing so with multiple consumers, can get more than one thread to succeed
> the compare-and-set operation and observe starvation or even deadlock in
> the while loop that checks for preceding dequeues.  The problematic piece
> of code when n = 0:
>
> cons_next = cons_head + n;
> success = rte_atomic32_cmpset(>cons.head, cons_head, cons_next);
>
> The same is possible on the enqueue path.
>
> Signed-off-by: Lazaros Koromilas 
> ---
>  lib/librte_ring/rte_ring.h | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> index 943c97c..eb45e41 100644
> --- a/lib/librte_ring/rte_ring.h
> +++ b/lib/librte_ring/rte_ring.h
> @@ -431,6 +431,11 @@ __rte_ring_mp_do_enqueue(struct rte_ring *r, void *
> const *obj_table,
> uint32_t mask = r->prod.mask;
> int ret;
>
> +   /* Avoid the unnecessary cmpset operation below, which is also
> +* potentially harmful when n equals 0. */
> +   if (n == 0)
>

What about using unlikely here?


> +   return 0;
> +
> /* move prod.head atomically */
> do {
> /* Reset n to the initial burst count */
> @@ -618,6 +623,11 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, void
> **obj_table,
> unsigned i, rep = 0;
> uint32_t mask = r->prod.mask;
>
> +   /* Avoid the unnecessary cmpset operation below, which is also
> +* potentially harmful when n equals 0. */
> +   if (n == 0)
>

Also here.


> +   return 0;
> +
> /* move cons.head atomically */
> do {
> /* Restore n as it may change every loop */
> --
> 1.9.1
>
>

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

[Mauricio Vásquez]

Hello,

I am trying to connect two virtual machines through Open vSwitch using
vhost-user ports, on the host side everything looks fine.
When using the standard virtio drivers both virtual machines are able to
exchange traffic, but when I load the virtio PMD and run a DPDK application
it shows the following error message:

...
EAL: PCI device :00:04.0 on NUMA socket -1
EAL:   probe driver: 1af4:1000 rte_virtio_pmd
EAL:   PCI memory mapped at 0x7f892dc0
PMD: virtio_read_caps(): [40] skipping non VNDR cap id: 11
PMD: virtio_read_caps(): no modern virtio pci device found.
PMD: vtpci_init(): trying with legacy virtio pci.
EAL: eal_parse_sysfs_value(): cannot open sysfs value
/sys/bus/pci/devices/:00:04.0/uio/uio0/portio/port0/start
EAL: pci_uio_ioport_map(): cannot parse portio start
EAL: Error - exiting with code: 1
  Cause: Requested device :00:04.0 cannot be used
...

I tried it using the master version of DPDK, when I use the 2.2 version it
works without problems:

...
PMD: parse_sysfs_value(): parse_sysfs_value(): cannot open sysfs value
/sys/bus/pci/devices/:00:04.0/uio/uio0/portio/port0/size
PMD: virtio_resource_init_by_uio(): virtio_resource_init_by_uio(): cannot
parse size
PMD: virtio_resource_init_by_ioports(): PCI Port IO found start=0xc100 with
size=0x20
PMD: virtio_negotiate_features(): guest_features before negotiate = cf8020
PMD: virtio_negotiate_features(): host_features before negotiate = 40268020
PMD: virtio_negotiate_features(): features after negotiate = 68020
PMD: eth_virtio_dev_init(): PORT MAC: 00:00:00:00:00:11
PMD: eth_virtio_dev_init(): VIRTIO_NET_F_STATUS is not supported
PMD: eth_virtio_dev_init(): VIRTIO_NET_F_MQ is not supported
PMD: virtio_dev_cq_queue_setup():  >>
PMD: virtio_dev_queue_setup(): selecting queue: 2
PMD: virtio_dev_queue_setup(): vq_size: 64 nb_desc:0
PMD: virtio_dev_queue_setup(): vring_size: 4612, rounded_vring_size: 8192
PMD: virtio_dev_queue_setup(): vq->vq_ring_mem:  0x76d43000
PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fa669743000
PMD: eth_virtio_dev_init(): config->max_virtqueue_pairs=1
PMD: eth_virtio_dev_init(): config->status=0
PMD: eth_virtio_dev_init(): PORT MAC: 00:00:00:00:00:11
PMD: eth_virtio_dev_init(): hw->max_rx_queues=1   hw->max_tx_queues=1
PMD: eth_virtio_dev_init(): port 0 vendorID=0x1af4 deviceID=0x1000
PMD: virtio_dev_vring_start():  >>
...

According to git bisect it appears to be that it does not work anymore
after the b8f04520ad71 ("virtio: use PCI ioport API") commit.

I also tried to run the "Vhost Sample Application" in the host with the
test-pmd in the guest, the problem is the same.

I am using:
QEMU v2.2.1
guest kernel: Linux ubuntu 3.19.0-25-generic
Both guest and host use 2MB huge pages

The qemu command line is
DEVICE_CMD="-chardev
socket,id=char2,path=/usr/local/var/run/openvswitch/vhost-user-2 \
-netdev type=vhost-user,id=mynet2,chardev=char2,vhostforce \
-device virtio-net-pci,mac=00:00:00:00:00:11,netdev=mynet2"

MEMORY_CMD="-object
memory-backend-file,id=mem,size=1024M,mem-path=/dev/hugepages,share=on
-numa node,memdev=mem -mem-prealloc"

qemu-system-x86_64 ... -cpu host -smp 3 -machine accel=kvm,usb=off
$MEMORY_CMD -m 1024 $DEVICE_CMD -monitor stdio

Could you check if this happens also to you?

Thank you very much.

[dpdk-dev] [PATCH] doc: fix vhost bad section number references

[Mauricio Vásquez]

Hi John,

I'll check for other hard-coded references like this, so, I think it is
better to drop this patch.
I'll include the doc name in the reference and send it in a patch series.


On 22 February 2016 at 10:56, Mcnamara, John 
wrote:

> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mauricio Vasquez B
> > Sent: Saturday, February 20, 2016 11:13 AM
> > To: Xie, Huawei ; yuanhan.liu at linux.intel.com
> > Cc: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH] doc: fix vhost bad section number references
> >
> > Section numbers were "hard-coded". This patch adds them as hyperlinks.
> >
> > Signed-off-by: Mauricio Vasquez B
> > 
>
> Acked-by: John McNamara 
>
> Thanks.
>
> It is probably best to include some reference to the file or doc section in
> the target name since they are shared across all of the Html documentation.
> For example _vhost_running_the_vm instead of _running_the_vm.
>
> Btw, I was surprised this issue hadn't be fixed in an earlier doc patchset.
> Checking the docs there are around 20 other hardcoded references like this.
> If you have some time it would be could if you could fix those in the same
> way.
>
> John
>
>

[dpdk-dev] rings PMD detaching

[Mauricio Vásquez]

Hello Everybody,

I was wondering if there were a way to detach (delete) a ring pmd device
created with rte_eth_from_rings.  I realized that rte_eth_dev_detach does
not work in this case because there is a comparison between the device's
name and the driver's name in rte_eal_vdev_uninit, then devices created
with arbitrary names can not be uninitialized.

My question is how to implement it?, I have two ideas on mind:
- make rte_pmd_ring_devuninit a public function, then the user can call
this using as argument the name of the device.
- modify rte_eal_vdev_uninit in such a way that there is not any comparison
based on the dev name, probably it will require to add some extra field in
the rte_eth_dev structure to distinguish between the different virtual
devices.

Any idea or comment about it?

Thank you very much

[dpdk-dev] [PATCH] ring: Fix memory leakage in rte_pmd_ring_devuninit()

[Mauricio Vásquez]

On 20 November 2015 at 13:42, Richardson, Bruce 
wrote:

>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mcnamara, John
> > Sent: Friday, November 20, 2015 12:32 PM
> > To: Mauricio Vasquez B ;
> > dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] ring: Fix memory leakage in
> > rte_pmd_ring_devuninit()
> >
> >
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mauricio Vasquez
> > > B
> > > Sent: Wednesday, November 18, 2015 10:29 PM
> > > To: dev at dpdk.org
> > > Subject: [dpdk-dev] [PATCH] ring: Fix memory leakage in
> > > rte_pmd_ring_devuninit()
> > >
> > > When freeing the device, it is also necessary to free rx_queues and
> > > tx_queues
> > >
> > > Signed-off-by: Mauricio Vasquez B
> > > 
> > > ---
> > >  drivers/net/ring/rte_eth_ring.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/net/ring/rte_eth_ring.c
> > > b/drivers/net/ring/rte_eth_ring.c index 9a31bce..e091e4f 100644
> > > --- a/drivers/net/ring/rte_eth_ring.c
> > > +++ b/drivers/net/ring/rte_eth_ring.c
> > > @@ -582,6 +582,9 @@ rte_pmd_ring_devuninit(const char *name)
> > > return -ENODEV;
> > >
> > > eth_dev_stop(eth_dev);
> > > +
> > > +   rte_free(eth_dev->data->rx_queues);
> > > +   rte_free(eth_dev->data->tx_queues);
> > > rte_free(eth_dev->data->dev_private);
> > > rte_free(eth_dev->data);
> >
> > Hi,
> >
> > This should test for eth_dev->data before freeing the members. Like:
> >
> > if (eth_dev->data) {
> > rte_free(eth_dev->data->rx_queues);
> > rte_free(eth_dev->data->tx_queues);
> > rte_free(eth_dev->data->dev_private);
> > }
> >
> > Thanks,
> >
> > John
>
> That was my thought initially too, but since this is an uninit routine,
> the data field must already have been set up correctly by the init/creation
> function.
>
That was my reasoning too.

> That being said, the check does no harm, so we might as well add it.
>
I agree, I will send a new patch version.

>
> /Bruce
>

Mauricio V,

[dpdk-dev] Why rte_eal_ivshmem_obj_initd() does not add memory pools to rte_mempool_tailq list?

[Mauricio Vásquez]

Hi Anatoly,

Thank you very much for your answer, it clarifies it for me. I absolutely
agree with you that adding mempools support should not be implemented until
a solution for mempool cache corruption is found.

Mauricio,

On 16 October 2015 at 15:00, Burakov, Anatoly 
wrote:

> Hi Mauricio
>
> > Dear DPDK community,
> >
> > Some time ago I was trying to map a memory pool into a guest using
> > IVSHMEM as described here:
> >
> > http://comments.gmane.org/gmane.comp.networking.dpdk.devel/17779
> >
> > After some time I decided to review the code of eal_ivshmem.c, I noticed
> > that in the function rte_eal_ivshmem_obj_init the rings are added to the
> > rte_ring_tailq list, but for memory pools there is not a similar
> procedure.
> > My question is why it does not exist such procedure? Is there any reason
> or
> > is it just missing?
> >
> > If it is just missing I could propose a implementation for it,
> >
> > Thank you very much for your attention,
> >
> > Mauricio V?squez
>
> Sharing mempools over IVSHMEM is not supported because all sorts of
> strange things start to happen when you consider that mempool caches (which
> are not thread safe) are part of the picture. The only way to even work
> with mempools over IVSHMEM without things horribly breaking would be to
> either always watch your coremasks (which is prone to user error) or
> disable mempool caches (which slows things down). This is the reason
> sharing mempools over IVSHMEM was never supported.
>
> Technically, there is nothing stopping you to implement it yourself - all
> you have to do is to add a wrapper that looks for their memzones (like we
> have for rings), and add an auto-discovery mechanism to the EAL IVSHMEM
> code (again, like we have for rings). However, unless things I mentioned
> aren't a problem anymore for whatever reason, I would be very reluctant to
> ack a patch adding mempools support to IVSHMEM code.
>
> Thanks,
> Anatoly
>

[dpdk-dev] IVSHMEM hotplug support in DPDK

[Mauricio Vásquez]

Hi All,

I am trying to understand if there is support for hotplugging of IVSHMEM
devices in dpdk. I set up a simple experiment where I hotplugged an ivshmem
device into a VM using the device_add command plus the command line
generated by rte_ivshmem_metadata_cmdline_generate in  QEMU monitor. It
appears to work, in fact, when I run lspci in the guest I can see the
device, but when I execute a simple dpdk application that looks for a ring
that was previously mapped into the device, it's not able to find it. In
fact when the application starts, the EAL appears not to find the device.

So my question is the following: is there support for IVSHMEM hotplug in
the current dpdk implementation?

I used the last dpdk version available in git, a host with a kernel
3.13.0-43 and a guest with 3.12.0-rc1.

Thank you very much.

Mauricio V,

[dpdk-dev] dpdk 2.0.0: Issue mapping mempool into guest using IVSHMEM

[Mauricio Vásquez]

Thank you for your answer Bruce,

I think you refer to the example "l2fwd-ivshmem", Don't you?
I compiled and run it, it works.

I was reviewing the code and I found that the function rte_mempool_lookup
is not used in the guest.
In the host a structure containing pointers to the rings is allocated using
rte_memzone_reserve and then mapped to the guest with
rte_ivshmem_metadata_add_memzone.
In the guest rte_memzone_lookup is used to lookup for this structure.

It's clear to me that I could use this approach to do what I want to do,
but I don't understand why rte_mempool_lookup does not work in my case.

Thanks in advance.

On Tue, May 19, 2015 at 2:27 PM, Bruce Richardson <
bruce.richardson at intel.com> wrote:

> On Mon, May 18, 2015 at 10:32:37AM +0200, Mauricio V?squez wrote:
> > Hi all,
> >
> > I'm trying to map a mempool into a guest using the IVSHMEM library but
> the
> > mempool is not visible from the guest.
> >
> > The code I'm running is quite simple, on the host I run a primary DPDK
> > process that creates the mempool, creates a metadata file and then adds
> the
> > mempool to it.
>
> Can you perhaps try using the ivshmem example application with DPDK to
> start with
> and see if you can reproduce your issue with that?
>
> Regards,
> /Bruce
>
> >
> > The code is:
> > ...
> > int main(int argc, char * argv[])
> > {
> > int retval = 0;
> >
> > /* Init EAL, parsing EAL args */
> > retval = rte_eal_init(argc, argv);
> > if (retval < 0)
> > return -1;
> >
> > char cmdline[PATH_MAX] = {0};
> >
> > struct rte_mempool *packets_pool;
> > //Create mempool
> > packets_pool = rte_mempool_create(
> > "packets",
> > NUM_PKTS,
> > MBUF_SIZE,
> > CACHE_SIZE,//This is the size of the mempool
> > cache
> > sizeof(struct rte_pktmbuf_pool_private),
> > rte_pktmbuf_pool_init,
> > NULL,
> > rte_pktmbuf_init,
> > NULL,
> > rte_socket_id(),
> > 0 /*NO_FLAGS*/);
> >
> > if (packets_pool == NULL)
> > rte_exit(EXIT_FAILURE,"Cannot init the packets pool\n");
> >
> > //Create metadata file
> > if (rte_ivshmem_metadata_create(metadata_name) < 0)
> > rte_exit(EXIT_FAILURE, "Cannot create metadata file\n");
> >
> > //Add mempool to metadata file
> > if(rte_ivshmem_metadata_add_mempool(packets_pool, metadata_name) < 0)
> > rte_exit(EXIT_FAILURE, "Cannot add mempool metadata file\n");
> >
> > //Get qemu command line
> > if (rte_ivshmem_metadata_cmdline_generate(cmdline, sizeof(cmdline),
> > metadata_name) < 0)
> > rte_exit(EXIT_FAILURE, "Failed generating command line for
> qemu\n");
> >
> > RTE_LOG(INFO, APP, "Command line for qemu: %s\n", cmdline);
> > save_ivshmem_cmdline_to_file(cmdline);
> >
> > //Avoids the application closes
> > char x = getchar();
> > (void) x;
> > return 0;
> > }
> >
> > When I run it I can see clearly that the memzone is added:
> >
> > EAL: Adding memzone 'MP_packets' at 0x7ffec0e8c1c0 to metadata vm_1
> > EAL: Adding memzone 'RG_MP_packets' at 0x7ffec0d8c140 to metadata vm_1
> > APP: Command line for qemu: -device
> >
> ivshmem,size=2048M,shm=fd:/dev/hugepages/rtemap_0:0x0:0x4000:/dev/zero:0x0:0x3fffc000:/var/run/.dpdk_ivshmem_metadata_vm_1:0x0:0x4000
> >
> > I run the modified version of QEMU provided by dpdk-ovs using the command
> > line generated by the host application, then in the guest I run an even
> > simpler application:
> >
> > ...
> > void mempool_walk_f(const struct rte_mempool *r, void * arg)
> > {
> > RTE_LOG(INFO, APP, "Mempool: %s\n", r->name);
> > (void) arg;
> > }
> >
> > int main(int argc, char *argv[])
> > {
> > int retval = 0;
> >
> > if ((retval = rte_eal_init(argc, argv)) < 0)
> > return -1;
> >
> > argc -= retval;
> > argv += retval;
> >
> > struct rte_mempool * packets;
> >
> > packets = rte_mempool_lookup("packets");
> >
> > if(packets == NULL)
> > {
> > RTE_LOG(ERR, APP, "Failed to find mempool\n");
> > }
> >
> > RTE_LOG(INFO, APP, "List of mempool: \n");
> > rte_mempool_walk(mempool_walk_f, NULL);
> >
> > return 0;
> > }
> > ...
> >
> > I can see in the application output that the mem zones that were added
> are
> > found:
> >
> > EAL: Found memzone: 'RG_MP_packets' at 0x7ffec0d8c140 (len 0x100080)
> > EAL: Found memzone: 'MP_packets' at 0x7ffec0e8c1c0 (len 0x3832100)
> >
> > But, the rte_mempool_lookup function returns NULL.
> > Using the rte_mempool_walker the program only prints a memzone called
> > log_history.
> >
> > Do you have any suggestion?
> >
> > Thank you very much for your help.
>

[dpdk-dev] dpdk 2.0.0: Issue mapping mempool into guest using IVSHMEM

[Mauricio Vásquez]

Hi all,

I'm trying to map a mempool into a guest using the IVSHMEM library but the
mempool is not visible from the guest.

The code I'm running is quite simple, on the host I run a primary DPDK
process that creates the mempool, creates a metadata file and then adds the
mempool to it.

The code is:
...
int main(int argc, char * argv[])
{
int retval = 0;

/* Init EAL, parsing EAL args */
retval = rte_eal_init(argc, argv);
if (retval < 0)
return -1;

char cmdline[PATH_MAX] = {0};

struct rte_mempool *packets_pool;
//Create mempool
packets_pool = rte_mempool_create(
"packets",
NUM_PKTS,
MBUF_SIZE,
CACHE_SIZE,//This is the size of the mempool
cache
sizeof(struct rte_pktmbuf_pool_private),
rte_pktmbuf_pool_init,
NULL,
rte_pktmbuf_init,
NULL,
rte_socket_id(),
0 /*NO_FLAGS*/);

if (packets_pool == NULL)
rte_exit(EXIT_FAILURE,"Cannot init the packets pool\n");

//Create metadata file
if (rte_ivshmem_metadata_create(metadata_name) < 0)
rte_exit(EXIT_FAILURE, "Cannot create metadata file\n");

//Add mempool to metadata file
if(rte_ivshmem_metadata_add_mempool(packets_pool, metadata_name) < 0)
rte_exit(EXIT_FAILURE, "Cannot add mempool metadata file\n");

//Get qemu command line
if (rte_ivshmem_metadata_cmdline_generate(cmdline, sizeof(cmdline),
metadata_name) < 0)
rte_exit(EXIT_FAILURE, "Failed generating command line for qemu\n");

RTE_LOG(INFO, APP, "Command line for qemu: %s\n", cmdline);
save_ivshmem_cmdline_to_file(cmdline);

//Avoids the application closes
char x = getchar();
(void) x;
return 0;
}

When I run it I can see clearly that the memzone is added:

EAL: Adding memzone 'MP_packets' at 0x7ffec0e8c1c0 to metadata vm_1
EAL: Adding memzone 'RG_MP_packets' at 0x7ffec0d8c140 to metadata vm_1
APP: Command line for qemu: -device
ivshmem,size=2048M,shm=fd:/dev/hugepages/rtemap_0:0x0:0x4000:/dev/zero:0x0:0x3fffc000:/var/run/.dpdk_ivshmem_metadata_vm_1:0x0:0x4000

I run the modified version of QEMU provided by dpdk-ovs using the command
line generated by the host application, then in the guest I run an even
simpler application:

...
void mempool_walk_f(const struct rte_mempool *r, void * arg)
{
RTE_LOG(INFO, APP, "Mempool: %s\n", r->name);
(void) arg;
}

int main(int argc, char *argv[])
{
int retval = 0;

if ((retval = rte_eal_init(argc, argv)) < 0)
return -1;

argc -= retval;
argv += retval;

struct rte_mempool * packets;

packets = rte_mempool_lookup("packets");

if(packets == NULL)
{
RTE_LOG(ERR, APP, "Failed to find mempool\n");
}

RTE_LOG(INFO, APP, "List of mempool: \n");
rte_mempool_walk(mempool_walk_f, NULL);

return 0;
}
...

I can see in the application output that the mem zones that were added are
found:

EAL: Found memzone: 'RG_MP_packets' at 0x7ffec0d8c140 (len 0x100080)
EAL: Found memzone: 'MP_packets' at 0x7ffec0e8c1c0 (len 0x3832100)

But, the rte_mempool_lookup function returns NULL.
Using the rte_mempool_walker the program only prints a memzone called
log_history.

Do you have any suggestion?

Thank you very much for your help.