[dpdk-dev] Please any one who can help me with librte_sched

Ariel Rodriguez arodriguez at callistech.com
Wed May 28 02:45:37 CEST 2014


Thank you perfect explanation, i think im going to creating a new parallel
rte_sched_port and change the reference with managment core updating the
tx/sched core. So, what happens with the packets on the old reference if i
just do rte_port_free on it, are them leaked? Is there a why to flush the
rte_sched_port or maybe gets the packet total size somewhere?.
Anyway the rcu algoritm fits ok in this aproach ... but maybe there is a
way to flush the old reference port, and work from there with the recently
 created rte_sched_port ....

Regars,
Ariel.


On Tue, May 27, 2014 at 3:31 PM, Dumitrescu, Cristian <
cristian.dumitrescu at intel.com> wrote:

> Hi Ariel,
>
> What's wrong with calling rte_sched_subport_config() and
> rte_sched_pipe_config() during run-time?
>
> This assumes that:
>
> 1. Port initialization is done, which includes the following:
> a) the number of subports, pipes per subport are fixed
> b) the queues are all created and their size is fixed
> c) the pipe profiles are defined
> d) Basically the maximal data structures get created (maximum number of
> supports, pipes and queues) with no run-time changes allowed, apart for the
> bandwidth related parameters. Queues that do not receive packets are not
> used now, they will be used as soon as they get packets. The
> packets-to-queues mapping logic can change over time, as well as the level
> of activity for different users/queues.
>
> 2. The CPU core calling the subport/pipe config functions is the same as
> the core doing enque/dequeue for this port (for thread safety reasons).
> a) As you say, the management core can send update requests to the core
> running the scheduler, with the latter sampling the request queue regularly
> and performing the updates.
>
> Regards,
> Cristian
>
>
> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Tuesday, May 27, 2014 5:35 PM
> To: Ariel Rodriguez
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Please any one who can help me with librte_sched
>
> On Tue, 27 May 2014 10:33:02 -0300
> Ariel Rodriguez <arodriguez at callistech.com> wrote:
>
> > Hello , this is my third mail , the previous mails have not been answered
> > yet.
> >
> > I justo need someone explains to me  how the librte_sched framework
> behaves
> > in a specific situation.
> >
> > I have a managment application , this connects with a ring with the tx
> > core, when a user applies some configuration of the bandwith mangement ,
> > the tx core read the message in the ring parse the configuration in a
> > rte_port_params struct , subport_params and pipe_params, then creates a
> new
> > rte_sched from scratch , and then changes the pointer of the current
> > rte_sched_port currently doing scheduling and then the code execurte
> > rte_sched_port_free() for the unreference (reference by temporal pointer)
> > rte_sched_port . This is the only way i found for applying dinamic
> > configuration or changes to the qos framework.
> > So, with this, what happens with the packets attached to the old
> > rte_sched_port while is deleted? are those lost packets inside the
> > rte_sched_port generates memory leaks?  how can i recover this packets _
> > just dequeing from the port scheduler? Where the port scheduler
>  indicates
> > empty packets in the queu state?
> >
> > Is there a better way to achieve this kind of behaviour? i just need to
> > update  the rte_sched_port configuration dinamically, and i want to
> change
> > the current pipe configuration and sub port configuration also.
> >
> > Regards .
>
> If you need to do dynamic changes, I would recommend using an RCU type
> algorithm where you exchange in new parameters and then cleanup/free
> after a grace period.  See http://lttng.org/urcu
>
> --------------------------------------------------------------
> Intel Shannon Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
> Business address: Dromore House, East Park, Shannon, Co. Clare
>
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please
> contact the sender and delete all copies.
>
>
>


More information about the dev mailing list