Re: [dpdk-dev] [PATCH v4 02/17] net/ionic: add hardware structures definitions

[Alfredo Cardigliano]

> On 20 Dec 2019, at 01:16, Stephen Hemminger  
> wrote:
> 
> On Thu, 19 Dec 2019 23:18:32 +0100
> Alfredo Cardigliano  wrote:
> 
>> +
>> +#pragma pack(push, 1)
>> +
> 
> Really, packing leads to unaligned data structures and is generally
> a bad idea.


This specific file defines data structures shared with the adapter (and other 
OS drivers)
thus any additional padding should be avoided. Actually the pragma is 
unnecessary 
here, as who wrote this file worked pretty hard tweaking the structs by hand to 
be sure
that they are all formed such that the fields are on their appropriate byte 
boundaries 
and all field padding is explicitly defined.

Alfredo

Re: [dpdk-dev] [PATCH v6 3/4] net/ixgbe: cleanup Tx buffers

[Di, ChenxuX]

Hi,


> -Original Message-
> From: Ananyev, Konstantin
> Sent: Monday, December 30, 2019 8:54 PM
> To: Di, ChenxuX ; dev@dpdk.org
> Cc: Yang, Qiming ; Di, ChenxuX
> 
> Subject: RE: [dpdk-dev] [PATCH v6 3/4] net/ixgbe: cleanup Tx buffers
> 
> Hi,
> 
> > Add support to the ixgbe driver for the API rte_eth_tx_done_cleanup to
> > force free consumed buffers on Tx ring.
> >
> > Signed-off-by: Chenxu Di 
> > ---
> >  drivers/net/ixgbe/ixgbe_ethdev.c |   2 +
> >  drivers/net/ixgbe/ixgbe_rxtx.c   | 116 +++
> >  drivers/net/ixgbe/ixgbe_rxtx.h   |   2 +
> >  3 files changed, 120 insertions(+)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > index 2c6fd0f13..0091405db 100644
> > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > @@ -601,6 +601,7 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops
> > = {  .udp_tunnel_port_add  = ixgbe_dev_udp_tunnel_port_add,
> > .udp_tunnel_port_del  = ixgbe_dev_udp_tunnel_port_del,
> >  .tm_ops_get   = ixgbe_tm_ops_get,
> > +.tx_done_cleanup  = ixgbe_tx_done_cleanup,
> 
> Don't see how we can have one tx_done_cleanup() for different tx functions?
> Vector and scalar TX path use different  format for sw_ring[] entries.
> Also offload and simile TX paths use different method to track used/free
> descriptors, and use different functions to free them:
> offload uses tx_entry next_id, last_id plus txq. last_desc_cleaned, while 
> simple
> TX paths use tx_next_dd.
> 

This patches will be not include function for Vector, and I will update my code 
to
Make it work for offload and simple .
> 
> >  };
> >
> >  /*
> > @@ -649,6 +650,7 @@ static const struct eth_dev_ops ixgbevf_eth_dev_ops
> = {
> >  .reta_query   = ixgbe_dev_rss_reta_query,
> >  .rss_hash_update  = ixgbe_dev_rss_hash_update,
> >  .rss_hash_conf_get= ixgbe_dev_rss_hash_conf_get,
> > +.tx_done_cleanup  = ixgbe_tx_done_cleanup,
> >  };
> >
> >  /* store statistics names and its offset in stats structure */ diff
> > --git a/drivers/net/ixgbe/ixgbe_rxtx.c
> > b/drivers/net/ixgbe/ixgbe_rxtx.c index fa572d184..520b9c756 100644
> > --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> > +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> > @@ -2306,6 +2306,122 @@ ixgbe_tx_queue_release_mbufs(struct
> > ixgbe_tx_queue *txq)  }  }
> >
> > +int ixgbe_tx_done_cleanup(void *q, uint32_t free_cnt)
> 
> That seems to work only for offload(full) TX path (ixgbe_xmit_pkts).
> Simple(fast) path seems not covered by this function.
> 

Same as above

> > +{
> > +struct ixgbe_tx_queue *txq = (struct ixgbe_tx_queue *)q; struct
> > +ixgbe_tx_entry *sw_ring; volatile union ixgbe_adv_tx_desc *txr;
> > +uint16_t tx_first; /* First segment analyzed. */
> > +uint16_t tx_id;/* Current segment being processed. */
> > +uint16_t tx_last;  /* Last segment in the current packet. */ uint16_t
> > +tx_next;  /* First segment of the next packet. */ int count;
> > +
> > +if (txq == NULL)
> > +return -ENODEV;
> > +
> > +count = 0;
> > +sw_ring = txq->sw_ring;
> > +txr = txq->tx_ring;
> > +
> > +/*
> > + * tx_tail is the last sent packet on the sw_ring. Goto the end
> > + * of that packet (the last segment in the packet chain) and
> > + * then the next segment will be the start of the oldest segment
> > + * in the sw_ring.
> 
> Not sure I understand the sentence above.
> tx_tail is the value of TDT HW register (most recently armed by SW TD).
> last_id  is the index of last descriptor for multi-seg packet.
> next_id is just the index of next descriptor in HW TD ring.
> How do you conclude that it will be the ' oldest segment in the sw_ring'?
> 

The tx_tail is the last sent packet on the sw_ring. While the xmit_cleanup or 
Tx_free_bufs will be call when the nb_tx_free < tx_free_thresh .
So the sw_ring[tx_tail].next_id must be the begin of mbufs which are not used or
 Already freed . then begin the loop until the mbuf is used and begin to free 
them.



> Another question why do you need to write your own functions?
> Why can't you reuse existing ixgbe_xmit_cleanup() for full(offload) path and
> ixgbe_tx_free_bufs() for simple path?
> Yes,  ixgbe_xmit_cleanup() doesn't free mbufs, but at least it could be used 
> to
> determine finished TX descriptors.
> Based on that you can you can free appropriate sw_ring[] entries.
> 

The reason why I don't reuse existing function is that they all free several 
mbufs 
While the free_cnt of the API rte_eth_tx_done_cleanup() is the number of 
packets.
It also need to be done that check which mbuffs are from the same packet.


> >This is the first packet that will be
> > + * attempted to be freed.
> > + */
> > +
> > +/* Get last segment in most recently added packet. */ tx_last =
> > +sw_ring[txq->tx_tail].last_id;
> > +
> > +/* Get the next segment, which is the oldest segment in ring. */
> > +tx_first = sw_ring[tx_last].next_id;
> > +
> > +/* Set the current index to the first. */ tx_id = tx_first;
> > +
>

Re: [dpdk-dev] [PATCH v2 04/11] examples/l3fwd: add ethdev setup based on eventdev

[Nipun Gupta]

> -Original Message-
> From: Jerin Jacob 
> Sent: Thursday, January 2, 2020 3:04 PM
> To: Nipun Gupta 
> Cc: Pavan Nikhilesh Bhagavatula ; Jerin Jacob
> Kollanukkaran ; Marko Kovacevic
> ; Ori Kam ; Bruce
> Richardson ; Radu Nicolau
> ; Akhil Goyal ; Tomasz
> Kantecki ; Sunil Kumar Kori ;
> Hemant Agrawal ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 04/11] examples/l3fwd: add ethdev setup
> based on eventdev
> 
> On Thu, Jan 2, 2020 at 2:20 PM Nipun Gupta  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Pavan Nikhilesh Bhagavatula 
> > > Sent: Thursday, January 2, 2020 11:52 AM
> > > To: Nipun Gupta ; Jerin Jacob Kollanukkaran
> > > ; Marko Kovacevic ; Ori
> > > Kam ; Bruce Richardson
> > > ; Radu Nicolau ;
> > > Akhil Goyal ; Tomasz Kantecki
> > > ; Sunil Kumar Kori ;
> > > Hemant Agrawal 
> > > Cc: dev@dpdk.org
> > > Subject: RE: [dpdk-dev] [PATCH v2 04/11] examples/l3fwd: add ethdev setup
> > > based on eventdev
> > >
> > > >> >&local_port_conf);
> > > >> >> +   if (ret < 0)
> > > >> >> +   rte_exit(EXIT_FAILURE,
> > > >> >> +"Cannot configure device: err=%d,
> > > >> >> port=%d\n",
> > > >> >> +ret, port_id);
> > > >> >> +
> > > >> >
> > > >> >We should be using number of RX queues as per the config option
> > > >> >provided in the arguments.
> > > >> >L3fwd is supposed to support multiple queue. Right?
> > > >>
> > > >> The entire premise of using event device is to showcase packet
> > > >scheduling to
> > > >> cores
> > > >> without the need for splitting packets across multiple queues.
> > > >>
> > > >> Queue config is ignored when event mode is selected.
> > > >
> > > >For atomic queues, we have single queue providing packets to a single
> > > >core at a time till processing on that core is completed, irrespective of
> > > >the flows on that hardware queue.
> > > >And multiple queues are required to distribute separate packets on
> > > >separate cores, with these atomic queues maintaining the ordering and
> > > >not scheduling on other core, until processing core has completed its
> > > >job.
> > > >To have this solution generic, we should also take config parameter -
> > > >(port, number of queues) to enable multiple ethernet RX queues.
> > > >
> > >
> > > Not sure I follow we connect Rx queue to an event queue which is then
> > > linked to multiple event ports which are polled on
> > > by respective cores.
> >
> > This is what we too support, but with atomic queue case the scenario gets
> little complex.
> > Each atomic queue can be scheduled only to one event port at a time, until 
> > all
> the events from
> > that event port are processed. Then only it can move to other event port.
> 
> This would make it a poll mode. We might as well use normal PMD + RSS
> for the same instead.
> i.e use l3fwd in poll mode. It will be the same in terms of performance. 
> Right?

We do not need to have a complete config, but can have a parameter as number of 
RX
queues per port. We will send a patch on top of this to support the same.

Thanks,
Nipun

> 
> >
> > To have separate event ports process packets at same time in atomic 
> > scenario,
> multiple queues
> > are required. As l3fwd supports multiple queues, it seems legitimate to add 
> > the
> support.
> >
> > Thanks,
> > Nipun
> >
> > > How would increasing Rx queues help? Distributing flows from single event
> > > queue to multiple event ports is the responsibility
> > > of Event device as per spec.
> > > Does DPAA/2 function differently?
> > >
> > > Regards,
> > > Pavan.
> > >
> > > >Regards,
> > > >Nipun
> > > >
> > > >>
> > > >> >
> > > >> >Regards,
> > > >> >Nipun
> > > >> >
> > > >>
> > > >> Regards,
> > > >> Pavan.

Re: [dpdk-dev] [PATCH v2 04/11] examples/l3fwd: add ethdev setup based on eventdev

[Jerin Jacob]

On Fri, Jan 3, 2020 at 2:36 PM Nipun Gupta  wrote:
>
>
>
> > -Original Message-
> > From: Jerin Jacob 
> > Sent: Thursday, January 2, 2020 3:04 PM
> > To: Nipun Gupta 
> > Cc: Pavan Nikhilesh Bhagavatula ; Jerin Jacob
> > Kollanukkaran ; Marko Kovacevic
> > ; Ori Kam ; Bruce
> > Richardson ; Radu Nicolau
> > ; Akhil Goyal ; Tomasz
> > Kantecki ; Sunil Kumar Kori ;
> > Hemant Agrawal ; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v2 04/11] examples/l3fwd: add ethdev setup
> > based on eventdev
> >
> > On Thu, Jan 2, 2020 at 2:20 PM Nipun Gupta  wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Pavan Nikhilesh Bhagavatula 
> > > > Sent: Thursday, January 2, 2020 11:52 AM
> > > > To: Nipun Gupta ; Jerin Jacob Kollanukkaran
> > > > ; Marko Kovacevic ; Ori
> > > > Kam ; Bruce Richardson
> > > > ; Radu Nicolau ;
> > > > Akhil Goyal ; Tomasz Kantecki
> > > > ; Sunil Kumar Kori ;
> > > > Hemant Agrawal 
> > > > Cc: dev@dpdk.org
> > > > Subject: RE: [dpdk-dev] [PATCH v2 04/11] examples/l3fwd: add ethdev 
> > > > setup
> > > > based on eventdev
> > > >
> > > > >> >&local_port_conf);
> > > > >> >> +   if (ret < 0)
> > > > >> >> +   rte_exit(EXIT_FAILURE,
> > > > >> >> +"Cannot configure device: err=%d,
> > > > >> >> port=%d\n",
> > > > >> >> +ret, port_id);
> > > > >> >> +
> > > > >> >
> > > > >> >We should be using number of RX queues as per the config option
> > > > >> >provided in the arguments.
> > > > >> >L3fwd is supposed to support multiple queue. Right?
> > > > >>
> > > > >> The entire premise of using event device is to showcase packet
> > > > >scheduling to
> > > > >> cores
> > > > >> without the need for splitting packets across multiple queues.
> > > > >>
> > > > >> Queue config is ignored when event mode is selected.
> > > > >
> > > > >For atomic queues, we have single queue providing packets to a single
> > > > >core at a time till processing on that core is completed, irrespective 
> > > > >of
> > > > >the flows on that hardware queue.
> > > > >And multiple queues are required to distribute separate packets on
> > > > >separate cores, with these atomic queues maintaining the ordering and
> > > > >not scheduling on other core, until processing core has completed its
> > > > >job.
> > > > >To have this solution generic, we should also take config parameter -
> > > > >(port, number of queues) to enable multiple ethernet RX queues.
> > > > >
> > > >
> > > > Not sure I follow we connect Rx queue to an event queue which is then
> > > > linked to multiple event ports which are polled on
> > > > by respective cores.
> > >
> > > This is what we too support, but with atomic queue case the scenario gets
> > little complex.
> > > Each atomic queue can be scheduled only to one event port at a time, 
> > > until all
> > the events from
> > > that event port are processed. Then only it can move to other event port.
> >
> > This would make it a poll mode. We might as well use normal PMD + RSS
> > for the same instead.
> > i.e use l3fwd in poll mode. It will be the same in terms of performance. 
> > Right?
>
> We do not need to have a complete config, but can have a parameter as number 
> of RX
> queues per port. We will send a patch on top of this to support the same.

Looks good to me.

>
> Thanks,
> Nipun
>
> >
> > >
> > > To have separate event ports process packets at same time in atomic 
> > > scenario,
> > multiple queues
> > > are required. As l3fwd supports multiple queues, it seems legitimate to 
> > > add the
> > support.
> > >
> > > Thanks,
> > > Nipun
> > >
> > > > How would increasing Rx queues help? Distributing flows from single 
> > > > event
> > > > queue to multiple event ports is the responsibility
> > > > of Event device as per spec.
> > > > Does DPAA/2 function differently?
> > > >
> > > > Regards,
> > > > Pavan.
> > > >
> > > > >Regards,
> > > > >Nipun
> > > > >
> > > > >>
> > > > >> >
> > > > >> >Regards,
> > > > >> >Nipun
> > > > >> >
> > > > >>
> > > > >> Regards,
> > > > >> Pavan.

Re: [dpdk-dev] [PATCH v2 1/3] eal/arm64: relax the io barrier for aarch64

[Gavin Hu]

Hi Jerin,

> -Original Message-
> From: Jerin Jacob 
> Sent: Friday, January 3, 2020 3:35 PM
> To: Gavin Hu 
> Cc: dpdk-dev ; nd ; David Marchand
> ; tho...@monjalon.net;
> rasl...@mellanox.com; maxime.coque...@redhat.com; tiwei@intel.com;
> hemant.agra...@nxp.com; jer...@marvell.com; Pavan Nikhilesh
> ; Honnappa Nagarahalli
> ; Ruifeng Wang
> ; Phil Yang ; Joyce Kong
> ; Steve Capper 
> Subject: Re: [dpdk-dev] [PATCH v2 1/3] eal/arm64: relax the io barrier for
> aarch64
> 
> On Fri, Jan 3, 2020 at 12:00 PM Gavin Hu  wrote:
> >
> > Hi Jerin,
> 
> Hi Gavin,
> 
> >
> > > -Original Message-
> > > From: Jerin Jacob 
> > > Sent: Thursday, January 2, 2020 5:52 PM
> > > To: Gavin Hu 
> > > Cc: dpdk-dev ; nd ; David Marchand
> > > ; tho...@monjalon.net;
> > > rasl...@mellanox.com; maxime.coque...@redhat.com;
> tiwei@intel.com;
> > > hemant.agra...@nxp.com; jer...@marvell.com; Pavan Nikhilesh
> > > ; Honnappa Nagarahalli
> > > ; Ruifeng Wang
> > > ; Phil Yang ; Joyce Kong
> > > ; Steve Capper 
> > > Subject: Re: [dpdk-dev] [PATCH v2 1/3] eal/arm64: relax the io barrier for
> > > aarch64
> > >
> > > On Mon, Dec 23, 2019 at 3:46 PM Gavin Hu  wrote:
> > > >
> > > > Hi Jerin,
> > > >
> > > > > -Original Message-
> > > > > From: Jerin Jacob 
> > > > > Sent: Monday, December 23, 2019 5:20 PM
> > > > > To: Gavin Hu 
> > > > > Cc: dpdk-dev ; nd ; David Marchand
> > > > > ; tho...@monjalon.net;
> > > > > rasl...@mellanox.com; maxime.coque...@redhat.com;
> > > > > tiwei@intel.com; hemant.agra...@nxp.com; jer...@marvell.com;
> > > > > Pavan Nikhilesh ; Honnappa Nagarahalli
> > > > > ; Ruifeng Wang
> > > > > ; Phil Yang ; Joyce
> Kong
> > > > > ; Steve Capper 
> > > > > Subject: Re: [dpdk-dev] [PATCH v2 1/3] eal/arm64: relax the io barrier
> for
> > > > > aarch64
> > > > >
> > > > > On Mon, Dec 23, 2019 at 2:44 PM Gavin Hu 
> wrote:
> > > > > >
> > > > > > Hi Jerin,
> > > > >
> > > > > Hi Gavin,
> > > > >
> > > > > >
> > > > > > I think we are on the same page with regard to the problem, and the
> > > > > situations, thanks for illuminating the historical background of the 
> > > > > two
> > > > > barriers.
> > > > > > About the solution, I added inline comments.
> > > > > > > It will be optimization only when if we are changing in the fast 
> > > > > > > path.
> > > > > > > In the slow path, it does not matter.
> > > > > > > I think, the First step should be to use rte_cio_* wherever it is
> > > > > > > coherent memory used in _fast path_. I think, Almost every driver
> > > > > > > fixed that.
> > > > > > >
> > > > > > > I am not against this patch(changing the slow path to use rte_cio*
> > > > > > > from rte_io* and virtio changes associated with that).
> > > > > > > If you are taking that patch, pay attention to all the drivers in 
> > > > > > > the
> > > > > > > tree which is using rte_io* for mixed access in slowpath.
> > > > > > I see 30+ drivers has calling rte_io* directly or indirectly through
> > > > > rte_write/read*.
> > > > > > It is hard for me to figure out all the mixed accesses in these 
> > > > > > drivers,
> and
> > > > > as you said, it makes no sense to change the _slow path_.
> > > > > >
> > > > > > How about we keep the old rte_io as is, and introduce 'fast path'
> version
> > > > > of rte_io for new code use?
> > > > > > Then in future, we may merge the two?
> > > > > > Another reason about this proposal is maybe there is rte_io calling 
> > > > > > in
> > > the
> > > > > fast path, but they are not mixed accesses and rte_cio is not 
> > > > > suitable.
> > > > >
> > > > > Could you share more details about the case where fastpath + rte_io
> > > > > needed + rte_cio is not suitable?
> > > >
> > > > Here is an example for i40e, in the fast path, but only a pure io memory
> > > access.
> > > >
> > >
> https://code.dpdk.org/dpdk/v19.11/source/drivers/net/i40e/i40e_rxtx.c#L12
> > > 08
> > >
> > > Yes. That's a performance issue.
> > >
> > > It could be changed to following for the fix that works on x86, arm64
> > > with existing infra.
> > >
> > > From:
> > > I40E_PCI_REG_WRITE()
> > >
> > > to:
> > >
> > > rte_cio_wmb()
> > > I40E_PCI_REG_WRITE_RELAXED()
> > Yes, this is correct, I will submit a new patch for this.
> > This is an example out of all the cases that I must fix before relaxing the
> rte_io barriers.
> > My plan is as follows, any comments are welcome!
> > 1. replace rte_*mb and rte_io_*mb with rte_cio_*mb where applicable in
> the fastpath, this is an optimization, as the barriers are relaxed.
> > 2. replace all the rte_io_*mb with rte_cio_*mb where applicable in the
> slowpath and control path
> > 3. until *all* the occurrences in the step 1 and 2 are done, then this path 
> > can
> be re-activated.
> >
> > Please advise if the above approach works from your viewpoint.
> 
> I would prefer to have ONLY the step (1) and add a note for the same
> in  https://doc.dpdk.org/guides/prog_guide/perf_opt_guidelines.html
> as documentation reference.
Ok, good idea, I 

