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 >>>> SCM_TXTIME. >>>> >>>> 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 >
