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
>>> 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.
> Correct. The same is true if you try to set SO_TXTIME for something which
> is just routing regular traffic.
>> (...)
>>>> 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.
> Makes sense.
>>>> 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?
> I think so. It's _the_ network time on which everything is based on.
>>>> 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 
>> .
> And the NICs PTP clock is CLOCK_TAI, so there should be no reason to have
> yet another clock, right?

Most likely, though you can technically have a different time domain
that is not based on TAI.

> Thanks,
>       tglx

Reply via email to