Re: [dpdk-dev] [PATCH 09/14] examples/ipsec-secgw: add eventmode to ipsec-secgw

[Anoob Joseph]

Hi Konstantin,

Please see inline.

Thanks,
Anoob

> -Original Message-
> From: dev  On Behalf Of Ananyev, Konstantin
> Sent: Monday, December 23, 2019 10:13 PM
> To: Anoob Joseph ; Akhil Goyal
> ; Nicolau, Radu ; Thomas
> Monjalon 
> Cc: Lukas Bartosik ; Jerin Jacob Kollanukkaran
> ; Narayana Prasad Raju Athreya
> ; Ankur Dwivedi ;
> Archana Muniganti ; Tejasree Kondoj
> ; Vamsi Krishna Attunuru
> ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 09/14] examples/ipsec-secgw: add
> eventmode to ipsec-secgw
> 
> >
> > Add eventmode support to ipsec-secgw. This uses event helper to setup
> > and use the eventmode capabilities. Add driver inbound worker.
> >
> > Example command:
> > ./ipsec-secgw -c 0x1 -w 0002:02:00.0,ipsec_in_max_spi=100 -w
> > 0002:07:00.0  -w 0002:0e:00.0 -w 0002:10:00.1 -- -P -p 0x3 -u 0x1
> > --config "(0,0,0),(1,0,0)" -f a-aes-gcm-msa.cfg --transfer-mode 1
> > --schedule-type 2 --process-mode drv --process-dir in
> >
> > Signed-off-by: Anoob Joseph 
> > Signed-off-by: Lukasz Bartosik 
> > ---
> >  examples/ipsec-secgw/Makefile   |   1 +
> >  examples/ipsec-secgw/event_helper.c |   3 +
> >  examples/ipsec-secgw/event_helper.h |  26 +++
> > examples/ipsec-secgw/ipsec-secgw.c  | 344
> +++-
> >  examples/ipsec-secgw/ipsec.h|   7 +
> >  examples/ipsec-secgw/ipsec_worker.c | 180 +++
> >  examples/ipsec-secgw/meson.build|   2 +-
> >  7 files changed, 555 insertions(+), 8 deletions(-)  create mode
> > 100644 examples/ipsec-secgw/ipsec_worker.c
> >
> > diff --git a/examples/ipsec-secgw/Makefile
> > b/examples/ipsec-secgw/Makefile index 09e3c5a..f6fd94c 100644
> > --- a/examples/ipsec-secgw/Makefile
> > +++ b/examples/ipsec-secgw/Makefile
> > @@ -15,6 +15,7 @@ SRCS-y += sa.c
> >  SRCS-y += rt.c
> >  SRCS-y += ipsec_process.c
> >  SRCS-y += ipsec-secgw.c
> > +SRCS-y += ipsec_worker.c
> >  SRCS-y += event_helper.c
> >
> >  CFLAGS += -gdwarf-2
> > diff --git a/examples/ipsec-secgw/event_helper.c
> > b/examples/ipsec-secgw/event_helper.c
> > index 6549875..44f997d 100644
> > --- a/examples/ipsec-secgw/event_helper.c
> > +++ b/examples/ipsec-secgw/event_helper.c
> > @@ -984,6 +984,9 @@ eh_find_worker(uint32_t lcore_id, struct eh_conf
> *conf,
> > else
> > curr_conf.cap.burst = EH_RX_TYPE_NON_BURST;
> >
> > +   curr_conf.cap.ipsec_mode = conf->ipsec_mode;
> > +   curr_conf.cap.ipsec_dir = conf->ipsec_dir;
> > +
> > /* Parse the passed list and see if we have matching capabilities */
> >
> > /* Initialize the pointer used to traverse the list */ diff --git
> > a/examples/ipsec-secgw/event_helper.h
> > b/examples/ipsec-secgw/event_helper.h
> > index 2895dfa..07849b0 100644
> > --- a/examples/ipsec-secgw/event_helper.h
> > +++ b/examples/ipsec-secgw/event_helper.h
> > @@ -74,6 +74,22 @@ enum eh_tx_types {
> > EH_TX_TYPE_NO_INTERNAL_PORT
> >  };
> >
> > +/**
> > + * Event mode ipsec mode types
> > + */
> > +enum eh_ipsec_mode_types {
> > +   EH_IPSEC_MODE_TYPE_APP = 0,
> > +   EH_IPSEC_MODE_TYPE_DRIVER
> > +};
> > +
> > +/**
> > + * Event mode ipsec direction types
> > + */
> > +enum eh_ipsec_dir_types {
> > +   EH_IPSEC_DIR_TYPE_OUTBOUND = 0,
> > +   EH_IPSEC_DIR_TYPE_INBOUND,
> > +};
> > +
> >  /* Event dev params */
> >  struct eventdev_params {
> > uint8_t eventdev_id;
> > @@ -183,6 +199,12 @@ struct eh_conf {
> >  */
> > void *mode_params;
> > /**< Mode specific parameters */
> > +
> > +   /** Application specific params */
> > +   enum eh_ipsec_mode_types ipsec_mode;
> > +   /**< Mode of ipsec run */
> > +   enum eh_ipsec_dir_types ipsec_dir;
> > +   /**< Direction of ipsec processing */
> >  };
> >
> >  /* Workers registered by the application */ @@ -194,6 +216,10 @@
> > struct eh_app_worker_params {
> > /**< Specify status of rx type burst */
> > uint64_t tx_internal_port : 1;
> > /**< Specify whether tx internal port is available */
> > +   uint64_t ipsec_mode : 1;
> > +   /**< Specify ipsec processing level */
> > +   uint64_t ipsec_dir : 1;
> > +   /**< Specify direction of ipsec */
> > };
> > uint64_t u64;
> > } cap;
> > diff --git a/examples/ipsec-secgw/ipsec-secgw.c
> > b/examples/ipsec-secgw/ipsec-secgw.c
> > index 7506922..c5d95b9 100644
> > --- a/examples/ipsec-secgw/ipsec-secgw.c
> > +++ b/examples/ipsec-secgw/ipsec-secgw.c
> > @@ -2,6 +2,7 @@
> >   * Copyright(c) 2016 Intel Corporation
> >   */
> >
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -14,6 +15,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  #include 
> > @@ -41,12 +43,17 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >
> > +#include "event_helper.h"
> >  #include "ipsec.h"
> >  #include "parser.h"
> >
> 

Re: [dpdk-dev] [PATCH 09/14] examples/ipsec-secgw: add eventmode to ipsec-secgw

[Anoob Joseph]

Hi Konstantin

Please see inline.

Thanks,
Anoob

> -Original Message-
> From: Ananyev, Konstantin 
> Sent: Tuesday, December 24, 2019 6:18 PM
> To: Anoob Joseph ; Akhil Goyal
> ; Nicolau, Radu ; Thomas
> Monjalon 
> Cc: Lukas Bartosik ; Jerin Jacob Kollanukkaran
> ; Narayana Prasad Raju Athreya
> ; Ankur Dwivedi ;
> Archana Muniganti ; Tejasree Kondoj
> ; Vamsi Krishna Attunuru
> ; dev@dpdk.org
> Subject: [EXT] RE: [PATCH 09/14] examples/ipsec-secgw: add eventmode to
> ipsec-secgw
> 
> External Email
> 
> --
> > Add eventmode support to ipsec-secgw. This uses event helper to setup
> > and use the eventmode capabilities. Add driver inbound worker.
> >
> > Example command:
> > ./ipsec-secgw -c 0x1 -w 0002:02:00.0,ipsec_in_max_spi=100 -w
> > 0002:07:00.0  -w 0002:0e:00.0 -w 0002:10:00.1 -- -P -p 0x3 -u 0x1
> > --config "(0,0,0),(1,0,0)" -f a-aes-gcm-msa.cfg --transfer-mode 1
> > --schedule-type 2 --process-mode drv --process-dir in
> 
> As  I can see new event mode is totally orthogonal to the existing poll mode.
> Event mode has it is own data-path, and it doesn't reuse any part of poll-
> mode data-path code.
> Plus in event mode many poll-mode options:
> libirary/legacy mode, fragment/reassemble, replay-window, ESN, fall-back
> session, etc.
> are simply ignored.

[Anoob] The features are not supported with the initial version. But the 
features are equally applicable to eventmode and is planned for the future. 
Also, fragment/reassemble, replay-window, ESN, fall-back session etc are not 
applicable for non-library mode. We can follow the same logic and allow for an 
extra arg (which is --transfer-mode).
 
> Also as I can read the current code -
> right now these modes can't be mixed and used together.
> User has to use either only event based or poll mode API/devices.

[Anoob] Same like how we cannot mix library and non-library modes.
 
> 
> If so, then at least we need a check (and report with error exit) for these
> mutually exclusive option variants.

[Anoob] Will do that.
 
> Probably even better would be to generate two separate binaries Let say:
> ipsec-secgw-event and ipsec-secgw-poll.
> We can still keep the same parent directory, makefile, common src files etc.
> for both.

[Anoob] I would be inclined to not fork the current application. Do you see any 
issues if the same binary could run in both modes. The default behavior would 
be poll mode (with existing behavior).
 
> 
> >
> > Signed-off-by: Anoob Joseph 
> > Signed-off-by: Lukasz Bartosik 
> > ---
> >  examples/ipsec-secgw/Makefile   |   1 +
> >  examples/ipsec-secgw/event_helper.c |   3 +
> >  examples/ipsec-secgw/event_helper.h |  26 +++
> > examples/ipsec-secgw/ipsec-secgw.c  | 344
> +++-
> >  examples/ipsec-secgw/ipsec.h|   7 +
> >  examples/ipsec-secgw/ipsec_worker.c | 180 +++
> >  examples/ipsec-secgw/meson.build|   2 +-
> >  7 files changed, 555 insertions(+), 8 deletions(-)  create mode
> > 100644 examples/ipsec-secgw/ipsec_worker.c
> >
> > diff --git a/examples/ipsec-secgw/Makefile
> > b/examples/ipsec-secgw/Makefile index 09e3c5a..f6fd94c 100644
> > --- a/examples/ipsec-secgw/Makefile
> > +++ b/examples/ipsec-secgw/Makefile
> > @@ -15,6 +15,7 @@ SRCS-y += sa.c
> >  SRCS-y += rt.c
> >  SRCS-y += ipsec_process.c
> >  SRCS-y += ipsec-secgw.c
> > +SRCS-y += ipsec_worker.c
> >  SRCS-y += event_helper.c
> >
> >  CFLAGS += -gdwarf-2
> > diff --git a/examples/ipsec-secgw/event_helper.c
> > b/examples/ipsec-secgw/event_helper.c
> > index 6549875..44f997d 100644
> > --- a/examples/ipsec-secgw/event_helper.c
> > +++ b/examples/ipsec-secgw/event_helper.c
> > @@ -984,6 +984,9 @@ eh_find_worker(uint32_t lcore_id, struct eh_conf
> *conf,
> > else
> > curr_conf.cap.burst = EH_RX_TYPE_NON_BURST;
> >
> > +   curr_conf.cap.ipsec_mode = conf->ipsec_mode;
> > +   curr_conf.cap.ipsec_dir = conf->ipsec_dir;
> > +
> > /* Parse the passed list and see if we have matching capabilities */
> >
> > /* Initialize the pointer used to traverse the list */ diff --git
> > a/examples/ipsec-secgw/event_helper.h
> > b/examples/ipsec-secgw/event_helper.h
> > index 2895dfa..07849b0 100644
> > --- a/examples/ipsec-secgw/event_helper.h
> > +++ b/examples/ipsec-secgw/event_helper.h
> > @@ -74,6 +74,22 @@ enum eh_tx_types {
> > EH_TX_TYPE_NO_INTERNAL_PORT
> >  };
> >
> > +/**
> > + * Event mode ipsec mode types
> > + */
> > +enum eh_ipsec_mode_types {
> > +   EH_IPSEC_MODE_TYPE_APP = 0,
> > +   EH_IPSEC_MODE_TYPE_DRIVER
> > +};
> > +
> > +/**
> > + * Event mode ipsec direction types
> > + */
> > +enum eh_ipsec_dir_types {
> > +   EH_IPSEC_DIR_TYPE_OUTBOUND = 0,
> > +   EH_IPSEC_DIR_TYPE_INBOUND,
> > +};
> > +
> >  /* Event dev params */
> >  struct eventdev_params {
> > uint8_t eventdev_id;
> > @@ -183,6 +199,12 @@ struct eh_conf {
> >  */
> > void *mode_params;
> > /**< Mode

[dpdk-dev] [Bug 379] Build fail using dpdk-setup.sh in RedHat version 3.10.0-862.rt56.804.el7.x86_64

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=379

Thomas Monjalon (tho...@monjalon.net) changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
 CC||tho...@monjalon.net

--- Comment #1 from Thomas Monjalon (tho...@monjalon.net) ---
Please see
http://doc.dpdk.org/guides/linux_gsg/sys_reqs.html#compilation-of-the-dpdk

You need the kernel headers if you build a kernel module.
Either install the package for it or disable compilation of kni and igb_uio.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: [dpdk-dev] [PATCH] add ABI checks

[Kinsella, Ray]

> -Original Message-
> From: Richardson, Bruce 
> Sent: Friday 20 December 2019 15:32
> To: David Marchand ; dev@dpdk.org
> Cc: tho...@monjalon.net; Laatz, Kevin ;
> acon...@redhat.com; nhor...@tuxdriver.com; Michael Santana
> ; Mcnamara, John ;
> Kovacevic, Marko ; Kinsella, Ray
> 
> Subject: RE: [PATCH] add ABI checks
> 
> 
> 
> > -Original Message-
> > From: David Marchand 
> > Sent: Friday, December 20, 2019 3:21 PM
> > To: dev@dpdk.org
> > Cc: tho...@monjalon.net; Richardson, Bruce
> > ; Laatz, Kevin ;
> > acon...@redhat.com; nhor...@tuxdriver.com; Michael Santana
> > ; Mcnamara, John
> ;
> > Kovacevic, Marko 
> > Subject: [PATCH] add ABI checks
> >
> > Starting from Kevin and Bruce idea of using libabigail, here is an
> > alternate approach to implement ABI checks.
> >
> > By default, those checks are disabled and enabling them requires a
> > manual step that generates the ABI dumps on a reference version for a
> > set of configurations.
> >
> > Those checks are enabled in the CI by default for the default meson
> > options on x86 and aarch64 so that proposed patches are validated.
> > A cache of the ABI is stored in travis jobs.
> > Checks can be only informational by setting ABI_CHECKS_WARN_ONLY when
> > breaking the ABI in a future release.
> >
> > For advanced developers and maintainers, the contributing guide
> > details the higher level scripts that are quite close to the existing
> > devtools scripts.
> >
> > Signed-off-by: David Marchand 
> > ---
> >  .ci/linux-build.sh  | 43 +++
> >  .travis.yml | 20 +++--
> >  devtools/check-abi-dump.sh  | 46
> +
> >  devtools/check-abi-reference.sh | 27 +
> >  devtools/dpdk.abignore  |  2 ++
> >  devtools/gen-abi-dump.sh| 29 ++
> >  devtools/gen-abi-reference.sh   | 24 +++
> >  devtools/test-build.sh  | 13 ++--
> >  devtools/test-meson-builds.sh   |  6 
> >  doc/guides/contributing/patches.rst | 25 
> >  10 files changed, 230 insertions(+), 5 deletions(-)  create mode
> > 100755 devtools/check-abi-dump.sh  create mode 100755
> > devtools/check-abi- reference.sh  create mode 100644
> > devtools/dpdk.abignore  create mode
> > 100755 devtools/gen-abi-dump.sh  create mode 100755 devtools/gen-abi-
> > reference.sh
> >
> > diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh index
> > ccc3a7ccd..345dba264 100755
> > --- a/.ci/linux-build.sh
> > +++ b/.ci/linux-build.sh
> > @@ -30,8 +30,51 @@ fi
> >
> >  OPTS="$OPTS --default-library=$DEF_LIB"
> >  meson build --werror -Dexamples=all $OPTS
> > +
> > +if [ "$ABI_CHECKS" = "1" ]; then
> > +git remote add ref ${REF_GIT_REPO:-https://dpdk.org/git/dpdk}
> > +git fetch --tags ref ${REF_GIT_BRANCH:-master}
> > +
> > +head=$(git describe --all)
> > +tag=$(git describe --abbrev=0)
> > +
> > +if [ "$(cat reference/VERSION 2>/dev/null)" != "$tag" ]; then
> > +rm -rf reference
> > +fi
> > +
> > +if [ ! -d reference ]; then
> > +gen_abi_dump=$(mktemp -t gen-abi-dump-XXX.sh)
> > +cp -a devtools/gen-abi-dump.sh $gen_abi_dump
> > +
> > +git checkout -qf $tag
> > +ninja -C build
> > +$gen_abi_dump build reference
> > +
> > +if [ "$AARCH64" != "1" ]; then
> > +mkdir -p reference/app
> > +cp -a build/app/dpdk-testpmd reference/app/
> > +
> > +export
> LD_LIBRARY_PATH=$(pwd)/build/lib:$(pwd)/build/drivers
> > +devtools/test-null.sh reference/app/dpdk-testpmd
> > +unset LD_LIBRARY_PATH
> > +fi
> > +echo $tag > reference/VERSION
> > +
> > +git checkout -qf $head
> > +fi
> > +fi
> > +
> >  ninja -C build
> >
> > +if [ "$ABI_CHECKS" = "1" ]; then
> > +devtools/check-abi-dump.sh build reference
> ${ABI_CHECKS_WARN_ONLY:-}
> > +if [ "$AARCH64" != "1" ]; then
> > +export LD_LIBRARY_PATH=$(pwd)/build/lib:$(pwd)/build/drivers
> > +devtools/test-null.sh reference/app/dpdk-testpmd
> > +unset LD_LIBRARY_PATH
> > +fi
> > +fi
> > +
> >  if [ "$AARCH64" != "1" ]; then
> >  devtools/test-null.sh
> >  fi
> > diff --git a/.travis.yml b/.travis.yml index 8f90d06f2..bbb060fa2
> > 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -1,5 +1,8 @@
> >  language: c
> > -cache: ccache
> > +cache:
> > +  ccache: true
> > +  directories:
> > +- reference
> >  compiler:
> >- gcc
> >- clang
> > @@ -21,7 +24,7 @@ aarch64_packages: &aarch64_packages
> >
> >  extra_packages: &extra_packages
> >- *required_packages
> > -  - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> > +  - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4,
> > + abigail-tools]
> >
> >  build_32b_packages: &build_32b_packages
> >- *required_packages
> > @@ -59,6 +62,13 @@ matrix:
> >apt:
> >  pac

[dpdk-dev] Offloading L4 checksum to crypto device

[Heng Wang]

Hi,
 This is Heng from Ericsson. We are now developing a platform based on dpdk. 
The platform usually processes the ipsec packets encapsulating udp packets.
  You know, calculating udp checksum is always time consuming. We found a 
hardware solution where our crypto device can calculate the udp checksum during 
encryption.
 Unfortunately, in DPDK, I didn't find any feature flag for it. Also the API 
rte_cryptodev_configure doesn't allow us to pass any offload flag to the crypto 
device.
 I think this could be a common case to calculate something, like checksums, 
before encryption in crypto devices. Should we consider add some new feature 
flag and offload support in dpdk crypto device?

Regards,
Heng

Re: [dpdk-dev] dpdk : windows build issue

[Revanur Srinivasa Kumar (RBEI/ETA)]

Hi,

Any pointers to the windows10 build is a great help. Now the linux setup is 
running; need is to evaluate on windows.

Regards
Srinivas 



-Original Message-
From: Pallavi Kadam  
Sent: Monday, September 23, 2019 11:54 PM
To: Revanur Srinivasa Kumar (RBEI/ETA) ; 
dev@dpdk.org
Subject: Re: [dpdk-dev] dpdk : windows build issue

Hi Srinivas

On 9/17/2019 2:34 AM, Revanur Srinivasa Kumar (RBEI/ETA) wrote:
> Hi,
>
> We are evaluating dpdk on windows10 64 bit desktop version ( linux runs fine 
> ). Build system is setup on PC, but I see that dpdk is supported on windows 
> server 2016/2019 only.
>
> Can we run dpdk on windows 10 ?
>
> Best regards,
>
> srinivas

We have been using Windows server to run and for validation purpose. 
But, Windows DPDK (source code) builds on Windows 10 as well.

Please refer to Windows build_dpdk.rst in doc for build tools installation.

Thanks,

Pallavi

Re: [dpdk-dev] 18.11.6 (LTS) patches review and test

[Lili Deng]

Hi Kevin,



I'd like to sign off validation dpdk-stable-18.11.6-rc1 against Azure gallery 
images.

Version used - 
https://git.dpdk.org/dpdk-stable/snapshot/dpdk-stable-18.11.6-rc1.tar.xz



Below are test matrix and results -

Tests

Ubuntu 16.04

Ubuntu 18.04

Ubuntu 19.10

RHEL 7-RAW

SLES 15

RHEL 7.5

CentOS 7.5

RHEL 8

CentOS 8

VERIFY-DPDK-FAILSAFE-DURING-TRAFFIC

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

VERIFY-DPDK-BUILD-AND-TESTPMD-TEST

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

VERIFY-SRIOV-FAILSAFE-FOR-DPDK

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

VERIFY-DPDK-COMPLIANCE

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

VERIFY-DPDK-OVS

PASS

PASS

PASS

SKIPPED

SKIPPED

SKIPPED

SKIPPED

SKIPPED

SKIPPED

VERIFY-DPDK-RING-LATENCY

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PERF-DPDK-FWD-PPS-DS15

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PERF-DPDK-SINGLE-CORE-PPS-DS4

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PERF-DPDK-SINGLE-CORE-PPS-DS15

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PERF-DPDK-MULTICORE-PPS-DS15

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PASS

PERF-DPDK-MULTICORE-PPS-F32

PASS

PASS

PASS

FAIL

PASS

PASS

FAIL

PASS

FAIL



FAIL reason for PERF-DPDK-MULTICORE-PPS-F32 - the performance is not expected 
in some rate.

For example, when run 3 times, only 1/3 pass, maybe the size Standard_F32s_v2 
on Azure is unstable.



Thanks,

Lili

From: Pei Zhang mailto:pezh...@redhat.com>>
Sent: Tuesday, December 24, 2019 9:17:54 PM
To: Kevin Traynor mailto:ktray...@redhat.com>>
Cc: sta...@dpdk.org 
mailto:sta...@dpdk.org>>; dev@dpdk.org 
mailto:dev@dpdk.org>>; Abhishek Marathe 
mailto:abhishek.mara...@microsoft.com>>; Akhil 
Goyal mailto:akhil.go...@nxp.com>>; Ali Alnubani 
mailto:alia...@mellanox.com>>; benjamin walker 
mailto:benjamin.wal...@intel.com>>; David 
Christensen mailto:d...@linux.vnet.ibm.com>>; Hemant 
Agrawal mailto:hemant.agra...@nxp.com>>; Ian Stokes 
mailto:ian.sto...@intel.com>>; Jerin Jacob 
mailto:jer...@marvell.com>>; John McNamara 
mailto:john.mcnam...@intel.com>>; Ju-Hyoung Lee 
mailto:juh...@microsoft.com>>; Luca Boccassi 
mailto:bl...@debian.org>>; pingx yu 
mailto:pingx...@intel.com>>; qian q xu 
mailto:qian.q...@intel.com>>; Raslan Darawsheh 
mailto:rasl...@mellanox.com>>; Thomas Monjalon 
mailto:tho...@monjalon.net>>; yuan peng 
mailto:yuan.p...@intel.com>>; zhaoyan chen 
mailto:zhaoyan.c...@intel.com>>
Subject: [EXTERNAL] Re: 18.11.6 (LTS) patches review and test



Hi Kevin,

Testing with 18.11.6-rc1 from Red Hat looks good.

We cover below 14 scenarios and and all get PASS:

(1)Guest with device assignment(PF) throughput testing(1G hugepage size):  PASS
(2)Guest with device assignment(PF) throughput testing(2M hugepage size) :  PASS
(3)Guest with device assignment(VF) throughput testing: PASS
(4)PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS
(5)PVP vhost-user 2Q throughput testing: PASS
(6)PVP vhost-user 1Q - cross numa node  throughput testing: PASS
(7)Guest with vhost-user 2 queues throughput testing: PASS
(8)vhost-user reconnect with dpdk-client, qemu-server: ovs reconnect: PASS
(9)vhost-user reconnect with dpdk-client, qemu-server: qemu reconnect:  PASS
(10)PVP 1Q live migration testing: PASS
(11)PVP 1Q cross numa node live migration testing: PASS
(12)Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS
(13)Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS
(14)Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS


Versions:
kernel 3.10
qemu 2.12
dpdk: 
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpdk.org%2Fgit%2Fdpdk-stabl&data=02%7C01%7Cjuhlee%40microsoft.com%7Caff14f2d05f646e47acf08d788f9d0ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637128478863352441&sdata=kDrMrJweYTTyed5iijS9m0u1LbcrsoHPVx3vu2oNe9o%3D&reserved=0
   remotes/origin/18.11
# git log -1
commit ae63431d6aa03aba1e73f80e797ee0af151adeb5
Author: Kevin Traynor mailto:ktray...@redhat.com>>
Date:   Wed Dec 18 11:24:09 2019 +
version: 18.11.6-rc1
Signed-off-by: Kevin Traynor 
mailto:ktray...@redhat.com>>


Best regards,

Pei


- Original Message -
From: "Kevin Traynor" mailto:ktray...@redhat.com>>
To: sta...@dpdk.org

Re: [dpdk-dev] [PATCH] mbuf: document how to set length when attaching ext buffer

[Jörg Thalheim]

Looks good to me!

Olivier Matz  writes:

> From: Jörg Thalheim 
>
> Enhance API documentation of rte_pktmbuf_attach_extbuf() to
> explain that the attached mbuf is initialized with length = 0.
>
> Link: https://bugs.dpdk.org/show_bug.cgi?id=362
>
> Signed-off-by: Jörg Thalheim 
> Signed-off-by: Olivier Matz 
> ---
>
> Hi,
>
> This patch is a slight reword of a patch submitted in bug id 362 by Jörg
> Thalheim.
>
> @Jörg, feel free to comment if I missed something.
>
> Thanks
> Olivier
>
>
>  lib/librte_mbuf/rte_mbuf.h | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 219b110b7..2d4bda251 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -924,10 +924,14 @@ rte_pktmbuf_ext_shinfo_init_helper(void *buf_addr, 
> uint16_t *buf_len,
>   * provided via shinfo. This callback function will be called once all the
>   * mbufs are detached from the buffer (refcnt becomes zero).
>   *
> - * The headroom for the attaching mbuf will be set to zero and this can be
> - * properly adjusted after attachment. For example, ``rte_pktmbuf_adj()``
> + * The headroom length of the attaching mbuf will be set to zero and this
> + * can be properly adjusted after attachment. For example, 
> ``rte_pktmbuf_adj()``
>   * or ``rte_pktmbuf_reset_headroom()`` might be used.
>   *
> + * Similarly, the packet length is initialized to 0. If the buffer contains
> + * data, the user has to adjust ``data_len`` and the ``pkt_len`` field of
> + * the mbuf accordingly.
> + *
>   * More mbufs can be attached to the same external buffer by
>   * ``rte_pktmbuf_attach()`` once the external buffer has been attached by
>   * this API.

Re: [dpdk-dev] [PATCH v3 36/36] net/i40e/base: add new link speed constants

[Loktionov, Aleksandr]

Good day dear ALL

It's a new feature /*new speed display*/ but from other point of view it's a 
fix /*because it was found after new feature release*/

-Original Message-
From: Xing, Beilei  
Sent: Friday, December 27, 2019 6:38 AM
To: Ye, Xiaolong ; Zhang, Qi Z 
Cc: dev@dpdk.org; Stillwell Jr, Paul M ; 
Loktionov, Aleksandr 
Subject: RE: [PATCH v3 36/36] net/i40e/base: add new link speed constants



> -Original Message-
> From: Ye, Xiaolong
> Sent: Monday, December 16, 2019 10:44 AM
> To: Xing, Beilei ; Zhang, Qi Z 
> 
> Cc: dev@dpdk.org; Stillwell Jr, Paul M 
> ; Ye, Xiaolong ; 
> Loktionov, Aleksandr 
> Subject: [PATCH v3 36/36] net/i40e/base: add new link speed constants
> 
> This patch fixes 'NIC Link is Up, Unknown bps' message in dmesg for 
> 2.5Gb/5Gb speeds. This problem is fixed by adding constants for 
> VIRTCHNL_LINK_SPEED_2_5GB and VIRTCHNL_LINK_SPEED_5GB.
> 

It's a fix patch, fix line is needed? The same comment is also for patch 27/36, 
25/36, 21/36, 14/36.

> Signed-off-by: Aleksandr Loktionov 
> Signed-off-by: Xiaolong Ye 
> ---
>  drivers/net/i40e/base/i40e_prototype.h | 4 
>  drivers/net/i40e/base/virtchnl.h   | 4 
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/net/i40e/base/i40e_prototype.h
> b/drivers/net/i40e/base/i40e_prototype.h
> index 0f06e3262..d8ab3ea0a 100644
> --- a/drivers/net/i40e/base/i40e_prototype.h
> +++ b/drivers/net/i40e/base/i40e_prototype.h
> @@ -505,6 +505,10 @@ i40e_virtchnl_link_speed(enum i40e_aq_link_speed
> link_speed)
>   return VIRTCHNL_LINK_SPEED_100MB;
>   case I40E_LINK_SPEED_1GB:
>   return VIRTCHNL_LINK_SPEED_1GB;
> + case I40E_LINK_SPEED_2_5GB:
> + return VIRTCHNL_LINK_SPEED_2_5GB;
> + case I40E_LINK_SPEED_5GB:
> + return VIRTCHNL_LINK_SPEED_5GB;
>   case I40E_LINK_SPEED_10GB:
>   return VIRTCHNL_LINK_SPEED_10GB;
>   case I40E_LINK_SPEED_40GB:
> diff --git a/drivers/net/i40e/base/virtchnl.h 
> b/drivers/net/i40e/base/virtchnl.h
> index c613d4761..92515bf34 100644
> --- a/drivers/net/i40e/base/virtchnl.h
> +++ b/drivers/net/i40e/base/virtchnl.h
> @@ -53,12 +53,14 @@ enum virtchnl_status_code {  #define 
> VIRTCHNL_ERR_PARAM VIRTCHNL_STATUS_ERR_PARAM  #define 
> VIRTCHNL_STATUS_NOT_SUPPORTED VIRTCHNL_STATUS_ERR_NOT_SUPPORTED
> 
> +#define VIRTCHNL_LINK_SPEED_2_5GB_SHIFT  0x0
>  #define VIRTCHNL_LINK_SPEED_100MB_SHIFT  0x1
>  #define VIRTCHNL_LINK_SPEED_1000MB_SHIFT 0x2
>  #define VIRTCHNL_LINK_SPEED_10GB_SHIFT   0x3
>  #define VIRTCHNL_LINK_SPEED_40GB_SHIFT   0x4
>  #define VIRTCHNL_LINK_SPEED_20GB_SHIFT   0x5
>  #define VIRTCHNL_LINK_SPEED_25GB_SHIFT   0x6
> +#define VIRTCHNL_LINK_SPEED_5GB_SHIFT0x7
> 
>  enum virtchnl_link_speed {
>   VIRTCHNL_LINK_SPEED_UNKNOWN = 0,
> @@ -68,6 +70,8 @@ enum virtchnl_link_speed {
>   VIRTCHNL_LINK_SPEED_40GB=
> BIT(VIRTCHNL_LINK_SPEED_40GB_SHIFT),
>   VIRTCHNL_LINK_SPEED_20GB=
> BIT(VIRTCHNL_LINK_SPEED_20GB_SHIFT),
>   VIRTCHNL_LINK_SPEED_25GB=
> BIT(VIRTCHNL_LINK_SPEED_25GB_SHIFT),
> + VIRTCHNL_LINK_SPEED_2_5GB   =
> BIT(VIRTCHNL_LINK_SPEED_2_5GB_SHIFT),
> + VIRTCHNL_LINK_SPEED_5GB =
> BIT(VIRTCHNL_LINK_SPEED_5GB_SHIFT),
>  };
> 
>  /* for hsplit_0 field of Rx HMC context */
> --
> 2.17.1




Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial 
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | 
Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). If you are not the intended recipient, please 
contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.

Re: [dpdk-dev] [dpdk-dev PATCH v2 2/6] raw/octeontx2_ep: add device configuration

[Mahipal Challa]

Hi Gavin,
Please see response inline.


> -Original Message-
> From: Gavin Hu 
> Sent: Thursday, January 2, 2020 3:48 PM
> To: Mahipal Challa ; dev@dpdk.org
> Cc: Jerin Jacob Kollanukkaran ; Narayana Prasad Raju
> Athreya ; Subrahmanyam Nilla
> ; Venkateshwarlu Nalla ; nd
> 
> Subject: [EXT] RE: [dpdk-dev] [dpdk-dev PATCH v2 2/6] raw/octeontx2_ep:
> add device configuration
> 
> External Email
> 
> --
> Hi Mahipal,
> 
> 3 comments inline.
> 
> > -Original Message-
> > From: dev  On Behalf Of Mahipal Challa
> > Sent: Friday, December 27, 2019 8:40 PM
> > To: dev@dpdk.org
> > Cc: jer...@marvell.com; pathr...@marvell.com; sni...@marvell.com;
> > venk...@marvell.com
> > Subject: [dpdk-dev] [dpdk-dev PATCH v2 2/6] raw/octeontx2_ep: add
> device
> > configuration
> >
> > Register "dev_configure" API to configure/initialize the SDP
> > VF PCIe devices.
> >
> > Signed-off-by: Mahipal Challa 
> > ---
> >  doc/guides/rawdevs/octeontx2_ep.rst|  29 ++
> >  drivers/common/octeontx2/hw/otx2_sdp.h | 184 +
> >  drivers/common/octeontx2/otx2_common.c |   9 +
> >  drivers/common/octeontx2/otx2_common.h |   4 +
> >  .../octeontx2/rte_common_octeontx2_version.map |   6 +
> >  drivers/raw/octeontx2_ep/Makefile  |   3 +
> >  drivers/raw/octeontx2_ep/meson.build   |   4 +-
> >  drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c  | 294 ++
> >  drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h  |  11 +
> >  drivers/raw/octeontx2_ep/otx2_ep_rawdev.c  | 148 +++
> >  drivers/raw/octeontx2_ep/otx2_ep_rawdev.h  | 434
> > -
> >  drivers/raw/octeontx2_ep/otx2_ep_vf.c  | 408
> +++
> >  drivers/raw/octeontx2_ep/otx2_ep_vf.h  |  10 +
> >  13 files changed, 1542 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/guides/rawdevs/octeontx2_ep.rst
> > b/doc/guides/rawdevs/octeontx2_ep.rst
> > index 5f5ed01..2507fcf 100644
> > --- a/doc/guides/rawdevs/octeontx2_ep.rst
> > +++ b/doc/guides/rawdevs/octeontx2_ep.rst
> > @@ -39,3 +39,32 @@ entry `sriov_numvfs` for the corresponding PF
> driver.
> >
> >  Once the required VFs are enabled, to be accessible from DPDK, VFs need
> to
> > be
> >  bound to vfio-pci driver.
> > +
> > +Device Setup
> > +
> > +
> > +The OCTEON TX2 SDP End Point VF devices will need to be bound to a
> > +user-space IO driver for use. The script ``dpdk-devbind.py`` script
> > +included with DPDK can be used to view the state of the devices and to
> bind
> > +them to a suitable DPDK-supported kernel driver. When querying the
> status
> > +of the devices, they will appear under the category of "Misc (rawdev)
> > +devices", i.e. the command ``dpdk-devbind.py --status-dev misc`` can be
> > +used to see the state of those devices alone.
> > +
> > +Device Configuration
> > +
> > +
> > +Configuring SDP EP rawdev device is done using the
> > ``rte_rawdev_configure()``
> > +API, which takes the mempool as parameter. PMD uses this pool to
> > send/receive
> > +packets to/from the HW.
> > +
> > +The following code shows how the device is configured
> > +
> > +.. code-block:: c
> > +
> > +   struct sdp_rawdev_info config = {0};
> > +   struct rte_rawdev_info rdev_info = {.dev_private = &config};
> > +   config.enqdeq_mpool = (void *)rte_mempool_create(...);
> > +
> > +   rte_rawdev_configure(dev_id, (rte_rawdev_obj_t)&rdev_info);
> > +
> > diff --git a/drivers/common/octeontx2/hw/otx2_sdp.h
> > b/drivers/common/octeontx2/hw/otx2_sdp.h
> > new file mode 100644
> > index 000..7e03317
> > --- /dev/null
> > +++ b/drivers/common/octeontx2/hw/otx2_sdp.h
> > @@ -0,0 +1,184 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(C) 2019 Marvell International Ltd.
> > + */
> > +
> > +#ifndef __OTX2_SDP_HW_H_
> > +#define __OTX2_SDP_HW_H_
> > +
> > +/* SDP VF IOQs */
> > +#define SDP_MIN_RINGS_PER_VF(1)
> > +#define SDP_MAX_RINGS_PER_VF(8)
> > +
> > +/* SDP VF IQ configuration */
> > +#define SDP_VF_MAX_IQ_DESCRIPTORS   (512)
> > +#define SDP_VF_MIN_IQ_DESCRIPTORS   (128)
> > +
> > +#define SDP_VF_DB_MIN   (1)
> > +#define SDP_VF_DB_TIMEOUT   (1)
> > +#define SDP_VF_INTR_THRESHOLD   (0x)
> > +
> > +#define SDP_VF_64BYTE_INSTR (64)
> > +#define SDP_VF_32BYTE_INSTR (32)
> > +
> > +/* SDP VF OQ configuration */
> > +#define SDP_VF_MAX_OQ_DESCRIPTORS   (512)
> > +#define SDP_VF_MIN_OQ_DESCRIPTORS   (128)
> > +#define SDP_VF_OQ_BUF_SIZE  (2048)
> > +#define SDP_VF_OQ_REFIL_THRESHOLD   (16)
> > +
> > +#define SDP_VF_OQ_INFOPTR_MODE  (1)
> > +#define SDP_VF_OQ_BUFPTR_MODE   (0)
> > +
> > +#define SDP_VF_OQ_INTR_PKT  (1)
> > +#define SDP_VF_OQ_INTR_TIME (10)
> > +#define SDP_VF_CFG_IO_QUEUESSDP_MAX_RINGS_PER_VF
> > +
> > +/* Wait time in millis

Re: [dpdk-dev] [dpdk-dev PATCH v2 4/6] raw/octeontx2_ep: add enqueue operation

[Mahipal Challa]

Hi Gavin,
Please see response inline.



> -Original Message-
> From: Gavin Hu 
> Sent: Thursday, January 2, 2020 4:13 PM
> To: Mahipal Challa ; dev@dpdk.org
> Cc: Jerin Jacob Kollanukkaran ; Narayana Prasad Raju
> Athreya ; Subrahmanyam Nilla
> ; Venkateshwarlu Nalla ; nd
> 
> Subject: [EXT] RE: [dpdk-dev] [dpdk-dev PATCH v2 4/6] raw/octeontx2_ep:
> add enqueue operation
> 
> External Email
> 
> --
> Hi Mahipal,
> 
> > -Original Message-
> > From: dev  On Behalf Of Mahipal Challa
> > Sent: Friday, December 27, 2019 8:40 PM
> > To: dev@dpdk.org
> > Cc: jer...@marvell.com; pathr...@marvell.com; sni...@marvell.com;
> > venk...@marvell.com
> > Subject: [dpdk-dev] [dpdk-dev PATCH v2 4/6] raw/octeontx2_ep: add
> > enqueue operation
> >
> > Add rawdev enqueue operation for SDP VF devices.
> >
> > Signed-off-by: Mahipal Challa 
> > ---
> >  doc/guides/rawdevs/octeontx2_ep.rst   |   6 +
> >  drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 242
> > ++
> >  drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h |  39 +
> >  drivers/raw/octeontx2_ep/otx2_ep_rawdev.c |   1 +
> >  drivers/raw/octeontx2_ep/otx2_ep_rawdev.h |  20 +++
> >  drivers/raw/octeontx2_ep/otx2_ep_vf.c |  24 +++
> >  6 files changed, 332 insertions(+)
> >
> > diff --git a/doc/guides/rawdevs/octeontx2_ep.rst
> > b/doc/guides/rawdevs/octeontx2_ep.rst
> > index 2507fcf..39a7c29 100644
> > --- a/doc/guides/rawdevs/octeontx2_ep.rst
> > +++ b/doc/guides/rawdevs/octeontx2_ep.rst
> > @@ -68,3 +68,9 @@ The following code shows how the device is
> > configured
> >
> > rte_rawdev_configure(dev_id, (rte_rawdev_obj_t)&rdev_info);
> >
> > +Performing Data Transfer
> > +
> > +
> > +To perform data transfer using SDP VF EP rawdev devices use standard
> > +``rte_rawdev_enqueue_buffers()`` and ``rte_rawdev_dequeue_buffers()``
> > APIs.
> > +
> > diff --git a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> > b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> > index 584b818..6910f08 100644
> > --- a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> > +++ b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> > @@ -403,3 +403,245 @@
> > return -ENOMEM;
> >  }
> >
> > +static inline void
> > +sdp_iqreq_delete(struct sdp_device *sdpvf,
> > +   struct sdp_instr_queue *iq, uint32_t idx) {
> > +   uint32_t reqtype;
> > +   void *buf;
> > +
> > +   buf = iq->req_list[idx].buf;
> > +   reqtype = iq->req_list[idx].reqtype;
> > +
> > +   switch (reqtype) {
> > +   case SDP_REQTYPE_NORESP:
> > +   rte_mempool_put(sdpvf->enqdeq_mpool, buf);
> > +   otx2_sdp_dbg("IQ buffer freed at idx[%d]", idx);
> > +   break;
> > +
> > +   case SDP_REQTYPE_NORESP_GATHER:
> > +   case SDP_REQTYPE_NONE:
> > +   default:
> > +   otx2_info("This iqreq mode is not supported:%d", reqtype);
> > +
> > +   }
> > +
> > +   /* Reset the request list at this index */
> > +   iq->req_list[idx].buf = NULL;
> > +   iq->req_list[idx].reqtype = 0;
> > +}
> > +
> > +static inline void
> > +sdp_iqreq_add(struct sdp_instr_queue *iq, void *buf,
> > +   uint32_t reqtype)
> > +{
> > +   iq->req_list[iq->host_write_index].buf = buf;
> > +   iq->req_list[iq->host_write_index].reqtype = reqtype;
> > +
> > +   otx2_sdp_dbg("IQ buffer added at idx[%d]", iq->host_write_index);
> > +
> > +}
> > +
> > +static void
> > +sdp_flush_iq(struct sdp_device *sdpvf,
> > +   struct sdp_instr_queue *iq,
> > +   uint32_t pending_thresh __rte_unused) {
> > +   uint32_t instr_processed = 0;
> > +
> > +   rte_spinlock_lock(&iq->lock);
> > +
> > +   iq->otx_read_index = sdpvf->fn_list.update_iq_read_idx(iq);
> > +   while (iq->flush_index != iq->otx_read_index) {
> > +   /* Free the IQ data buffer to the pool */
> > +   sdp_iqreq_delete(sdpvf, iq, iq->flush_index);
> > +   iq->flush_index =
> > +   sdp_incr_index(iq->flush_index, 1, iq->nb_desc);
> > +
> > +   instr_processed++;
> > +   }
> > +
> > +   iq->stats.instr_processed = instr_processed;
> > +   rte_atomic64_sub(&iq->instr_pending, instr_processed);
> > +
> > +   rte_spinlock_unlock(&iq->lock);
> > +}
> > +
> > +static inline void
> > +sdp_ring_doorbell(struct sdp_device *sdpvf __rte_unused,
> > +   struct sdp_instr_queue *iq)
> > +{
> > +   otx2_write64(iq->fill_cnt, iq->doorbell_reg);
> > +
> > +   /* Make sure doorbell write goes through */
> > +   rte_cio_wmb();
> This rte_cio_wmb() should be moved before the doorbell ring to guarantee
> the IQ command submitted in post_iqcmd is observed by the peer HW
> before observing the doorbell ring.

[Mahipal]: Yes, IQ command is ensured to be in memory well before the doorbell 
ring operation, this is done by "post_iqcmd" routine(please see below).
And this "rte_cio_wmb()" is just to ensure the doorbell write operation 
completion(As per your suggestion in v1, we changed this from rte_wmb() to 
rte_ci

[dpdk-dev] [PATCH] event/dsw: avoid credit leak on oversized enqueue bursts

[Mattias Rönnblom]

If an application issues rte_event_enqueue_new_burst() or
rte_event_enqueue_forward_burst() call with a burst of events longer
than the configured max enqueue burst size, DSW allocates credits not
only for events actually enqueued, but for the complete burst. If this
process is repeated, enough credits will have leaked to cause the
event device to backpressure (i.e. disallow) any new enqueue
operations.

In addition, the port-level enqueue xstats will log the wrong number
of events enqueued for oversized enqueues.

This patch makes DSW gracefully handle oversized enqueue bursts.

Fixes: 1c8e3caa3bfb ("event/dsw: add event scheduling and device start/stop")
Cc: sta...@dpdk.org

Signed-off-by: Mattias Rönnblom 
---
 drivers/event/dsw/dsw_event.c | 36 ---
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/drivers/event/dsw/dsw_event.c b/drivers/event/dsw/dsw_event.c
index 61a66fabf..b919244c6 100644
--- a/drivers/event/dsw/dsw_event.c
+++ b/drivers/event/dsw/dsw_event.c
@@ -1018,12 +1018,12 @@ dsw_event_enqueue(void *port, const struct rte_event 
*ev)
 }
 
 static __rte_always_inline uint16_t
-dsw_event_enqueue_burst_generic(void *port, const struct rte_event events[],
+dsw_event_enqueue_burst_generic(struct dsw_port *source_port,
+   const struct rte_event events[],
uint16_t events_len, bool op_types_known,
uint16_t num_new, uint16_t num_release,
uint16_t num_non_release)
 {
-   struct dsw_port *source_port = port;
struct dsw_evdev *dsw = source_port->dsw;
bool enough_credits;
uint16_t i;
@@ -1050,9 +1050,6 @@ dsw_event_enqueue_burst_generic(void *port, const struct 
rte_event events[],
return 0;
}
 
-   if (unlikely(events_len > source_port->enqueue_depth))
-   events_len = source_port->enqueue_depth;
-
dsw_port_note_op(source_port, events_len);
 
if (!op_types_known)
@@ -1108,24 +1105,41 @@ uint16_t
 dsw_event_enqueue_burst(void *port, const struct rte_event events[],
uint16_t events_len)
 {
-   return dsw_event_enqueue_burst_generic(port, events, events_len, false,
-  0, 0, 0);
+   struct dsw_port *source_port = port;
+
+   if (unlikely(events_len > source_port->enqueue_depth))
+   events_len = source_port->enqueue_depth;
+
+   return dsw_event_enqueue_burst_generic(source_port, events,
+  events_len, false, 0, 0, 0);
 }
 
 uint16_t
 dsw_event_enqueue_new_burst(void *port, const struct rte_event events[],
uint16_t events_len)
 {
-   return dsw_event_enqueue_burst_generic(port, events, events_len, true,
-  events_len, 0, events_len);
+   struct dsw_port *source_port = port;
+
+   if (unlikely(events_len > source_port->enqueue_depth))
+   events_len = source_port->enqueue_depth;
+
+   return dsw_event_enqueue_burst_generic(source_port, events,
+  events_len, true, events_len,
+  0, events_len);
 }
 
 uint16_t
 dsw_event_enqueue_forward_burst(void *port, const struct rte_event events[],
uint16_t events_len)
 {
-   return dsw_event_enqueue_burst_generic(port, events, events_len, true,
-  0, 0, events_len);
+   struct dsw_port *source_port = port;
+
+   if (unlikely(events_len > source_port->enqueue_depth))
+   events_len = source_port->enqueue_depth;
+
+   return dsw_event_enqueue_burst_generic(source_port, events,
+  events_len, true, 0, 0,
+  events_len);
 }
 
 uint16_t
-- 
2.17.1

[dpdk-dev] [PATCH 1/2] eal/freebsd: update CPU macro for FreeBSD 13 support

[Bruce Richardson]

In (currently unreleased) FreeBSD 13, the CPU_NAND macro has been renamed
to CPU_ANDNOT, so we need to use different DPDK-specific macros depending
on what system-defined ones are present.

Signed-off-by: Bruce Richardson 
---
 lib/librte_eal/freebsd/eal/include/rte_os.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/lib/librte_eal/freebsd/eal/include/rte_os.h 
b/lib/librte_eal/freebsd/eal/include/rte_os.h
index a5efe618f..eeb750cd8 100644
--- a/lib/librte_eal/freebsd/eal/include/rte_os.h
+++ b/lib/librte_eal/freebsd/eal/include/rte_os.h
@@ -29,6 +29,9 @@ typedef cpuset_t rte_cpuset_t;
CPU_COPY(&tmp, dst); \
 } while (0)
 #define RTE_CPU_FILL(set) CPU_FILL(set)
+
+/* In FreeBSD 13 CPU_NAND macro is CPU_ANDNOT */
+#ifdef CPU_NAND
 #define RTE_CPU_NOT(dst, src) do \
 { \
cpuset_t tmp; \
@@ -36,5 +39,14 @@ typedef cpuset_t rte_cpuset_t;
CPU_NAND(&tmp, src); \
CPU_COPY(&tmp, dst); \
 } while (0)
+#else
+#define RTE_CPU_NOT(dst, src) do \
+{ \
+   cpuset_t tmp; \
+   CPU_FILL(&tmp); \
+   CPU_ANDNOT(&tmp, src); \
+   CPU_COPY(&tmp, dst); \
+} while (0)
+#endif
 
 #endif /* _RTE_OS_H_ */
-- 
2.24.1

[dpdk-dev] [PATCH 0/2] Fix build with FreeBSD 13-CURRENT

[Bruce Richardson]

The FreeBSD CI system is reporting errors with DPDK on the current head
of the FreeBSD development branch for FreeBSD 13. Ahead of BSD 13's
release, we need to apply fixes to ensure DPDK continues to compile
on the various versions.

Bruce Richardson (2):
  eal/freebsd: update CPU macro for FreeBSD 13 support
  kernel/freebsd: update contigmem for FreeBSD 13

 kernel/freebsd/contigmem/contigmem.c|  7 +--
 lib/librte_eal/freebsd/eal/include/rte_os.h | 12 
 2 files changed, 17 insertions(+), 2 deletions(-)

-- 
2.24.1

[dpdk-dev] [PATCH 2/2] kernel/freebsd: update contigmem for FreeBSD 13

[Bruce Richardson]

FreeBSD 13 has changed the definition of vm_page_replace so we need
to have slightly different code paths around this function depending on
the BSD version.

Signed-off-by: Bruce Richardson 
---
 kernel/freebsd/contigmem/contigmem.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/kernel/freebsd/contigmem/contigmem.c 
b/kernel/freebsd/contigmem/contigmem.c
index 64e0a7fec..7ea0bc617 100644
--- a/kernel/freebsd/contigmem/contigmem.c
+++ b/kernel/freebsd/contigmem/contigmem.c
@@ -297,19 +297,22 @@ contigmem_cdev_pager_fault(vm_object_t object, 
vm_ooffset_t offset, int prot,
VM_OBJECT_WLOCK(object);
vm_page_updatefake(page, paddr, memattr);
} else {
-   vm_page_t mret;
/*
 * Replace the passed in reqpage page with our own fake page and
 * free up the original page.
 */
page = vm_page_getfake(paddr, memattr);
VM_OBJECT_WLOCK(object);
-   mret = vm_page_replace(page, object, (*mres)->pindex);
+#if __FreeBSD__ >= 13
+   vm_page_replace(page, object, (*mres)->pindex, *mres);
+#else
+   vm_page_t mret = vm_page_replace(page, object, (*mres)->pindex);
KASSERT(mret == *mres,
("invalid page replacement, old=%p, ret=%p", *mres, mret));
vm_page_lock(mret);
vm_page_free(mret);
vm_page_unlock(mret);
+#endif
*mres = page;
}
 
-- 
2.24.1

Re: [dpdk-dev] [PATCH v2 01/11] examples/l3fwd: add framework for event device

[Ananyev, Konstantin]

> Add framework to enable event device as a producer of packets.
> To switch between event mode and poll mode the following options
> have been added:
>   `--mode="eventdev"` or `--mode="poll"`
> Also, allow the user to select the schedule type to be either
> RTE_SCHED_TYPE_ORDERED, RTE_SCHED_TYPE_ATOMIC or RTE_SCHED_TYPE_PARALLEL
> through:
>   `--eventq-sched="ordered"` or `--eventq-sched="atomic"` or
>   `--eventq-sched="parallel"`
> 
> Poll mode is still the default operation mode.
> 
> Signed-off-by: Sunil Kumar Kori 
> ---
>  examples/l3fwd/Makefile  |  2 +-
>  examples/l3fwd/l3fwd.h   |  6 +++
>  examples/l3fwd/l3fwd_event.c | 75 
>  examples/l3fwd/l3fwd_event.h | 54 ++
>  examples/l3fwd/main.c| 41 +---
>  examples/l3fwd/meson.build   |  4 +-
>  6 files changed, 174 insertions(+), 8 deletions(-)
>  create mode 100644 examples/l3fwd/l3fwd_event.c
>  create mode 100644 examples/l3fwd/l3fwd_event.h
> 
> diff --git a/examples/l3fwd/Makefile b/examples/l3fwd/Makefile
> index b2dbf2607..c892b867b 100644
> --- a/examples/l3fwd/Makefile
> +++ b/examples/l3fwd/Makefile
> @@ -5,7 +5,7 @@
>  APP = l3fwd
> 
>  # all source are stored in SRCS-y
> -SRCS-y := main.c l3fwd_lpm.c l3fwd_em.c
> +SRCS-y := main.c l3fwd_lpm.c l3fwd_em.c l3fwd_event.c
> 
>  # Build using pkg-config variables if possible
>  ifeq ($(shell pkg-config --exists libdpdk && echo 0),0)
> diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
> index 293fb1fa2..cd17a41b3 100644
> --- a/examples/l3fwd/l3fwd.h
> +++ b/examples/l3fwd/l3fwd.h
> @@ -5,6 +5,9 @@
>  #ifndef __L3_FWD_H__
>  #define __L3_FWD_H__
> 
> +#include 
> +

Why do we need it here?

> +#include 
>  #include 
> 
>  #define DO_RFC_1812_CHECKS
> @@ -169,6 +172,9 @@ is_valid_ipv4_pkt(struct rte_ipv4_hdr *pkt, uint32_t 
> link_len)
>  }
>  #endif /* DO_RFC_1812_CHECKS */
> 
> +void
> +print_usage(const char *prgname);
> +
>  /* Function pointers for LPM or EM functionality. */
>  void
>  setup_lpm(const int socketid);
> diff --git a/examples/l3fwd/l3fwd_event.c b/examples/l3fwd/l3fwd_event.c
> new file mode 100644
> index 0..3892720be
> --- /dev/null
> +++ b/examples/l3fwd/l3fwd_event.c
> @@ -0,0 +1,75 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2019 Marvell International Ltd.
> + */
> +
> +#include 
> +#include 
> +
> +#include "l3fwd.h"
> +#include "l3fwd_event.h"
> +
> +static void
> +parse_mode(const char *optarg)
> +{
> + struct l3fwd_event_resources *evt_rsrc = l3fwd_get_eventdev_rsrc();
> +
> + if (!strncmp(optarg, "poll", 4))

That looks a bit clumsy and error-prone.
Just strcmp(optarg, "poll") seems enough here.
Same for other similar places.

> + evt_rsrc->enabled = false;
> + else if (!strncmp(optarg, "eventdev", 8))
> + evt_rsrc->enabled = true;
> +}
> +
> +static void
> +parse_eventq_sync(const char *optarg)
> +{
> + struct l3fwd_event_resources *evt_rsrc = l3fwd_get_eventdev_rsrc();
> +
> + if (!strncmp(optarg, "ordered", 7))
> + evt_rsrc->sched_type = RTE_SCHED_TYPE_ORDERED;
> + if (!strncmp(optarg, "atomic", 6))
> + evt_rsrc->sched_type = RTE_SCHED_TYPE_ATOMIC;
> + if (!strncmp(optarg, "parallel", 8))
> + evt_rsrc->sched_type = RTE_SCHED_TYPE_PARALLEL;
> +}
> +
> +static void
> +l3fwd_parse_eventdev_args(char **argv, int argc)
> +{
> + const struct option eventdev_lgopts[] = {
> + {CMD_LINE_OPT_MODE, 1, 0, CMD_LINE_OPT_MODE_NUM},
> + {CMD_LINE_OPT_EVENTQ_SYNC, 1, 0, CMD_LINE_OPT_EVENTQ_SYNC_NUM},
> + {NULL, 0, 0, 0}
> + };
> + char *prgname = argv[0];
> + char **argvopt = argv;
> + int32_t option_index;
> + int32_t opt;
> +
> + while ((opt = getopt_long(argc, argvopt, "", eventdev_lgopts,
> + &option_index)) != EOF) {
> + switch (opt) {
> + case CMD_LINE_OPT_MODE_NUM:
> + parse_mode(optarg);
> + break;
> +
> + case CMD_LINE_OPT_EVENTQ_SYNC_NUM:
> + parse_eventq_sync(optarg);
> + break;
> +
> + default:
> + print_usage(prgname);
> + exit(1);
> + }
> + }
> +}
> +
> +void
> +l3fwd_event_resource_setup(void)
> +{
> + struct l3fwd_event_resources *evt_rsrc = l3fwd_get_eventdev_rsrc();
> +
> + /* Parse eventdev command line options */
> + l3fwd_parse_eventdev_args(evt_rsrc->args, evt_rsrc->nb_args);
> + if (!evt_rsrc->enabled)
> + return;
> +}
> diff --git a/examples/l3fwd/l3fwd_event.h b/examples/l3fwd/l3fwd_event.h
> new file mode 100644
> index 0..c95296c38
> --- /dev/null
> +++ b/examples/l3fwd/l3fwd_event.h
> @@ -0,0 +1,54 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2019 Marvell International Ltd.
> + 

Re: [dpdk-dev] [PATCH v2 07/11] examples/l3fwd: add service core setup based on caps

[Ananyev, Konstantin]

> diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
> index 20df12748..69d212bc2 100644
> --- a/examples/l3fwd/main.c
> +++ b/examples/l3fwd/main.c
> @@ -826,6 +826,93 @@ prepare_ptype_parser(uint16_t portid, uint16_t queueid)
>   return 0;
>  }
> 
> +static inline int
> +l3fwd_service_enable(uint32_t service_id)
> +{
> + uint8_t min_service_count = UINT8_MAX;
> + uint32_t slcore_array[RTE_MAX_LCORE];
> + unsigned int slcore = 0;
> + uint8_t service_count;
> + int32_t slcore_count;
> +
> + if (!rte_service_lcore_count())
> + return -ENOENT;
> +
> + slcore_count = rte_service_lcore_list(slcore_array, RTE_MAX_LCORE);
> + if (slcore_count < 0)
> + return -ENOENT;
> + /* Get the core which has least number of services running. */
> + while (slcore_count--) {
> + /* Reset default mapping */
> + rte_service_map_lcore_set(service_id,
> + slcore_array[slcore_count], 0);
> + service_count = rte_service_lcore_count_services(
> + slcore_array[slcore_count]);
> + if (service_count < min_service_count) {
> + slcore = slcore_array[slcore_count];
> + min_service_count = service_count;
> + }
> + }
> + if (rte_service_map_lcore_set(service_id, slcore, 1))
> + return -ENOENT;
> + rte_service_lcore_start(slcore);
> +
> + return 0;
> +}
> +
> +static void
> +l3fwd_event_service_setup(void)
> +{
> + struct l3fwd_event_resources *evt_rsrc = l3fwd_get_eventdev_rsrc();
> + struct rte_event_dev_info evdev_info;
> + uint32_t service_id, caps;
> + int ret, i;
> +
> + rte_event_dev_info_get(evt_rsrc->event_d_id, &evdev_info);
> + if (evdev_info.event_dev_cap  & RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED) {
> + ret = rte_event_dev_service_id_get(evt_rsrc->event_d_id,
> + &service_id);
> + if (ret != -ESRCH && ret != 0)
> + rte_exit(EXIT_FAILURE,
> +  "Error in starting eventdev service\n");
> + l3fwd_service_enable(service_id);
> + }
> +
> + for (i = 0; i < evt_rsrc->rx_adptr.nb_rx_adptr; i++) {
> + ret = rte_event_eth_rx_adapter_caps_get(evt_rsrc->event_d_id,
> + evt_rsrc->rx_adptr.rx_adptr[i], &caps);
> + if (ret < 0)
> + rte_exit(EXIT_FAILURE,
> +  "Failed to get Rx adapter[%d] caps\n",
> +  evt_rsrc->rx_adptr.rx_adptr[i]);
> + ret = rte_event_eth_rx_adapter_service_id_get(
> + evt_rsrc->event_d_id,
> + &service_id);
> + if (ret != -ESRCH && ret != 0)
> + rte_exit(EXIT_FAILURE,
> +  "Error in starting Rx adapter[%d] service\n",
> +  evt_rsrc->rx_adptr.rx_adptr[i]);
> + l3fwd_service_enable(service_id);
> + }
> +
> + for (i = 0; i < evt_rsrc->tx_adptr.nb_tx_adptr; i++) {
> + ret = rte_event_eth_tx_adapter_caps_get(evt_rsrc->event_d_id,
> + evt_rsrc->tx_adptr.tx_adptr[i], &caps);
> + if (ret < 0)
> + rte_exit(EXIT_FAILURE,
> +  "Failed to get Rx adapter[%d] caps\n",
> +  evt_rsrc->tx_adptr.tx_adptr[i]);
> + ret = rte_event_eth_tx_adapter_service_id_get(
> + evt_rsrc->event_d_id,
> + &service_id);
> + if (ret != -ESRCH && ret != 0)
> + rte_exit(EXIT_FAILURE,
> +  "Error in starting Rx adapter[%d] service\n",
> +  evt_rsrc->tx_adptr.tx_adptr[i]);
> + l3fwd_service_enable(service_id);
> + }
> +}
> +
>  int
>  main(int argc, char **argv)
>  {
> @@ -869,6 +956,8 @@ main(int argc, char **argv)
>   evt_rsrc->port_mask = enabled_port_mask;
>   /* Configure eventdev parameters if user has requested */
>   l3fwd_event_resource_setup(&port_conf);
> + if (evt_rsrc->enabled)
> + goto skip_port_config;

Please try to avoid introducing more gotos.
If init code below is poll mode specific, let's move it int a separate function.
Then we can have something like:
If (evt_rsrc->enabled)  {
  ...
  ret =  l3fwd_event_resource_setup(...);
  l3fwd_event_service_setup();
 ...
} else 
   ret = l3fwd_poll_resource_setup(...);

...

> 
>   if (check_lcore_params() < 0)
>   rte_exit(EXIT_FAILURE, "check_lcore_params failed\n");
> @@ -1054,6 +1143,7 @@ main(int argc, char **argv)
>   }
>   }
> 
> +skip_port_config:
>   printf("\n");
> 
>   /* start ports */
> @@ -1083,6 +1173,9 @@ main(int argc, char **argv)
>   

Re: [dpdk-dev] [PATCH v2 08/11] examples/l3fwd: add event lpm main loop

[Ananyev, Konstantin]

> Add lpm main loop for handling events based on capabilities of the
> event device.
> 
> Signed-off-by: Pavan Nikhilesh 
> ---
>  examples/l3fwd/l3fwd.h   |   9 ++
>  examples/l3fwd/l3fwd_event.c |   9 ++
>  examples/l3fwd/l3fwd_event.h |   5 +
>  examples/l3fwd/l3fwd_lpm.c   | 231 +++
>  examples/l3fwd/main.c|  10 +-
>  5 files changed, 260 insertions(+), 4 deletions(-)
> 
> diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
> index 6d16cde74..8f2e4be23 100644
> --- a/examples/l3fwd/l3fwd.h
> +++ b/examples/l3fwd/l3fwd.h
> @@ -212,6 +212,15 @@ em_main_loop(__attribute__((unused)) void *dummy);
>  int
>  lpm_main_loop(__attribute__((unused)) void *dummy);
> 
> +int
> +lpm_event_main_loop_tx_d(__attribute__((unused)) void *dummy);
> +int
> +lpm_event_main_loop_tx_d_burst(__attribute__((unused)) void *dummy);
> +int
> +lpm_event_main_loop_tx_q(__attribute__((unused)) void *dummy);
> +int
> +lpm_event_main_loop_tx_q_burst(__attribute__((unused)) void *dummy);

No need to add unused attribute in function declaration.
BTW, if all event_loop_cb functions don't use parameter, why just not
make them 'typedef int (*event_loop_cb)(void)'?

> +
>  /* Return ipv4/ipv6 fwd lookup struct for LPM or EM. */
>  void *
>  em_get_ipv4_l3fwd_lookup_struct(const int socketid);
> diff --git a/examples/l3fwd/l3fwd_event.c b/examples/l3fwd/l3fwd_event.c
> index 0e796f003..c7de046e3 100644
> --- a/examples/l3fwd/l3fwd_event.c
> +++ b/examples/l3fwd/l3fwd_event.c
> @@ -235,6 +235,12 @@ void
>  l3fwd_event_resource_setup(struct rte_eth_conf *port_conf)
>  {
>   struct l3fwd_event_resources *evt_rsrc = l3fwd_get_eventdev_rsrc();
> + const event_loop_cb lpm_event_loop[2][2] = {
> + [0][0] = lpm_event_main_loop_tx_d,
> + [0][1] = lpm_event_main_loop_tx_d_burst,
> + [1][0] = lpm_event_main_loop_tx_q,
> + [1][1] = lpm_event_main_loop_tx_q_burst,
> + };
>   uint32_t event_queue_cfg;
>   int ret;
> 
> @@ -268,4 +274,7 @@ l3fwd_event_resource_setup(struct rte_eth_conf *port_conf)
>   ret = rte_event_dev_start(evt_rsrc->event_d_id);
>   if (ret < 0)
>   rte_exit(EXIT_FAILURE, "Error in starting eventdev");
> +
> + evt_rsrc->ops.lpm_event_loop = lpm_event_loop[evt_rsrc->tx_mode_q]
> +[evt_rsrc->has_burst];
>  }
> diff --git a/examples/l3fwd/l3fwd_event.h b/examples/l3fwd/l3fwd_event.h
> index 9d8bd5a36..fcc0ce51a 100644
> --- a/examples/l3fwd/l3fwd_event.h
> +++ b/examples/l3fwd/l3fwd_event.h
> @@ -14,6 +14,11 @@
> 
>  #include "l3fwd.h"
> 
> +#define L3FWD_EVENT_SINGLE 0x1
> +#define L3FWD_EVENT_BURST  0x2
> +#define L3FWD_EVENT_TX_DIRECT  0x4
> +#define L3FWD_EVENT_TX_ENQ 0x8
> +
>  #define CMD_LINE_OPT_MODE "mode"
>  #define CMD_LINE_OPT_EVENTQ_SYNC "eventq-sched"
> 
> diff --git a/examples/l3fwd/l3fwd_lpm.c b/examples/l3fwd/l3fwd_lpm.c
> index 349de2703..c4669d6d5 100644
> --- a/examples/l3fwd/l3fwd_lpm.c
> +++ b/examples/l3fwd/l3fwd_lpm.c
> @@ -28,6 +28,7 @@
>  #include 
> 
>  #include "l3fwd.h"
> +#include "l3fwd_event.h"
> 
>  struct ipv4_l3fwd_lpm_route {
>   uint32_t ip;
> @@ -254,6 +255,236 @@ lpm_main_loop(__attribute__((unused)) void *dummy)
>   return 0;
>  }
> 
> +static __rte_always_inline void
> +lpm_event_loop_single(struct l3fwd_event_resources *evt_rsrc,
> + const uint8_t flags)
> +{
> + const int event_p_id = l3fwd_get_free_event_port(evt_rsrc);
> + const uint8_t tx_q_id = evt_rsrc->evq.event_q_id[
> + evt_rsrc->evq.nb_queues - 1];
> + const uint8_t event_d_id = evt_rsrc->event_d_id;
> + struct lcore_conf *lconf;
> + unsigned int lcore_id;
> + struct rte_event ev;
> +
> + if (event_p_id < 0)
> + return;
> +
> + lcore_id = rte_lcore_id();
> + lconf = &lcore_conf[lcore_id];
> +
> + RTE_LOG(INFO, L3FWD, "entering %s on lcore %u\n", __func__, lcore_id);
> + while (!force_quit) {
> + if (!rte_event_dequeue_burst(event_d_id, event_p_id, &ev, 1, 0))
> + continue;
> +
> + struct rte_mbuf *mbuf = ev.mbuf;
> + mbuf->port = lpm_get_dst_port(lconf, mbuf, mbuf->port);
> +
> +#if defined RTE_ARCH_X86 || defined RTE_MACHINE_CPUFLAG_NEON \
> + || defined RTE_ARCH_PPC_64
> + process_packet(mbuf, &mbuf->port);
> +#else
> +
> + struct rte_ether_hdr *eth_hdr = rte_pktmbuf_mtod(mbuf,
> + struct rte_ether_hdr *);
> +#ifdef DO_RFC_1812_CHECKS
> + struct rte_ipv4_hdr *ipv4_hdr;
> + if (RTE_ETH_IS_IPV4_HDR(mbuf->packet_type)) {
> + /* Handle IPv4 headers.*/
> + ipv4_hdr = rte_pktmbuf_mtod_offset(mbuf,
> + struct rte_ipv4_hdr *,
> + sizeof(struct rte_ether_hdr));
>

Re: [dpdk-dev] [PATCH v2 09/11] examples/l3fwd: add event em main loop

[Ananyev, Konstantin]

> Add em main loop for handling events based on capabilities of the
> event device.
> 
> Signed-off-by: Pavan Nikhilesh 
> ---
>  examples/l3fwd/l3fwd.h   |  10 ++
>  examples/l3fwd/l3fwd_em.c| 177 +++
>  examples/l3fwd/l3fwd_em.h| 159 +---
>  examples/l3fwd/l3fwd_em_hlm.h| 131 
>  examples/l3fwd/l3fwd_em_sequential.h |  26 
>  examples/l3fwd/l3fwd_event.c |   9 ++
>  examples/l3fwd/main.c|   5 +-
>  7 files changed, 470 insertions(+), 47 deletions(-)
> 
> diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
> index 8f2e4be23..2d02fa731 100644
> --- a/examples/l3fwd/l3fwd.h
> +++ b/examples/l3fwd/l3fwd.h
> @@ -221,6 +221,16 @@ lpm_event_main_loop_tx_q(__attribute__((unused)) void 
> *dummy);
>  int
>  lpm_event_main_loop_tx_q_burst(__attribute__((unused)) void *dummy);
> 
> +int
> +em_event_main_loop_tx_d(__attribute__((unused)) void *dummy);
> +int
> +em_event_main_loop_tx_d_burst(__attribute__((unused)) void *dummy);
> +int
> +em_event_main_loop_tx_q(__attribute__((unused)) void *dummy);
> +int
> +em_event_main_loop_tx_q_burst(__attribute__((unused)) void *dummy);

Same question as for lpm: if your functions don't need params,
why not to define them as ones without params? 

> +
> +
>  /* Return ipv4/ipv6 fwd lookup struct for LPM or EM. */
>  void *
>  em_get_ipv4_l3fwd_lookup_struct(const int socketid);

Re: [dpdk-dev] [PATCH v2 10/11] examples/l3fwd: add graceful teardown for eventdevice

[Ananyev, Konstantin]

> Add graceful teardown that addresses both event mode and poll mode.
> 
> Signed-off-by: Pavan Nikhilesh 
> ---
>  examples/l3fwd/main.c | 49 ++-
>  1 file changed, 34 insertions(+), 15 deletions(-)
> 
> diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
> index 0ae64dd41..68998f42c 100644
> --- a/examples/l3fwd/main.c
> +++ b/examples/l3fwd/main.c
> @@ -920,7 +920,7 @@ main(int argc, char **argv)
>   struct lcore_conf *qconf;
>   struct rte_eth_dev_info dev_info;
>   struct rte_eth_txconf *txconf;
> - int ret;
> + int i, ret;
>   unsigned nb_ports;
>   uint16_t queueid, portid;
>   unsigned lcore_id;
> @@ -1195,27 +1195,46 @@ main(int argc, char **argv)
>   }
>   }
> 
> -
>   check_all_ports_link_status(enabled_port_mask);
> 
>   ret = 0;
>   /* launch per-lcore init on every lcore */
>   rte_eal_mp_remote_launch(l3fwd_lkp.main_loop, NULL, CALL_MASTER);
> - RTE_LCORE_FOREACH_SLAVE(lcore_id) {
> - if (rte_eal_wait_lcore(lcore_id) < 0) {
> - ret = -1;
> - break;
> + if (evt_rsrc->enabled) {
> + for (i = 0; i < evt_rsrc->rx_adptr.nb_rx_adptr; i++)
> + rte_event_eth_rx_adapter_stop(
> + evt_rsrc->rx_adptr.rx_adptr[i]);
> + for (i = 0; i < evt_rsrc->tx_adptr.nb_tx_adptr; i++)
> + rte_event_eth_tx_adapter_stop(
> + evt_rsrc->tx_adptr.tx_adptr[i]);
> +
> + RTE_ETH_FOREACH_DEV(portid) {
> + if ((enabled_port_mask & (1 << portid)) == 0)
> + continue;
> + rte_eth_dev_stop(portid);
>   }
> - }
> 
> - /* stop ports */
> - RTE_ETH_FOREACH_DEV(portid) {
> - if ((enabled_port_mask & (1 << portid)) == 0)
> - continue;
> - printf("Closing port %d...", portid);
> - rte_eth_dev_stop(portid);
> - rte_eth_dev_close(portid);
> - printf(" Done\n");

Why to stop ports *before* making sure all lcores are stopped?
Shouldn't that peace of code be identical for both poll and event mode?
Something like:
rte_eal_mp_wait_lcore();

RTE_ETH_FOREACH_DEV(portid) {
if ((enabled_port_mask & (1 << portid)) == 0)
continue;
rte_eth_dev_stop(portid);
rte_eth_dev_close(portid);
}
?

> + rte_eal_mp_wait_lcore();
> + RTE_ETH_FOREACH_DEV(portid) {
> + if ((enabled_port_mask & (1 << portid)) == 0)
> + continue;
> + rte_eth_dev_close(portid);
> + }
> +
> + rte_event_dev_stop(evt_rsrc->event_d_id);
> + rte_event_dev_close(evt_rsrc->event_d_id);
> +
> + } else {
> + rte_eal_mp_wait_lcore();
> +
> + RTE_ETH_FOREACH_DEV(portid) {
> + if ((enabled_port_mask & (1 << portid)) == 0)
> + continue;
> + printf("Closing port %d...", portid);
> + rte_eth_dev_stop(portid);
> + rte_eth_dev_close(portid);
> + printf(" Done\n");
> + }
>   }
>   printf("Bye...\n");
> 
> --
> 2.17.1

Re: [dpdk-dev] [PATCH v2] build: explicitly enable sse4 for meson builds

[Bruce Richardson]

+stable

This patch is probably worthwhile taking into 19.11 and 18.11 branches to
reduce chances of failures on CI of stable trees.

On Mon, Dec 23, 2019 at 10:38:40AM +, Bruce Richardson wrote:
> If the compiler does not recognise the specific CPU when building with the
> default "native" machine type, sse4.2 instructions can be missing, causing
> a build error. Rather than advising the user to change the machine type,
> we can just turn on SSE4.2 directly. This can prevent issues with running
> automated tests with older compilers/distros on newer hardware.
> 
Cc: sta...@dpdk.org
> Signed-off-by: Bruce Richardson 
> ---
> V2: insert missing quotes around "-msse4"
> ---
>  config/x86/meson.build | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/config/x86/meson.build b/config/x86/meson.build
> index 8b0fa3e6f..adc857ba2 100644
> --- a/config/x86/meson.build
> +++ b/config/x86/meson.build
> @@ -15,11 +15,9 @@ if not is_windows
>  endif
>  
>  # we require SSE4.2 for DPDK
> -sse_errormsg = '''SSE4.2 instruction set is required for DPDK.
> -Please set the machine type to "nehalem" or "corei7" or higher value'''
> -
>  if cc.get_define('__SSE4_2__', args: machine_args) == ''
> - error(sse_errormsg)
> + message('SSE 4.2 not enabled by default, explicitly enabling')
> + machine_args += '-msse4'
>  endif
>  
>  base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
> -- 
> 2.24.1
> 

[dpdk-dev] [PATCH] build: skip processing docs folder if docs disabled

[Bruce Richardson]

While each target is set to be ignored if the docs are disabled in the
meson build, there is little reason to process the docs folder at all.

Signed-off-by: Bruce Richardson 
---
 doc/meson.build | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/meson.build b/doc/meson.build
index c5410d85d..c49ec8476 100644
--- a/doc/meson.build
+++ b/doc/meson.build
@@ -1,6 +1,10 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2018 Luca Boccassi 
 
+if not get_option('enable_docs')
+   subdir_done()
+endif
+
 doc_targets = []
 doc_target_names = []
 subdir('api')
-- 
2.24.1

Re: [dpdk-dev] [PATCH v2] build: explicitly enable sse4 for meson builds

[David Marchand]

On Fri, Jan 3, 2020 at 2:55 PM Bruce Richardson
 wrote:
>
> +stable
>
> This patch is probably worthwhile taking into 19.11 and 18.11 branches to
> reduce chances of failures on CI of stable trees.

+1

>
> On Mon, Dec 23, 2019 at 10:38:40AM +, Bruce Richardson wrote:
> > If the compiler does not recognise the specific CPU when building with the
> > default "native" machine type, sse4.2 instructions can be missing, causing
> > a build error. Rather than advising the user to change the machine type,
> > we can just turn on SSE4.2 directly. This can prevent issues with running
> > automated tests with older compilers/distros on newer hardware.
> >
> Cc: sta...@dpdk.org
> > Signed-off-by: Bruce Richardson 

Acked-by: David Marchand 

Applied, thanks.


--
David Marchand

[dpdk-dev] [PATCH v2] net/iavf/base: change the base code as common

[Haiyue Wang]

Change the iavf base code as driver common library, it is used by iavf
PMD now, and it can be used by i40evf PMD in the future.

Signed-off-by: Haiyue Wang 
---
v2: update the commit message, and rename the iavf_main.c to iavf_impl.c

 drivers/common/Makefile   |   5 +
 drivers/common/iavf/Makefile  |  28 +
 drivers/{net/iavf/base => common/iavf}/README |   1 +
 .../iavf/base => common/iavf}/iavf_adminq.c   |   0
 .../iavf/base => common/iavf}/iavf_adminq.h   |   0
 .../base => common/iavf}/iavf_adminq_cmd.h|   0
 .../iavf/base => common/iavf}/iavf_alloc.h|   0
 .../iavf/base => common/iavf}/iavf_common.c   |   0
 .../iavf/base => common/iavf}/iavf_devids.h   |   0
 drivers/common/iavf/iavf_impl.c   | 114 ++
 .../iavf/base => common/iavf}/iavf_osdep.h|  50 ++--
 .../base => common/iavf}/iavf_prototype.h |   0
 .../iavf/base => common/iavf}/iavf_register.h |   0
 .../iavf/base => common/iavf}/iavf_status.h   |   0
 .../iavf/base => common/iavf}/iavf_type.h |   0
 drivers/common/iavf/meson.build   |  10 ++
 .../common/iavf/rte_common_iavf_version.map   |  12 ++
 .../{net/iavf/base => common/iavf}/virtchnl.h |   0
 drivers/common/meson.build|   2 +-
 drivers/net/iavf/Makefile |  23 +---
 drivers/net/iavf/base/meson.build |  23 
 drivers/net/iavf/iavf.h   |   6 +-
 drivers/net/iavf/iavf_ethdev.c|  83 -
 drivers/net/iavf/iavf_rxtx.c  |   3 -
 drivers/net/iavf/iavf_rxtx_vec_avx2.c |   1 -
 drivers/net/iavf/iavf_rxtx_vec_sse.c  |   2 -
 drivers/net/iavf/iavf_vchnl.c |   5 -
 drivers/net/iavf/meson.build  |   4 +-
 mk/rte.app.mk |   4 +
 29 files changed, 192 insertions(+), 184 deletions(-)
 create mode 100644 drivers/common/iavf/Makefile
 rename drivers/{net/iavf/base => common/iavf}/README (96%)
 rename drivers/{net/iavf/base => common/iavf}/iavf_adminq.c (100%)
 rename drivers/{net/iavf/base => common/iavf}/iavf_adminq.h (100%)
 rename drivers/{net/iavf/base => common/iavf}/iavf_adminq_cmd.h (100%)
 rename drivers/{net/iavf/base => common/iavf}/iavf_alloc.h (100%)
 rename drivers/{net/iavf/base => common/iavf}/iavf_common.c (100%)
 rename drivers/{net/iavf/base => common/iavf}/iavf_devids.h (100%)
 create mode 100644 drivers/common/iavf/iavf_impl.c
 rename drivers/{net/iavf/base => common/iavf}/iavf_osdep.h (75%)
 rename drivers/{net/iavf/base => common/iavf}/iavf_prototype.h (100%)
 rename drivers/{net/iavf/base => common/iavf}/iavf_register.h (100%)
 rename drivers/{net/iavf/base => common/iavf}/iavf_status.h (100%)
 rename drivers/{net/iavf/base => common/iavf}/iavf_type.h (100%)
 create mode 100644 drivers/common/iavf/meson.build
 create mode 100644 drivers/common/iavf/rte_common_iavf_version.map
 rename drivers/{net/iavf/base => common/iavf}/virtchnl.h (100%)
 delete mode 100644 drivers/net/iavf/base/meson.build

