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 >> 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 . > >> 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, Jesus > > Thanks, > > tglx >
