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?
Thanks,
tglx