diff --git a/drivers/common/Makefile b/drivers/common/Makefile
index 1ff033bba..3254c5274 100644
--- a/drivers/common/Makefile
+++ b/drivers/common/Makefile
@@ -30,4 +30,9 @@ ifeq ($(CONFIG_RTE_LIBRTE_COMMON_DPAAX),y)
 DIRS-y += dpaax
 endif
 
+IAVF-y := $(CONFIG_RTE_LIBRTE_IAVF_PMD)
+ifneq (,$(findstring y,$(IAVF-y)))
+DIRS-y += iavf
+endif
+
 include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/drivers/common/iavf/Makefile b/drivers/common/iavf/Makefile
new file mode 100644
index 0..43383e376
--- /dev/null
+++ b/drivers/common/iavf/Makefile
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_common_iavf.a
+
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -Wno-pointer-arith
+CFLAGS += -Wno-cast-qual
+
+EXPORT_MAP := rte_common_iavf_version.map
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-y += iavf_adminq.c
+SRCS-y += iavf_common.c
+SRCS-y += iavf_impl.c
+
+LDLIBS += -lrte_eal
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/net/iavf/base/README b/drivers/common/iavf/README
similarity index 96%
rename from drivers/net/iavf/base/README
rename to drivers/common/iavf/README
index e8c49c36f..b78e89bee 100644
--- a/drivers/net/iavf/base/README
+++ b/drivers/common/iavf/README
@@ -17,3 +17,4 @@ NOTE: The source code in this directory should not be 
modified apart from
 the following file(s):
 
 iavf_osdep.h
