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 and hw offload, but now there will be a per-socket option that tells the
>> qdisc if the per-packet timestamp is the txtime (i.e. explicit mode, as 
>> you've
>> called it) or a deadline. The drop_if_late flag will be removed.
>> When in explicit mode, packets from that socket are dequeued from the qdisc
>> during its time slice if their [(txtime - delta) < now].
>>>  - Deadline aware qdisc to handle e.g. A/V streams. Applications are aware
>>>    of time constraints and provide the packet deadline. qdisc has admission
>>>    control. This can be a simple first comes, first served scheduler or
>>>    something like EDF which allows optimized utilization. The qdisc sets
>>>    the TX time depending on the deadline and feeds into the root.
>> 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 requests with the wrong mode.
> Making a qdisc doing both and let the user decide what he wants it to be is
> not really going to fly. Especially if you have different users which want
> a different mode. It's clearly distinct functionality.

Ok, so just to make sure I got this right, are you suggesting that both the
'tbs' qdisc *and* the socket (i.e. through SO_TXTIME) should have a config
parameter for specifying the txtime mode? This way if there is a mismatch,
packets from that socket are rejected by the qdisc.


>> Another question for this mode (but perhaps that applies to both modes) is, 
>> what
>> if the qdisc misses the deadline for *any* reason? I'm assuming it should 
>> drop
>> the packet during dequeue.
> There the question is how user space is notified about that issue. The
> application which queued the packet on time does rightfully assume that
> it's going to be on the wire on time.
> This is a violation of the overall scheduling plan, so you need to have
> a sane design to handle that.

In addition to the qdisc stats, we could look into using the socket's error
queue to notify the application about that.

>> 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 150000 offload sorting
> Why CLOCK_REALTIME? The only interesting time in a TSN network is
> CLOCK_TAI, really.

REALTIME was just an example here to show that the qdisc has to be configured
with a clockid parameter. Are you suggesting that instead both of the new qdiscs
(i.e. tbs and taprio) should always be using CLOCK_TAI implicitly?

>> 2) a new cmsg-interface for setting a per-packet timestamp that will be used
>> either as a txtime or as deadline by tbs (and further the NIC driver for the
>> offlaod case): SCM_TXTIME.
>> 3) a new socket option: SO_TXTIME. It will be used to enable the feature for 
>> a
>> socket, and will have as parameters a clockid and a txtime mode (deadline or
>> explicit), that defines the semantics of the timestamp set on packets using
>> 4) a new #define DYNAMIC_CLOCKID 15 added to include/uapi/linux/time.h .
> Can you remind me why we would need that?

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 use a clockid that was computed from the fd pointing to /dev/ptpX .

>> 5) a new schedule-aware qdisc, 'tas' or 'taprio', to be used per port. Its 
>> cli
>> will look like what was proposed for taprio (base time being an absolute 
>> timestamp).
>> If we all agree with the above, we will start by closing on 1-4 asap and will
>> focus on 5 next.
>> How does that sound?
> Backwards to be honest.
> You should start with the NIC facing qdisc because that's the key part of
> all this and the design might have implications on how the qdiscs which
> feed into it need to be designed.

Ok, let's just try to close on the above first.


> Thanks,
>       tglx

Reply via email to