From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by dpdk.org (Postfix) with ESMTP id 23C11688F for ; Fri, 30 May 2014 02:03:33 +0200 (CEST) Received: by mail-la0-f48.google.com with SMTP id mc6so591314lab.7 for ; Thu, 29 May 2014 17:03:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=COEWqIH1Gyk1B6RnEfcTM40Lqg9EW75LqF4QXsuAaPo=; b=VuuXkBC5l3pInGGkYwNEPL4y3mbqJr5sB/ZE6UodhGOJgDH/3qAl3P9MbVIbRk7IaK 0yhWY+2FmnrTOqzT46HEyD6vZRxojEf4IOWBS6a5ZPiFM3DBlaNAoMyI5A2SdqZoTPcp 0uSUYlrDxXvGWV4iZTj2VsMb3Izr7fhtMBPxreTxCWuNHaSHlu6j0aGFbagT7ZqiHFzp 7aC1I3iulQLcg8ct4M4aOSo2aBNLDM+nfcapevzYrUYquryTWt+K1i7QdwoRqUJvTX6P k7PNvVj7LHlwmd/MSC7e12X/8dAPnT31IL+cTw774NPXzdVnK6LBF9pQAp1t8GHMOmmG FPGQ== X-Gm-Message-State: ALoCoQlmjRai1HQSbFzowLKmNPpzxF8tg3Vhn519HTs+3wRJre782CyemlgnBIjvAc4Fjs/ujG2u MIME-Version: 1.0 X-Received: by 10.113.3.139 with SMTP id bw11mr8409160lbd.63.1401408224275; Thu, 29 May 2014 17:03:44 -0700 (PDT) Received: by 10.152.36.169 with HTTP; Thu, 29 May 2014 17:03:44 -0700 (PDT) Received: by 10.152.36.169 with HTTP; Thu, 29 May 2014 17:03:44 -0700 (PDT) In-Reply-To: References: <20140527093457.7f5d9746@nehalam.linuxnetplumber.net> <3EB4FA525960D640B5BDFFD6A3D891261B1BE888@IRSMSX102.ger.corp.intel.com> <3EB4FA525960D640B5BDFFD6A3D891261B1BECF9@IRSMSX102.ger.corp.intel.com> <3EB4FA525960D640B5BDFFD6A3D891261B1BF967@IRSMSX102.ger.corp.intel.com> Date: Thu, 29 May 2014 21:03:44 -0300 Message-ID: From: Ariel Rodriguez To: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] Fwd: RE: Please any one who can help me with librte_sched X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 00:03:33 -0000 ---------- Forwarded message ---------- From: "Ariel Rodriguez" Date: May 29, 2014 8:59 PM Subject: RE: [dpdk-dev] Please any one who can help me with librte_sched To: "Dumitrescu, Cristian" Cc: Hi christian. I am aware of that... maybe i wold have to explain better my approach. 1) The client applies a new configuration, its a requirement for our customer that they could change port, subport,pipe rate and also pipe profiles in a dynamic way. So, i think the solution on this way: First when a customer applies the config , the managment core parse the conf and then creates a new rte_sched_port from scratch with the changes in pipes profiles port subport and pipe rate etc. When the managment core is done with that , it send a command update via a rte_ring and the data in the ring is actually a structure wrapping the rte_sched_port recently created. 2) The tx core which is also the same core where its enqueue and dequeue packets from the "old" rte_sched_port, reads the rte_ring and extract the rte_sched_port that the customer applies. So i will just let the two of it lives together and the tx core enqueue in the new port only, and dequeue in a round robin manner from the two rte_sched_port until the "old one" become empty. Then this "live together" state ends, and the tx core is switch to the old state in which just enqueue and dequeue from one rte_sched_port only. Just a note we have a rx core in which the packets are read from the net port and send to severals worker ring . And we have several "workers" cores that just read from the ring and pass the packets to the ,i believe you know ,Qosmos ixEngine dpi. Based on the classification that qosmos delivers , we put that packet in a specific queue from specific pipe and send to the tx ring . We are doing qos scheduling based on the dinamic information that qosmos delivers. Then the tx core reads from that ring and behave like i just told. Thats our architecture in a few words ... i wide open to suggestions je je je. Im planning when i have a little time to read the qos scheduler code in a conscious way because im interesting in the aproach of scheduling packets in that way... because my other option is a hardware solution and if so i would have to change the perspective radically. On May 29, 2014 8:07 PM, "Dumitrescu, Cristian" < cristian.dumitrescu@intel.com> wrote: > Hi Ariel, > > > > So how are you making sure you are not getting more packets in while you > are waiting for dequeue() to return zero for some time? > > > > As stated, I don=E2=80=99t like this approach, firstly because it forces = the > on-the-fly BW configuration changes to result in dropping packets for a > considerable amount of time in an uncontrolled way, and it should not be > this way. Secondly, because making it work with no buffer leakage and no > race conditions is probably not that simple ;) > > > > Regards, > > Cristian > > > > > > *From:* Ariel Rodriguez [mailto:arodriguez@callistech.com] > *Sent:* Wednesday, May 28, 2014 11:50 AM > *To:* Dumitrescu, Cristian > *Cc:* dev@dpdk.org; Stephen Hemminger > *Subject:* RE: [dpdk-dev] Please any one who can help me with librte_sche= d > > > > Ok i can do that... but still is there a way to ask to the rte_sched_port > something like is_empty > ... Or simply if the dequeue function return 0 packets retrieved from the > old port structure running in other core, > Can i assume that port is empty with that? > > Regards > > Ariel. > > On May 28, 2014 7:10 AM, "Dumitrescu, Cristian" < > cristian.dumitrescu@intel.com> wrote: > > Hi Ariel, > > > > I think you put your finger precisely on the problem associated with your > approach: you have to iterate through all the queues and free up the > packets, which takes a lot of time. Obviously this is not done by the > rte_sched API. > > > > Maybe a limited workaround for this approach would be to create and > service the parallel rte_sched using a different CPU core, while the > previous CPU core takes its time to free up all the packets and data > structures correctly. > > > > Regards, > > Cristian > > > > *From:* Ariel Rodriguez [mailto:arodriguez@callistech.com] > *Sent:* Wednesday, May 28, 2014 1:46 AM > *To:* Dumitrescu, Cristian > *Cc:* Stephen Hemminger; dev@dpdk.org > *Subject:* Re: [dpdk-dev] Please any one who can help me with librte_sche= d > > > > Thank you perfect explanation, i think im going to creating a new paralle= l > 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 recentl= y > created rte_sched_port .... > > > > Regars, > > Ariel. > > > > On Tue, May 27, 2014 at 3:31 PM, Dumitrescu, Cristian < > cristian.dumitrescu@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 t= he > 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 leve= l > 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 regular= ly > and performing the updates. > > Regards, > Cristian > > > > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger > Sent: Tuesday, May 27, 2014 5:35 PM > To: Ariel Rodriguez > Cc: dev@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 wrote: > > > Hello , this is my third mail , the previous mails have not been answer= ed > > 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 pointe= r) > > 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 othe= rs > is strictly prohibited. If you are not the intended recipient, please > contact the sender and delete all copies. > > > > -------------------------------------------------------------- > 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 othe= rs > is strictly prohibited. If you are not the intended recipient, please > contact the sender and delete all copies. > > -------------------------------------------------------------- > 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 othe= rs > is strictly prohibited. If you are not the intended recipient, please > contact the sender and delete all copies. > >