+iavf_impl.c
diff --git a/drivers/net/iavf/base/iavf_adminq.c 
b/drivers/common/iavf/iavf_adminq.c
similarity index 100%
rename from drivers/net/iavf/base/iavf_adminq.c
rename to drivers/common/iavf/iavf_adminq.c
diff --git a/drivers/net/iavf/base/iavf_adminq.h 
b/drivers/common/iavf/iavf_adminq.h
similarity index 100%
rename from drivers/net/iavf/base/iavf_adminq.h
rename to drivers/common/iavf/iavf_adminq.h
diff --git 

[dpdk-dev] [PATCH 0/5] Update docs for installing on FreeBSD

[Bruce Richardson]

Update the FreeBSD GSG guide to cover:

* installing from package as well as via ports collection
* building and installing manually via meson and ninja
* building examples using the pkg-config file, since both the port/pkg
  and building from source use meson.
* other general tidy-up.

Bruce Richardson (5):
  doc: update intro to FreeBSD GSG
  doc: document installing from FreeBSD package
  doc: add meson install instructions for FreeBSD
  doc: update section on loading FreeBSD kernel modules
  doc: update documentation on build and running FreeBSD apps

 doc/guides/freebsd_gsg/build_dpdk.rst | 229 ++
 doc/guides/freebsd_gsg/build_sample_apps.rst  | 118 +++--
 doc/guides/freebsd_gsg/install_from_ports.rst |  73 +++---
 doc/guides/freebsd_gsg/intro.rst  |   7 +-
 4 files changed, 135 insertions(+), 292 deletions(-)

