Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

From: Thomas Gleixner Date: Tue, 24 Apr 2018 10:50:04 +0200 (CEST) > So adding 8 bytes to spare duplicated code will not change the kmem_cache > object size and I really doubt that anyone will notice. It's about where the cache lines end up when each and every byte is added

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

On Mon, 23 Apr 2018, Jesus Sanchez-Palencia wrote: > On 03/21/2018 06:46 AM, Thomas Gleixner wrote: > > On Tue, 6 Mar 2018, Jesus Sanchez-Palencia wrote: > >> +struct tbs_sched_data { > >> + bool sorting; > >> + int clockid; > >> + int queue; > >> + s32 delta; /* in ns */ > >> + ktime_t last;

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

Hi Thomas, On 03/21/2018 06:46 AM, Thomas Gleixner wrote: > On Tue, 6 Mar 2018, Jesus Sanchez-Palencia wrote: >> +struct tbs_sched_data { >> +bool sorting; >> +int clockid; >> +int queue; >> +s32 delta; /* in ns */ >> +ktime_t last; /* The txtime of the last skb sent to the

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

On Wed, 11 Apr 2018, Jesus Sanchez-Palencia wrote: > On 04/11/2018 01:16 PM, Thomas Gleixner wrote: > >> So there is a "clockid" that can be used for the full hw offload modes. On > >> this > >> case, the txtimes are in reference to the NIC's PTP clock, and, as > >> discussed, we > >> can't just

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

On Thu, Apr 12, 2018 at 08:03:49AM -0700, Richard Cochran wrote: > On Wed, Apr 11, 2018 at 04:38:44PM -0700, Jesus Sanchez-Palencia wrote: > > Just breaking this down a bit, yes, TAI is the network time base, and the > > NICs > > PTP clock use that because PTP is (commonly) based on TAI. After

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

On Wed, Apr 11, 2018 at 04:38:44PM -0700, Jesus Sanchez-Palencia wrote: > Just breaking this down a bit, yes, TAI is the network time base, and the NICs > PTP clock use that because PTP is (commonly) based on TAI. After the PHCs have > been synchronized over the network (e.g. with ptp4l), my

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

Hi, On 04/11/2018 01:16 PM, Thomas Gleixner wrote: Putting it all together, we end up with: 1) a new txtime aware qdisc, tbs, to be used per queue. Its cli will look like: $ tc qdisc add (...) tbs clockid CLOCK_REALTIME delta 15 offload sorting >>> >>> Why

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

On 04/11/2018 01:16 PM, Thomas Gleixner wrote: > On Tue, 10 Apr 2018, Jesus Sanchez-Palencia wrote: This will be provided by tbs if the socket which is transmitting packets is configured for deadline mode. >>> >>> You don't want the socket to decide that. The qdisc into which a socket

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

On Tue, 10 Apr 2018, Jesus Sanchez-Palencia wrote: > >> This will be provided by tbs if the socket which is transmitting packets is > >> configured for deadline mode. > > > > You don't want the socket to decide that. The qdisc into which a socket > > feeds defines the mode and the qdisc rejects

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

Hi Thomas, On 04/10/2018 05:37 AM, Thomas Gleixner wrote: (...) >>> >>> - Simple feed through (Applications are time contraints aware and set the >>>exact schedule). qdisc has admission control. >> >> This will be provided by the tbs qdisc. It will still provide a txtime sorted >> list

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

Jesus, On Mon, 9 Apr 2018, Jesus Sanchez-Palencia wrote: > On 03/28/2018 12:48 AM, Thomas Gleixner wrote: > > Yes, you have the root qdisc, which is in charge of the overall scheduling > > plan, how complex or not it is defined does not matter. It exposes traffic > > classes which have properties

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

Hi Thomas, On 03/28/2018 12:48 AM, Thomas Gleixner wrote: (...) > > There are two modes: > > 1) Send at the given TX time (Explicit mode) > > 2) Send before given TX time (Deadline mode) > > There is no need to specify 'drop if late' simply because if the message is > handed in

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

On Wed, Mar 28, 2018 at 09:48:05AM +0200, Thomas Gleixner wrote: > Jesus, Thomas, Jesus, > On Tue, 27 Mar 2018, Jesus Sanchez-Palencia wrote: > > On 03/25/2018 04:46 AM, Thomas Gleixner wrote: > > > This is missing right now and you want to get that right from the very > > > beginning. Duct

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

Jesus, On Tue, 27 Mar 2018, Jesus Sanchez-Palencia wrote: > On 03/25/2018 04:46 AM, Thomas Gleixner wrote: > > This is missing right now and you want to get that right from the very > > beginning. Duct taping it on the interface later on is a bad idea. > > Agreed that this is needed. On the

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

Hi Thomas, On 03/25/2018 04:46 AM, Thomas Gleixner wrote: > On Fri, 23 Mar 2018, Jesus Sanchez-Palencia wrote: >> On 03/22/2018 03:52 PM, Thomas Gleixner wrote: >>> So what's the plan for this? Having TAS as a separate entity or TAS feeding >>> into the proposed 'basic' time transmission thing?

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

On Fri, 23 Mar 2018, Jesus Sanchez-Palencia wrote: > On 03/22/2018 03:52 PM, Thomas Gleixner wrote: > > So what's the plan for this? Having TAS as a separate entity or TAS feeding > > into the proposed 'basic' time transmission thing? > > The second one, I guess. That's just wrong. It won't

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

Hi, On 03/22/2018 03:52 PM, Thomas Gleixner wrote: > On Thu, 22 Mar 2018, Jesus Sanchez-Palencia wrote: >> Our plan was to work directly with the Qbv-like scheduling (per-port) just >> after >> the cbs qdisc (Qav), but the feedback here and offline was that there were >> use >> cases for a

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

Hi Thomas, On 03/23/2018 01:49 AM, Thomas Gleixner wrote: > On Thu, 22 Mar 2018, Jesus Sanchez-Palencia wrote: >> On 03/22/2018 03:11 PM, Thomas Gleixner wrote: >> So, are you just opposing to the case where sorting off + offload off is >> used? >> (i.e. the scheduled FIFO case) > > FIFO does

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

On Thu, 22 Mar 2018, Jesus Sanchez-Palencia wrote: > On 03/22/2018 03:11 PM, Thomas Gleixner wrote: > So, are you just opposing to the case where sorting off + offload off is used? > (i.e. the scheduled FIFO case) FIFO does not make any sense if your packets have a fixed transmission time. I yet

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

Hi Thomas, On 03/22/2018 03:11 PM, Thomas Gleixner wrote: (...) >> Having the sorting always enabled requires that a valid static clockid is >> passed >> to the qdisc. For the hw offload mode, that means that the PHC and one of the >> system clocks must be synchronized since hrtimers do not

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

On Thu, 22 Mar 2018, Jesus Sanchez-Palencia wrote: > Our plan was to work directly with the Qbv-like scheduling (per-port) just > after > the cbs qdisc (Qav), but the feedback here and offline was that there were use > cases for a more simplistic launchtime approach (per-queue) as well. We've >

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

On Thu, 22 Mar 2018, Jesus Sanchez-Palencia wrote: > On 03/21/2018 06:46 AM, Thomas Gleixner wrote: > > If you look at the use cases of TDM in various fields then FIFO mode is > > pretty much useless. In industrial/automotive fieldbus applications the > > various time slices are filled by

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

Hi Thomas, On 03/21/2018 06:46 AM, Thomas Gleixner wrote: > On Tue, 6 Mar 2018, Jesus Sanchez-Palencia wrote: >> +struct tbs_sched_data { >> +bool sorting; >> +int clockid; >> +int queue; >> +s32 delta; /* in ns */ >> +ktime_t last; /* The txtime of the last skb sent to the

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

Hi Thomas, On 03/21/2018 03:29 PM, Thomas Gleixner wrote: > On Wed, 21 Mar 2018, Thomas Gleixner wrote: >> If you look at the use cases of TDM in various fields then FIFO mode is >> pretty much useless. In industrial/automotive fieldbus applications the >> various time slices are filled by

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

On Wed, 21 Mar 2018, Thomas Gleixner wrote: > If you look at the use cases of TDM in various fields then FIFO mode is > pretty much useless. In industrial/automotive fieldbus applications the > various time slices are filled by different threads or even processes. That brings me to a related

Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

On Tue, 6 Mar 2018, Jesus Sanchez-Palencia wrote: > +struct tbs_sched_data { > + bool sorting; > + int clockid; > + int queue; > + s32 delta; /* in ns */ > + ktime_t last; /* The txtime of the last skb sent to the netdevice. */ > + struct rb_root head; Hmm. You are

[RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc

From: Vinicius Costa Gomes TBS (Time Based Scheduler) uses the information added earlier in this series (the socket option SO_TXTIME and the new role of sk_buff->tstamp) to schedule traffic transmission based on absolute time. For some workloads, just bandwidth