-- 
2.24.1

[dpdk-dev] [PATCH 2/5] doc: document installing from FreeBSD package

[Bruce Richardson]

Update the FreeBSD GSG to cover installing from the pre-built package as
well as installing from a port.

Also, since the port is now based on meson, update the instructions for
compiling and running the example applications.

Signed-off-by: Bruce Richardson 
---
Note: at this stage, DPDK is in the "latest" package snapshot, but has
not yet made it's way into the quarterly snapshot used by default by
stable releases. This is hopefully only a matter of time.
---
 doc/guides/freebsd_gsg/install_from_ports.rst | 73 +--
 1 file changed, 36 insertions(+), 37 deletions(-)

diff --git a/doc/guides/freebsd_gsg/install_from_ports.rst 
b/doc/guides/freebsd_gsg/install_from_ports.rst
index 29f16cc6c..36dc4a417 100644
--- a/doc/guides/freebsd_gsg/install_from_ports.rst
+++ b/doc/guides/freebsd_gsg/install_from_ports.rst
@@ -7,29 +7,31 @@ Installing DPDK from the Ports Collection
 =
 
 The easiest way to get up and running with the DPDK on FreeBSD is to
-install it from the ports collection. Details of getting and using the ports
-collection are documented in the
-`FreeBSD Handbook 
`_.
+install it using the FreeBSD `pkg` utility or from the ports collection.
+Details of installing applications from packages or the ports collection are 
documented in the
+`FreeBSD Handbook 
`_,
+chapter `Installing Applications: Packages and Ports 
`_.
 
-Installing the DPDK FreeBSD Port
-
+.. note::
 
-On a system with the ports collection installed in ``/usr/ports``, the DPDK
-can be installed using the commands:
+   Please ensure that the latest patches are applied to third party libraries
+   and software to avoid any known vulnerabilities.
 
-.. code-block:: console
 
-cd /usr/ports/net/dpdk
+Installing the DPDK Package for FreeBSD
+---
 
-make install
+DPDK can be installed on FreeBSD using the command::
+
+   pkg install dpdk
 
-After the installation of the DPDK port, instructions will be printed on
+After the installation of the DPDK package, instructions will be printed on
 how to install the kernel modules required to use the DPDK. A more
 complete version of these instructions can be found in the sections
 :ref:`loading_contigmem` and :ref:`loading_nic_uio`. Normally, lines like
 those below would be added to the file ``/boot/loader.conf``.
 
-.. code-block:: console
+.. code-block:: shell
 
 # Reserve 2 x 1G blocks of contiguous memory using contigmem driver:
 hw.contigmem.num_buffers=2
@@ -40,24 +42,32 @@ those below would be added to the file 
``/boot/loader.conf``.
 hw.nic_uio.bdfs="2:0:0,2:0:1"
 nic_uio_load="YES"
 
-.. note::
 
-   Please ensure that the latest patches are applied to third party libraries
-   and software to avoid any known vulnerabilities.
+Installing the DPDK FreeBSD Port
+
+
+If so desired, the user can install DPDK using the ports collection rather 
than from
+a pre-compiled binary package.
+On a system with the ports collection installed in ``/usr/ports``, the DPDK
+can be installed using the commands::
+
+cd /usr/ports/net/dpdk
+
+make install
 
 
 Compiling and Running the Example Applications
 --
 
 When the DPDK has been installed from the ports collection it installs
-its example applications in ``/usr/local/share/dpdk/examples`` - also 
accessible via
-symlink as ``/usr/local/share/examples/dpdk``. These examples can be compiled 
and
-run as described in :ref:`compiling_sample_apps`. In this case, the required
-environmental variables should be set as below:
+its example applications in ``/usr/local/share/dpdk/examples``.
+These examples can be compiled and run as described in 
:ref:`compiling_sample_apps`.
 
-* ``RTE_SDK=/usr/local/share/dpdk``
+.. note::
 
-* ``RTE_TARGET=x86_64-native-freebsd-clang``
+   DPDK example applications must be complied using `gmake` rather than
+   BSD `make`. To detect the installed DPDK libraries, `pkg-config` should
+   also be installed on the system.
 
 .. note::
 
@@ -66,25 +76,18 @@ environmental variables should be set as below:
the instructions given in the next chapter, :ref:`building_from_source`
 
 An example application can therefore be copied to a user's home directory and
-compiled and run as below:
-
-.. code-block:: console
-
-export RTE_SDK=/usr/local/share/dpdk
-
-export RTE_TARGET=x86_64-native-freebsd-clang
+compiled and run as below, where we have 2 memory blocks of size 1G reserved
+via the contigmem module, and 4 NIC ports bound to the nic_uio module::
 
 cp -r /usr/local/share/dpdk/examples/helloworld .
 
 cd helloworld/
 
 gmake
-  CC main.o
-  LD helloworld
-  INSTALL-APP helloworl

[dpdk-dev] [PATCH 1/5] doc: update intro to FreeBSD GSG

[Bruce Richardson]

Update the introduction section note, to add in the fact that DPDK is now
packaged in FreeBSD, i.e. available as a pre-built binary package, as well
as being in the ports collection for manual building.

Signed-off-by: Bruce Richardson 
---
Note: at this stage, DPDK is in the "latest" package snapshot, but has
not yet made it's way into the quarterly snapshot used by default by
stable releases. This is hopefully only a matter of time.
---
 doc/guides/freebsd_gsg/intro.rst | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/doc/guides/freebsd_gsg/intro.rst b/doc/guides/freebsd_gsg/intro.rst
index e5611bca6..63160ce64 100644
--- a/doc/guides/freebsd_gsg/intro.rst
+++ b/doc/guides/freebsd_gsg/intro.rst
@@ -16,10 +16,9 @@ handbook is available from the FreeBSD Documentation Project:
 
 .. note::
 
-   The DPDK is now available as part of the FreeBSD ports collection.
-   Installing via the ports collection infrastructure is now the recommended
-   way to install the DPDK on FreeBSD, and is documented in the
-   next chapter, :ref:`install_from_ports`.
+   DPDK is now available as part of the FreeBSD ports collection and as a 
pre-built package.
+   Installing via the ports collection or FreeBSD `pkg` infrastructure is now 
the recommended
+   way to install DPDK on FreeBSD, and is documented in the next chapter, 
:ref:`install_from_ports`.
 
 Documentation Roadmap
 -
-- 
2.24.1

[dpdk-dev] [PATCH 3/5] doc: add meson install instructions for FreeBSD

[Bruce Richardson]

Update the FreeBSD GSG doc with instructions for installing using meson and
ninja rather than make.

Signed-off-by: Bruce Richardson 
Acked-by: Anatoly Burakov 
---
 doc/guides/freebsd_gsg/build_dpdk.rst | 164 +++---
 1 file changed, 40 insertions(+), 124 deletions(-)

diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst 
b/doc/guides/freebsd_gsg/build_dpdk.rst
index 7abd85aa5..c5d5379f6 100644
--- a/doc/guides/freebsd_gsg/build_dpdk.rst
+++ b/doc/guides/freebsd_gsg/build_dpdk.rst
@@ -6,147 +6,63 @@
 Compiling the DPDK Target from Source
 =
 
-System Requirements

+Prerequisites
+-
 
-The DPDK and its applications require the GNU make system (gmake)
-to build on FreeBSD. Optionally, gcc may also be used in place of clang
-to build the DPDK, in which case it too must be installed prior to
-compiling the DPDK. The installation of these tools is covered in this
-section.
+The following FreeBSD packages are required to build DPDK:
 
-Compiling the DPDK requires the FreeBSD kernel sources, which should be
-included during the installation of FreeBSD on the development platform.
-The DPDK also requires the use of FreeBSD ports to compile and function.
+* meson
+* ninja
+* pkgconf
 
-To use the FreeBSD ports system, it is required to update and extract the 
FreeBSD
-ports tree by issuing the following commands:
+These can be installed using (as root)::
 
-.. code-block:: console
-
-portsnap fetch
-portsnap extract
-
-If the environment requires proxies for external communication, these can be 
set
-using:
-
-.. code-block:: console
-
-setenv http_proxy :
-setenv ftp_proxy :
-
-The FreeBSD ports below need to be installed prior to building the DPDK.
-In general these can be installed using the following set of commands::
-
-   cd /usr/ports/
-
-   make config-recursive
-
-   make install
-
-   make clean
-
-Each port location can be found using::
-
-   whereis 
-
-The ports required and their locations are as follows:
-
-* dialog4ports: ``/usr/ports/ports-mgmt/dialog4ports``
-
-* GNU make(gmake): ``/usr/ports/devel/gmake``
-
-* coreutils: ``/usr/ports/sysutils/coreutils``
-
-For compiling and using the DPDK with gcc, the compiler must be installed
-from the ports collection:
-
-* gcc: version 4.9 is recommended ``/usr/ports/lang/gcc49``.
-  Ensure that ``CPU_OPTS`` is selected (default is OFF).
-
-When running the make config-recursive command, a dialog may be presented to 
the
-user. For the installation of the DPDK, the default options were used.
-
-.. note::
+  pkg install meson pkgconf
 
-To avoid multiple dialogs being presented to the user during make install,
-it is advisable before running the make install command to re-run the
-make config-recursive command until no more dialogs are seen.
+To compile the required kernel modules for memory management and working
+with physical NIC devices, the kernel sources for FreeBSD also
+need to be installed. If not already present on the system, these can be
+installed via commands like the following, for FreeBSD 12.1 on x86_64::
 
+  fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.1-RELEASE/src.txz
+  tar -C / -xJvf src.txz
 
-Install the DPDK and Browse Sources

+To enable the telemetry library in DPDK, the jansson library also needs to
+be installed, and can be installed via::
 
-First, uncompress the archive and move to the DPDK source directory:
+  pkg install jansson
 
-.. code-block:: console
-
-unzip DPDK-.zip
-cd DPDK-
-
-The DPDK is composed of several directories:
-
-*   lib: Source code of DPDK libraries
-
-*   app: Source code of DPDK applications (automatic tests)
-
-*   examples: Source code of DPDK applications
-
-*   config, buildtools, mk: Framework-related makefiles, scripts and 
configuration
-
-Installation of the DPDK Target Environments
-
-
-The format of a DPDK target is::
-
-   ARCH-MACHINE-EXECENV-TOOLCHAIN
-
-Where:
+Individual drivers may have additional requirements. Consult the relevant
+driver guide for any driver-specific requirements of interest.
 
-* ``ARCH`` is: ``x86_64``
+Building DPDK
+-
 
-* ``MACHINE`` is: ``native``
+The following commands can be used to build and install DPDK on a system.
+The final, install, step generally needs to be run as root::
 
-* ``EXECENV`` is: ``freebsd``
+  meson build
+  cd build
+  ninja
+  ninja install
 
-* ``TOOLCHAIN`` is: ``gcc`` | ``clang``
-
-The configuration files for the DPDK targets can be found in the DPDK/config
-directory in the form of::
-
-defconfig_ARCH-MACHINE-EXECENV-TOOLCHAIN
+This will install the DPDK libraries and drivers to `/usr/local/lib` with a
+pkg-config file `libdpdk.pc` installed to `/usr/local/lib/pkgconfig`. The
+DPDK test applications, such as `dpdk-testpmd` are installed to
+`/usr/local/bin`. To use these applications, it is recommended 

[dpdk-dev] [PATCH 4/5] doc: update section on loading FreeBSD kernel modules

[Bruce Richardson]

The kernel modules are now installed in the correct system location on
install when using meson and ninja, so update the documentation to remove
any references to the "kmod" directory. Also, make a few additional updates
to improve clarity.

Signed-off-by: Bruce Richardson 
---
 doc/guides/freebsd_gsg/build_dpdk.rst | 65 ---
 1 file changed, 29 insertions(+), 36 deletions(-)

diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst 
b/doc/guides/freebsd_gsg/build_dpdk.rst
index c5d5379f6..e31c966b9 100644
--- a/doc/guides/freebsd_gsg/build_dpdk.rst
+++ b/doc/guides/freebsd_gsg/build_dpdk.rst
@@ -73,26 +73,25 @@ To run a DPDK application, physically contiguous memory is 
required.
 In the absence of non-transparent superpages, the included sources for the
 contigmem kernel module provides the ability to present contiguous blocks of
 memory for the DPDK to use. The contigmem module must be loaded into the
-running kernel before any DPDK is run.  The module is found in the kmod
-sub-directory of the DPDK target directory.
+running kernel before any DPDK is run. Once DPDK is installed on the
+system, the module can be found in the `/boot/modules` directory.
 
 The amount of physically contiguous memory along with the number of physically
 contiguous blocks to be reserved by the module can be set at runtime prior to
-module loading using:
-
-.. code-block:: console
+module loading using::
 
 kenv hw.contigmem.num_buffers=n
 kenv hw.contigmem.buffer_size=m
 
 The kernel environment variables can also be specified during boot by placing 
the
-following in ``/boot/loader.conf``::
+following in ``/boot/loader.conf``:
 
-hw.contigmem.num_buffers=n hw.contigmem.buffer_size=m
+.. code-block:: shell
 
-The variables can be inspected using the following command:
+hw.contigmem.num_buffers=n
+hw.contigmem.buffer_size=m
 
-.. code-block:: console
+The variables can be inspected using the following command::
 
 sysctl -a hw.contigmem
 
@@ -100,18 +99,19 @@ Where n is the number of blocks and m is the size in bytes 
of each area of
 contiguous memory.  A default of two buffers of size 1073741824 bytes (1 
Gigabyte)
 each is set during module load if they are not specified in the environment.
 
-The module can then be loaded using kldload (assuming that the current 
directory
-is the DPDK target directory):
-
-.. code-block:: console
+The module can then be loaded using kldload::
 
-kldload ./kmod/contigmem.ko
+kldload contigmem
 
 It is advisable to include the loading of the contigmem module during the boot
 process to avoid issues with potential memory fragmentation during later system
-up time.  This can be achieved by copying the module to the ``/boot/kernel/``
-directory and placing the following into ``/boot/loader.conf``::
+up time.  This can be achieved by placing lines similar to the following into
+``/boot/loader.conf``:
+
+.. code-block:: shell
 
+hw.contigmem.num_buffers=1
+hw.contigmem.buffer_size=1073741824
 contigmem_load="YES"
 
 .. note::
@@ -120,17 +120,13 @@ directory and placing the following into 
``/boot/loader.conf``::
 ``hw.contigmem.num_buffers`` and ``hw.contigmem.buffer_size`` if the 
default values
 are not to be used.
 
-An error such as:
-
-.. code-block:: console
+An error such as::
 
 kldload: can't load ./x86_64-native-freebsd-gcc/kmod/contigmem.ko:
  Exec format error
 
 is generally attributed to not having enough contiguous memory
-available and can be verified via dmesg or ``/var/log/messages``:
-
-.. code-block:: console
+available and can be verified via dmesg or ``/var/log/messages``::
 
 kernel: contigmalloc failed for buffer 
 
@@ -142,13 +138,9 @@ Loading the DPDK nic_uio Module
 ---
 
 After loading the contigmem module, the ``nic_uio`` module must also be loaded 
into the
-running kernel prior to running any DPDK application.  This module must
-be loaded using the kldload command as shown below (assuming that the current
-directory is the DPDK target directory).
+running kernel prior to running any DPDK application, e.g. using::
 
-.. code-block:: console
-
-kldload ./kmod/nic_uio.ko
+kldload nic_uio
 
 .. note::
 
@@ -159,8 +151,9 @@ directory is the DPDK target directory).
 Currently loaded modules can be seen by using the ``kldstat`` command and a 
module
 can be removed from the running kernel by using ``kldunload ``.
 
-To load the module during boot, copy the ``nic_uio`` module to ``/boot/kernel``
-and place the following into ``/boot/loader.conf``::
+To load the module during boot place the following into ``/boot/loader.conf``:
+
+.. code-block:: shell
 
 nic_uio_load="YES"
 
@@ -184,7 +177,7 @@ Binding Network Ports to the nic_uio Module
 Device ownership can be viewed using the pciconf -l command. The example below 
shows
 four Intel® 82599 network ports under ``if_ixgbe`` module ownership.
 
-.. code-block:: console
+.. code-block:: none
 
   

[dpdk-dev] [PATCH 5/5] doc: update documentation on build and running FreeBSD apps

[Bruce Richardson]

Update the documentation on building and running apps on FreeBSD, taking
account of having used meson for building. We can also update the section
on the command-line parameters, rather than claiming to be a complete list
of parameters, it should describe how to get the complete list and only
cover a few important ones.

Signed-off-by: Bruce Richardson 
Acked-by: Anatoly Burakov 
---
 doc/guides/freebsd_gsg/build_sample_apps.rst | 118 +--
 1 file changed, 27 insertions(+), 91 deletions(-)

diff --git a/doc/guides/freebsd_gsg/build_sample_apps.rst 
b/doc/guides/freebsd_gsg/build_sample_apps.rst
index 0c1b9cb79..2a68f5fc3 100644
--- a/doc/guides/freebsd_gsg/build_sample_apps.rst
+++ b/doc/guides/freebsd_gsg/build_sample_apps.rst
@@ -12,68 +12,37 @@ environment. It also provides a pointer to where sample 
applications are stored.
 Compiling a Sample Application
 --
 
-Once a DPDK target environment directory has been created (such as
-``x86_64-native-freebsd-clang``), it contains all libraries and header files 
required
-to build an application.
+The DPDK example applications make use of the pkg-config file installed on
+the system when DPDK is installed, and so can be built using GNU make.
 
-When compiling an application in the FreeBSD environment on the DPDK,
-the following variables must be exported:
-
-*   ``RTE_SDK`` - Points to the DPDK installation directory.
-
-*   ``RTE_TARGET`` - Points to the DPDK target environment directory.
-For FreeBSD, this is the ``x86_64-native-freebsd-clang`` or
-``x86_64-native-freebsd-gcc`` directory.
-
-The following is an example of creating the ``helloworld`` application, which 
runs
-in the DPDK FreeBSD environment. While the example demonstrates compiling
-using gcc version 4.9, compiling with clang will be similar, except that the 
``CC=``
-parameter can probably be omitted. The ``helloworld`` example may be found in 
the
-``${RTE_SDK}/examples`` directory.
-
-The directory contains the ``main.c`` file. This file, when combined with the
-libraries in the DPDK target environment, calls the various functions to
-initialize the DPDK environment, then launches an entry point (dispatch
-application) for each core to be utilized. By default, the binary is generated
-in the build directory.
-
-.. code-block:: console
-
-setenv RTE_SDK /home/user/DPDK
-cd $(RTE_SDK)
-cd examples/helloworld/
-setenv RTE_SDK $HOME/DPDK
-setenv RTE_TARGET x86_64-native-freebsd-gcc
-
-gmake CC=gcc49
-  CC main.o
-  LD helloworld
-  INSTALL-APP helloworld
-  INSTALL-MAP helloworld.map
+.. note::
 
-ls build/app
-  helloworld helloworld.map
+   BSD make cannot be used to compile the DPDK example applications. GNU
+   make can be installed using `pkg install gmake` if not already installed
+   on the FreeBSD system.
 
-.. note::
+The following shows how to compile the helloworld example app, following
+the installation of DPDK using `ninja install` as described previously::
 
-In the above example, ``helloworld`` was in the directory structure of the
-DPDK. However, it could have been located outside the directory
-structure to keep the DPDK structure intact.  In the following case,
-the ``helloworld`` application is copied to a new directory as a new 
starting
-point.
+$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
 
-.. code-block:: console
+$ cd examples/helloworld/
 
-setenv RTE_SDK /home/user/DPDK
-cp -r $(RTE_SDK)/examples/helloworld my_rte_app
-cd my_rte_app/
-setenv RTE_TARGET x86_64-native-freebsd-gcc
+$ gmake
+cc -O3 -I/usr/local/include -include rte_config.h -march=native
+-D__BSD_VISIBLE  main.c -o build/helloworld-shared
+-L/usr/local/lib -lrte_telemetry -lrte_bpf -lrte_flow_classify
+-lrte_pipeline -lrte_table -lrte_port -lrte_fib -lrte_ipsec
+-lrte_stack -lrte_security -lrte_sched -lrte_reorder -lrte_rib
+-lrte_rcu -lrte_rawdev -lrte_pdump -lrte_member -lrte_lpm
+-lrte_latencystats -lrte_jobstats -lrte_ip_frag -lrte_gso -lrte_gro
+-lrte_eventdev -lrte_efd -lrte_distributor -lrte_cryptodev
+-lrte_compressdev -lrte_cfgfile -lrte_bitratestats -lrte_bbdev
+-lrte_acl -lrte_timer -lrte_hash -lrte_metrics -lrte_cmdline
+-lrte_pci -lrte_ethdev -lrte_meter -lrte_net -lrte_mbuf
+-lrte_mempool -lrte_ring -lrte_eal -lrte_kvargs
+ln -sf helloworld-shared build/helloworld
 
-gmake CC=gcc49
-  CC main.o
-  LD helloworld
-  INSTALL-APP helloworld
-  INSTALL-MAP helloworld.map
 
 .. _running_sample_app:
 
@@ -88,29 +57,15 @@ Running a Sample Application
 Abstraction Layer (EAL) library, which provides some options that are 
generic
 to every DPDK application.
 
-The following is the list of options that can be given to the EAL:
-
-.. code-block:: console
-
-./rte-app -l CORELIST [-n NUM] [-b ] \
-

Re: [dpdk-dev] [PATCH v3 0/5] GSG Documentation updates

[Bruce Richardson]

On Thu, Nov 28, 2019 at 07:56:42PM +0100, Thomas Monjalon wrote:
> 28/11/2019 17:33, Bruce Richardson:
> > This patchset includes documentation updates for both the Linux and
> > FreeBSD Getting Started Guide Docs. The majority of changes are to add
> > information on building using meson and ninja, with some additional
> > cleanups being performed at the same time.
> > 
> > V3: 
> >  * Updated patch 1 following feedback from Thomas
> >  * Dropped the final 3 patches for 19.11. Post 19.11 I'm hoping to
> >update the BSD port to support 19.11 and have it use meson and ninja
> >to build. Since this will require rework to the BSD GSG then anyway,
> >other major changes to that doc can be held off until that time too.
> > 
> > V2: Updated patch 2 following feedback from Anatoly
> > 
> > Bruce Richardson (5):
> >   doc: update Linux GSG system requirements section
> >   doc: add building with meson to linux GSG
> >   doc: reorder meson and make build instructions for arm
> >   doc: remove reference to old versions of FreeBSD
> >   doc: update examples output in FreeBSD GSG
> 
> Applied, thanks
> 
Thanks,

For reference, the dropped patches from V2 should now be covered by set:
http://patches.dpdk.org/project/dpdk/list/?series=7980

/Bruce

[dpdk-dev] [PATCH 00/14] cleanup resources on shutdown

[Stephen Hemminger]

Recently started using valgrind with DPDK, and the results
are not clean.

The DPDK has a function that applications can use to tell it
to cleanup resources on shutdown (rte_eal_cleanup). But the
current coverage of that API is spotty. Many internal parts of
DPDK leave files and allocated memory behind.

This patch set is a start at getting the sub-parts of
DPDK to cleanup after themselves. These are the easier ones,
the harder and more critical ones are in the drivers
and the memory subsystem.

There are no visible API or ABI changes here.

Stephen Hemminger (14):
  eal: log: close on cleanup
  eal: log: free dynamic state on cleanup
  eal: alarm: close timerfd on eal cleanup
  eal: cleanup threads
  eal: intr: cleanup resources
  eal: mp: end the multiprocess thread during cleanup
  eal: interrupts close epoll fd on shutdown
  eal: vfio: cleanup the mp sync handle
  eal: close mem config on cleanup
  tap: close netlink socket on device close
  eal: cleanup plugins data
  ethdev: raise priority of old driver warning
  eal: hotplug: cleanup multiprocess resources
  eal: malloc: cleanup mp resources

 drivers/net/tap/rte_eth_tap.c   |  7 -
 lib/librte_eal/common/eal_common_log.c  | 30 +-
 lib/librte_eal/common/eal_common_options.c  | 12 +++
 lib/librte_eal/common/eal_common_proc.c | 17 +++---
 lib/librte_eal/common/eal_options.h |  1 +
 lib/librte_eal/common/eal_private.h | 30 ++
 lib/librte_eal/common/hotplug_mp.c  |  5 +++
 lib/librte_eal/common/hotplug_mp.h  |  6 
 lib/librte_eal/common/malloc_heap.c |  6 
 lib/librte_eal/common/malloc_heap.h |  3 ++
 lib/librte_eal/common/malloc_mp.c   | 12 +++
 lib/librte_eal/common/malloc_mp.h   |  3 ++
 lib/librte_eal/linux/eal/eal.c  | 28 +
 lib/librte_eal/linux/eal/eal_alarm.c| 11 +++
 lib/librte_eal/linux/eal/eal_interrupts.c   | 35 ++---
 lib/librte_eal/linux/eal/eal_log.c  | 14 +
 lib/librte_eal/linux/eal/eal_vfio.h |  1 +
 lib/librte_eal/linux/eal/eal_vfio_mp_sync.c |  8 +
 lib/librte_ethdev/rte_ethdev.c  |  2 +-
 19 files changed, 218 insertions(+), 13 deletions(-)

-- 
2.20.1

[dpdk-dev] [PATCH 02/14] eal: log: free dynamic state on cleanup

[Stephen Hemminger]

When rte_eal_cleanup is called, free all the memory
associated with dynamic log levels and types.

Fixes: c1b5fa94a46f ("eal: support dynamic log types")
Cc: olivier.m...@6wind.com
Signed-off-by: Stephen Hemminger 
---
 lib/librte_eal/common/eal_common_log.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/lib/librte_eal/common/eal_common_log.c 
b/lib/librte_eal/common/eal_common_log.c
index 64d6e20947ed..7583bdc57619 100644
--- a/lib/librte_eal/common/eal_common_log.c
+++ b/lib/librte_eal/common/eal_common_log.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "eal_private.h"
 
@@ -54,7 +55,7 @@ struct log_cur_msg {
 };
 
 struct rte_log_dynamic_type {
-   const char *name;
+   char *name;
uint32_t loglevel;
 };
 
@@ -470,8 +471,23 @@ eal_log_set_default(FILE *default_log)
 void
 eal_log_cleanup(void)
 {
+   struct rte_eal_opt_loglevel *opt_ll, *tmp;
+   size_t i;
+
if (default_log_stream) {
fclose(default_log_stream);
default_log_stream = NULL;
}
+
+   TAILQ_FOREACH_SAFE(opt_ll, &opt_loglevel_list, next, tmp) {
+   free(opt_ll->pattern);
+   free(opt_ll);
+   }
+
+   for (i = 0; i < rte_logs.dynamic_types_len; i++)
+   free(rte_logs.dynamic_types[i].name);
+
+   rte_logs.dynamic_types_len = 0;
+   free(rte_logs.dynamic_types);
+   rte_logs.dynamic_types = NULL;
 }
-- 
2.20.1

[dpdk-dev] [PATCH 01/14] eal: log: close on cleanup

[Stephen Hemminger]

When application calls rte_eal_cleanup on shutdown,
the DPDK log should be closed and cleaned up.

Fixes: af75078fece3 ("first public release")
Signed-off-by: Stephen Hemminger 
---
 lib/librte_eal/common/eal_common_log.c | 12 
 lib/librte_eal/common/eal_private.h| 13 +
 lib/librte_eal/linux/eal/eal.c |  1 +
 lib/librte_eal/linux/eal/eal_log.c | 14 ++
 4 files changed, 40 insertions(+)

diff --git a/lib/librte_eal/common/eal_common_log.c 
b/lib/librte_eal/common/eal_common_log.c
index c0efd5214fa9..64d6e20947ed 100644
--- a/lib/librte_eal/common/eal_common_log.c
+++ b/lib/librte_eal/common/eal_common_log.c
@@ -463,3 +463,15 @@ eal_log_set_default(FILE *default_log)
"Debug dataplane logs available - lower performance\n");
 #endif
 }
+
+/*
+ * Called by envrionment-specific cleanup function.
+ */
+void
+eal_log_cleanup(void)
+{
+   if (default_log_stream) {
+   fclose(default_log_stream);
+   default_log_stream = NULL;
+   }
+}
diff --git a/lib/librte_eal/common/eal_private.h 
b/lib/librte_eal/common/eal_private.h
index 8a9d493f0c54..fdd942d71a36 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -90,6 +90,12 @@ int rte_eal_memzone_init(void);
  */
 void eal_log_set_default(FILE *default_log);
 
+/**
+ * Common log cleanup function (private to eal).
+ * Closes the default log stream. Called from rte_eal_cleanup().
+ */
+void eal_log_cleanup(void);
+
 /**
  * Fill configuration with number of physical and logical processors
  *
@@ -151,6 +157,13 @@ int rte_eal_timer_init(void);
  */
 int rte_eal_log_init(const char *id, int facility);
 
+/**
+ * Close the default log stream
+ *
+ * This function is private to EAL.
+ */
+void rte_eal_log_cleanup(void);
+
 /**
  * Save the log regexp for later
  */
diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index c4233ec3c8ac..a3381fd01a23 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -1327,6 +1327,7 @@ rte_eal_cleanup(void)
rte_service_finalize();
rte_mp_channel_cleanup();
eal_cleanup_config(&internal_config);
+   rte_eal_log_cleanup();
return 0;
 }
 
diff --git a/lib/librte_eal/linux/eal/eal_log.c 
b/lib/librte_eal/linux/eal/eal_log.c
index 9d02dddbed33..e1adbc91637a 100644
--- a/lib/librte_eal/linux/eal/eal_log.c
+++ b/lib/librte_eal/linux/eal/eal_log.c
@@ -37,8 +37,16 @@ console_log_write(__attribute__((unused)) void *c, const 
char *buf, size_t size)
return ret;
 }
 
+static int
+console_log_close(__attribute__((unused)) void *c)
+{
+   closelog();
+   return 0;
+}
+
 static cookie_io_functions_t console_log_func = {
.write = console_log_write,
+   .close = console_log_close,
 };
 
 /*
@@ -60,3 +68,9 @@ rte_eal_log_init(const char *id, int facility)
 
return 0;
 }
+
+void
+rte_eal_log_cleanup(void)
+{
+   eal_log_cleanup();
+}
-- 
2.20.1

[dpdk-dev] [PATCH 03/14] eal: alarm: close timerfd on eal cleanup

[Stephen Hemminger]

Calling rte_eal_cleanup() should cause DPDK to cleanup all
outstanding resources including file descriptors.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_eal/common/eal_private.h  |  7 +++
 lib/librte_eal/linux/eal/eal.c   |  1 +
 lib/librte_eal/linux/eal/eal_alarm.c | 11 +++
 3 files changed, 19 insertions(+)

diff --git a/lib/librte_eal/common/eal_private.h 
b/lib/librte_eal/common/eal_private.h
index fdd942d71a36..38682e79827c 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -202,6 +202,13 @@ int rte_eal_intr_init(void);
  */
 int rte_eal_alarm_init(void);
 
+/**
+ * Cleanup alarm resources.
+ *
+ * This function is private to EAL.
+ */
+void rte_eal_alarm_cleanup(void);
+
 /**
  * Function is to check if the kernel module(like, vfio, vfio_iommu_type1,
  * etc.) loaded.
diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index a3381fd01a23..a1b928820b11 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -1325,6 +1325,7 @@ rte_eal_cleanup(void)
if (rte_eal_process_type() == RTE_PROC_PRIMARY)
rte_memseg_walk(mark_freeable, NULL);
rte_service_finalize();
+   rte_eal_alarm_cleanup();
rte_mp_channel_cleanup();
eal_cleanup_config(&internal_config);
rte_eal_log_cleanup();
diff --git a/lib/librte_eal/linux/eal/eal_alarm.c 
b/lib/librte_eal/linux/eal/eal_alarm.c
index 0924c9205c84..e6aeee933ece 100644
--- a/lib/librte_eal/linux/eal/eal_alarm.c
+++ b/lib/librte_eal/linux/eal/eal_alarm.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -72,6 +73,16 @@ rte_eal_alarm_init(void)
return -1;
 }
 
+void
+rte_eal_alarm_cleanup(void)
+{
+   if (intr_handle.fd == -1)
+   return;
+
+   close(intr_handle.fd);
+   intr_handle.fd = -1;
+}
+
 static void
 eal_alarm_callback(void *arg __rte_unused)
 {
-- 
2.20.1

[dpdk-dev] [PATCH 04/14] eal: cleanup threads

[Stephen Hemminger]

When rte_eal_cleanup is called it should stop all the child threads
and close the pipes between threads.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_eal/linux/eal/eal.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index a1b928820b11..d98a2afe85da 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -1319,11 +1319,24 @@ mark_freeable(const struct rte_memseg_list *msl, const 
struct rte_memseg *ms,
 int
 rte_eal_cleanup(void)
 {
+   int i;
+
/* if we're in a primary process, we need to mark hugepages as freeable
 * so that finalization can release them back to the system.
 */
if (rte_eal_process_type() == RTE_PROC_PRIMARY)
rte_memseg_walk(mark_freeable, NULL);
+
+   RTE_LCORE_FOREACH_SLAVE(i) {
+   pthread_cancel(lcore_config[i].thread_id);
+   pthread_join(lcore_config[i].thread_id, NULL);
+
+   close(lcore_config[i].pipe_master2slave[0]);
+   close(lcore_config[i].pipe_master2slave[1]);
+   close(lcore_config[i].pipe_slave2master[0]);
+   close(lcore_config[i].pipe_slave2master[1]);
+   }
+
rte_service_finalize();
rte_eal_alarm_cleanup();
rte_mp_channel_cleanup();
-- 
2.20.1

[dpdk-dev] [PATCH 08/14] eal: vfio: cleanup the mp sync handle

[Stephen Hemminger]

When rte_eal_cleanup is called the rte_mp_action for VFIO
should be freed.

Fixes: edf73dd33072 ("ipc: handle unsupported IPC in action register")
Cc: anatoly.bura...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Stephen Hemminger 
---
 lib/librte_eal/linux/eal/eal.c  | 3 +++
 lib/librte_eal/linux/eal/eal_vfio.h | 1 +
 lib/librte_eal/linux/eal/eal_vfio_mp_sync.c | 8 
 3 files changed, 12 insertions(+)

diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index eb95f4f0c317..9ad81378f23c 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -1338,6 +1338,9 @@ rte_eal_cleanup(void)
}
 
rte_service_finalize();
+#ifdef VFIO_PRESENT
+   vfio_mp_sync_cleanup();
+#endif
rte_eal_intr_cleanup();
rte_eal_alarm_cleanup();
rte_mp_channel_cleanup();
diff --git a/lib/librte_eal/linux/eal/eal_vfio.h 
b/lib/librte_eal/linux/eal/eal_vfio.h
index cb2d35fb1206..bf7408a897a7 100644
--- a/lib/librte_eal/linux/eal/eal_vfio.h
+++ b/lib/librte_eal/linux/eal/eal_vfio.h
@@ -132,6 +132,7 @@ int
 vfio_has_supported_extensions(int vfio_container_fd);
 
 int vfio_mp_sync_setup(void);
+void vfio_mp_sync_cleanup(void);
 
 #define EAL_VFIO_MP "eal_vfio_mp_sync"
 
diff --git a/lib/librte_eal/linux/eal/eal_vfio_mp_sync.c 
b/lib/librte_eal/linux/eal/eal_vfio_mp_sync.c
index 5f2a5fc1d94e..b8ae9c65892e 100644
--- a/lib/librte_eal/linux/eal/eal_vfio_mp_sync.c
+++ b/lib/librte_eal/linux/eal/eal_vfio_mp_sync.c
@@ -120,4 +120,12 @@ vfio_mp_sync_setup(void)
return 0;
 }
 
+void
+vfio_mp_sync_cleanup(void)
+{
+   if (rte_eal_process_type() != RTE_PROC_PRIMARY)
+   return;
+
+   rte_mp_action_unregister(EAL_VFIO_MP);
+}
 #endif
-- 
2.20.1

[dpdk-dev] [PATCH 05/14] eal: intr: cleanup resources

[Stephen Hemminger]

When rte_eal_cleanup is called the interrupt thread and
associated resources should be cleaned up.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_eal/common/eal_private.h   | 10 ++
 lib/librte_eal/linux/eal/eal.c|  1 +
 lib/librte_eal/linux/eal/eal_interrupts.c |  9 +
 3 files changed, 20 insertions(+)

diff --git a/lib/librte_eal/common/eal_private.h 
b/lib/librte_eal/common/eal_private.h
index 38682e79827c..c62f35d3ac0f 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -191,6 +191,16 @@ int rte_eal_tailqs_init(void);
  */
 int rte_eal_intr_init(void);
 
+/**
+ * Cleanup interrupt handling.
+ *
+ * This function is private to EAL.
+ *
+ * @return
+ *  0 on success, negative on error
+ */
+void rte_eal_intr_cleanup(void);
+
 /**
  * Init alarm mechanism. This is to allow a callback be called after
  * specific time.
diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index d98a2afe85da..eb95f4f0c317 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -1338,6 +1338,7 @@ rte_eal_cleanup(void)
}
 
rte_service_finalize();
+   rte_eal_intr_cleanup();
rte_eal_alarm_cleanup();
rte_mp_channel_cleanup();
eal_cleanup_config(&internal_config);
diff --git a/lib/librte_eal/linux/eal/eal_interrupts.c 
b/lib/librte_eal/linux/eal/eal_interrupts.c
index 14ebb108cee9..fa08ac4171bd 100644
--- a/lib/librte_eal/linux/eal/eal_interrupts.c
+++ b/lib/librte_eal/linux/eal/eal_interrupts.c
@@ -1137,6 +1137,15 @@ rte_eal_intr_init(void)
return ret;
 }
 
+void
+rte_eal_intr_cleanup(void)
+{
+   pthread_cancel(intr_thread);
+   pthread_join(intr_thread, NULL);
+   close(intr_pipe.readfd);
+   close(intr_pipe.writefd);
+}
+
 static void
 eal_intr_proc_rxtx_intr(int fd, const struct rte_intr_handle *intr_handle)
 {
-- 
2.20.1

[dpdk-dev] [PATCH 09/14] eal: close mem config on cleanup

[Stephen Hemminger]

Resolves file descriptor left open after rte_eal_cleanup.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_eal/linux/eal/eal.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index 9ad81378f23c..e5c2a24322e9 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -1346,6 +1346,12 @@ rte_eal_cleanup(void)
rte_mp_channel_cleanup();
eal_cleanup_config(&internal_config);
rte_eal_log_cleanup();
+
+   if (mem_cfg_fd != -1) {
+   close(mem_cfg_fd);
+   mem_cfg_fd = -1;
+   }
+
return 0;
 }
 
-- 
2.20.1

[dpdk-dev] [PATCH 11/14] eal: cleanup plugins data

[Stephen Hemminger]

When rte_eal_cleanup is called walk through the list of shared
objects loaded, and close them and free the data structure.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_eal/common/eal_common_options.c | 12 
 lib/librte_eal/common/eal_options.h|  1 +
 lib/librte_eal/linux/eal/eal.c |  1 +
 3 files changed, 14 insertions(+)

diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
index a7f9c5f9bdfa..58c364d896f8 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -308,6 +308,18 @@ eal_plugins_init(void)
return 0;
 }
 
+void
+eal_plugins_cleanup(void)
+{
+   struct shared_driver *solib, *tmp;
+
+   TAILQ_FOREACH_SAFE(solib, &solib_list, next, tmp) {
+   if (solib->lib_handle)
+   dlclose(solib->lib_handle);
+   free(solib);
+   }
+}
+
 /*
  * Parse the coremask given as argument (hexadecimal string) and fill
  * the global configuration (core role and core count) with the parsed
diff --git a/lib/librte_eal/common/eal_options.h 
b/lib/librte_eal/common/eal_options.h
index 9855429e5813..67d3ba0d4491 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -84,5 +84,6 @@ int eal_check_common_options(struct internal_config 
*internal_cfg);
 void eal_common_usage(void);
 enum rte_proc_type_t eal_proc_type_detect(void);
 int eal_plugins_init(void);
+void eal_plugins_cleanup(void);
 
 #endif /* EAL_OPTIONS_H */
diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index e5c2a24322e9..9a00a3ed43ab 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -1344,6 +1344,7 @@ rte_eal_cleanup(void)
rte_eal_intr_cleanup();
rte_eal_alarm_cleanup();
rte_mp_channel_cleanup();
+   eal_plugins_cleanup();
eal_cleanup_config(&internal_config);
rte_eal_log_cleanup();
 
-- 
2.20.1

[dpdk-dev] [PATCH 10/14] tap: close netlink socket on device close

[Stephen Hemminger]

The netlink socket for flow creation was left open and never
closed.

Fixes: bf7b7f437b49 ("net/tap: create netdevice during probing")
Cc: pascal.ma...@6wind.com
Cc: sta...@dpdk.org
Signed-off-by: Stephen Hemminger 
---
 drivers/net/tap/rte_eth_tap.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index a13d8d50d7d7..d293dd8eeed5 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -1035,6 +1035,11 @@ tap_dev_close(struct rte_eth_dev *dev)
&internals->remote_initial_flags);
}
 
+   if (internals->nlsk_fd != -1) {
+   close(internals->nlsk_fd);
+   internals->nlsk_fd = -1;
+   }
+
if (internals->ka_fd != -1) {
close(internals->ka_fd);
internals->ka_fd = -1;
@@ -2406,7 +2411,7 @@ rte_pmd_tap_remove(struct rte_vdev_device *dev)
TAP_LOG(DEBUG, "Closing %s Ethernet device on numa %u",
tuntap_types[internals->type], rte_socket_id());
 
-   if (internals->nlsk_fd) {
+   if (internals->nlsk_fd != -1) {
tap_flow_flush(eth_dev, NULL);
tap_flow_implicit_flush(internals, NULL);
tap_nl_final(internals->nlsk_fd);
-- 
2.20.1

[dpdk-dev] [PATCH 07/14] eal: interrupts close epoll fd on shutdown

[Stephen Hemminger]

Use pthread callbacks to ensure that the epoll fd is closed
when rte_eal_cleanup is called.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_eal/linux/eal/eal_interrupts.c | 26 ++-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/lib/librte_eal/linux/eal/eal_interrupts.c 
b/lib/librte_eal/linux/eal/eal_interrupts.c
index fa08ac4171bd..ae4d3ae3ed60 100644
--- a/lib/librte_eal/linux/eal/eal_interrupts.c
+++ b/lib/librte_eal/linux/eal/eal_interrupts.c
@@ -1032,6 +1032,19 @@ eal_intr_handle_interrupts(int pfd, unsigned totalfds)
}
 }
 
+
+/**
+ * Callback at end of intr_thread loop or if thread is cancelled
+ * that closes the epoll file descriptor
+ */
+static void
+eal_intr_thread_close(void *arg)
+{
+   int pfd = (int)(unsigned long)arg;
+
+   close(pfd);
+}
+
 /**
  * It builds/rebuilds up the epoll file descriptor with all the
  * file descriptors being waited on. Then handles the interrupts.
@@ -1061,6 +1074,12 @@ eal_intr_thread_main(__rte_unused void *arg)
if (pfd < 0)
rte_panic("Cannot create epoll instance\n");
 
+   /* close pfd on thread exit or cancel_pop
+* see man page for restrictions on this macro.
+*/
+   pthread_cleanup_push(eal_intr_thread_close,
+(void *)(unsigned long)pfd);
+
pipe_event.data.fd = intr_pipe.readfd;
/**
 * add pipe fd into wait list, this pipe is used to
@@ -1100,11 +1119,8 @@ eal_intr_thread_main(__rte_unused void *arg)
/* serve the interrupt */
eal_intr_handle_interrupts(pfd, numfds);
 
-   /**
-* when we return, we need to rebuild the
-* list of fds to monitor.
-*/
-   close(pfd);
+   /* close pfd and rebuild the list */
+   pthread_cleanup_pop(1);
}
 }
 
-- 
2.20.1

[dpdk-dev] [PATCH 06/14] eal: mp: end the multiprocess thread during cleanup

[Stephen Hemminger]

When rte_eal_cleanup is called, all control threads should exit.
For the mp thread, this best handled by closing the mp_socket
and letting the thread see that.

This also fixes potential problems where the mp_socket gets
another hard error, and the thread runs away repeating itself
by reading the same error.

Fixes: 85d6815fa6d0 ("eal: close multi-process socket during cleanup")
Cc: qi.z.zh...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Stephen Hemminger 
---
 lib/librte_eal/common/eal_common_proc.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_proc.c 
b/lib/librte_eal/common/eal_common_proc.c
index 935e8fefeba8..f369d8bf6dd8 100644
--- a/lib/librte_eal/common/eal_common_proc.c
+++ b/lib/librte_eal/common/eal_common_proc.c
@@ -276,8 +276,17 @@ read_msg(struct mp_msg_internal *m, struct sockaddr_un *s)
msgh.msg_control = control;
msgh.msg_controllen = sizeof(control);
 
+retry:
msglen = recvmsg(mp_fd, &msgh, 0);
+
+   /* zero length message means socket was closed */
+   if (msglen == 0)
+   return 0;
+
if (msglen < 0) {
+   if (errno == EINTR)
+   goto retry;
+
RTE_LOG(ERR, EAL, "recvmsg failed, %s\n", strerror(errno));
return -1;
}
@@ -305,7 +314,7 @@ read_msg(struct mp_msg_internal *m, struct sockaddr_un *s)
RTE_LOG(ERR, EAL, "invalid received data length\n");
return -1;
}
-   return 0;
+   return msglen;
 }
 
 static void
@@ -376,10 +385,8 @@ mp_handle(void *arg __rte_unused)
struct mp_msg_internal msg;
struct sockaddr_un sa;
 
-   while (1) {
-   if (read_msg(&msg, &sa) == 0)
-   process_msg(&msg, &sa);
-   }
+   while (read_msg(&msg, &sa) > 0)
+   process_msg(&msg, &sa);
 
return NULL;
 }
-- 
2.20.1

[dpdk-dev] [PATCH 13/14] eal: hotplug: cleanup multiprocess resources

[Stephen Hemminger]

When rte_eal_cleanup is called, hotplug should unregister the
resources associated with the multi-process server.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_eal/common/hotplug_mp.c | 5 +
 lib/librte_eal/common/hotplug_mp.h | 6 ++
 lib/librte_eal/linux/eal/eal.c | 1 +
 3 files changed, 12 insertions(+)

diff --git a/lib/librte_eal/common/hotplug_mp.c 
b/lib/librte_eal/common/hotplug_mp.c
index ee791903b3b7..a390c01fd41c 100644
--- a/lib/librte_eal/common/hotplug_mp.c
+++ b/lib/librte_eal/common/hotplug_mp.c
@@ -463,3 +463,8 @@ int eal_mp_dev_hotplug_init(void)
 
return 0;
 }
+
+void eal_mp_dev_hotplug_cleanup(void)
+{
+   rte_mp_action_unregister(EAL_DEV_MP_ACTION_REQUEST);
+}
diff --git a/lib/librte_eal/common/hotplug_mp.h 
b/lib/librte_eal/common/hotplug_mp.h
index 8fcf9b52e24c..4848446c852d 100644
--- a/lib/librte_eal/common/hotplug_mp.h
+++ b/lib/librte_eal/common/hotplug_mp.h
@@ -37,6 +37,12 @@ struct eal_dev_mp_req {
 int
 eal_mp_dev_hotplug_init(void);
 
+/**
+ * Unregister all mp action callbacks for hotplug.
+ */
+void
+eal_mp_dev_hotplug_cleanup(void);
+
 /**
  * This is a synchronous wrapper for secondary process send
  * request to primary process, this is invoked when an attach
diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index 9a00a3ed43ab..ef04defbeaa4 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -1343,6 +1343,7 @@ rte_eal_cleanup(void)
 #endif
rte_eal_intr_cleanup();
rte_eal_alarm_cleanup();
+   eal_mp_dev_hotplug_cleanup();
rte_mp_channel_cleanup();
eal_plugins_cleanup();
eal_cleanup_config(&internal_config);
-- 
2.20.1

[dpdk-dev] [PATCH 14/14] eal: malloc: cleanup mp resources

[Stephen Hemminger]

The mp action resources in malloc should be cleaned up via
rte_eal_cleanup.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_eal/common/malloc_heap.c |  6 ++
 lib/librte_eal/common/malloc_heap.h |  3 +++
 lib/librte_eal/common/malloc_mp.c   | 12 
 lib/librte_eal/common/malloc_mp.h   |  3 +++
 lib/librte_eal/linux/eal/eal.c  |  1 +
 5 files changed, 25 insertions(+)

diff --git a/lib/librte_eal/common/malloc_heap.c 
b/lib/librte_eal/common/malloc_heap.c
index 842eb9de75a1..13c673f363a9 100644
--- a/lib/librte_eal/common/malloc_heap.c
+++ b/lib/librte_eal/common/malloc_heap.c
@@ -1362,3 +1362,9 @@ rte_eal_malloc_heap_init(void)
/* add all IOVA-contiguous areas to the heap */
return rte_memseg_contig_walk(malloc_add_seg, NULL);
 }
+
+void
+rte_eal_malloc_heap_cleanup(void)
+{
+   unregister_mp_requests();
+}
diff --git a/lib/librte_eal/common/malloc_heap.h 
b/lib/librte_eal/common/malloc_heap.h
index 772736b53f3c..ffad1b61e246 100644
--- a/lib/librte_eal/common/malloc_heap.h
+++ b/lib/librte_eal/common/malloc_heap.h
@@ -100,6 +100,9 @@ malloc_socket_to_heap_id(unsigned int socket_id);
 int
 rte_eal_malloc_heap_init(void);
 
+void
+rte_eal_malloc_heap_cleanup(void);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_eal/common/malloc_mp.c 
b/lib/librte_eal/common/malloc_mp.c
index 1f212f834993..a9a9e8a45221 100644
--- a/lib/librte_eal/common/malloc_mp.c
+++ b/lib/librte_eal/common/malloc_mp.c
@@ -749,3 +749,15 @@ register_mp_requests(void)
}
return 0;
 }
+
+void
+unregister_mp_requests(void)
+{
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+   rte_mp_action_unregister(MP_ACTION_REQUEST);
+   } else {
+   rte_mp_action_unregister(MP_ACTION_SYNC);
+   rte_mp_action_unregister(MP_ACTION_ROLLBACK);
+   rte_mp_action_unregister(MP_ACTION_RESPONSE);
+   }
+}
diff --git a/lib/librte_eal/common/malloc_mp.h 
b/lib/librte_eal/common/malloc_mp.h
index 2b86b76f6848..fb3d18c4e458 100644
--- a/lib/librte_eal/common/malloc_mp.h
+++ b/lib/librte_eal/common/malloc_mp.h
@@ -63,6 +63,9 @@ struct malloc_mp_req {
 int
 register_mp_requests(void);
 
+void
+unregister_mp_requests(void);
+
 int
 request_to_primary(struct malloc_mp_req *req);
 
diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index ef04defbeaa4..c660f6fac3f2 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -1344,6 +1344,7 @@ rte_eal_cleanup(void)
rte_eal_intr_cleanup();
rte_eal_alarm_cleanup();
eal_mp_dev_hotplug_cleanup();
+   rte_eal_malloc_heap_cleanup();
rte_mp_channel_cleanup();
eal_plugins_cleanup();
eal_cleanup_config(&internal_config);
-- 
2.20.1

[dpdk-dev] [PATCH 12/14] ethdev: raise priority of old driver warning

[Stephen Hemminger]

The priority of the message about drivers not using new (correct)
behaviour on close was debug. And debug messages are typically surpressed
and never seen.  Raise the priority so that broken drivers are visible
and hopefully get developers to fix.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_ethdev/rte_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 6e9cb243ea80..545687dbc5c9 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -1717,7 +1717,7 @@ rte_eth_dev_close(uint16_t port_id)
rte_eth_dev_release_port(dev);
return;
}
-   RTE_ETHDEV_LOG(DEBUG, "Port closing is using an old behaviour.\n"
+   RTE_ETHDEV_LOG(NOTICE, "Port closing is using an old behaviour.\n"
"The driver %s should migrate to the new behaviour.\n",
dev->device->driver->name);
/* old behaviour: only free queue arrays */
-- 
2.20.1