Willem de Bruijn <willemdebruijn.kernel@xxxxxxxxx> writes: >> > If I understand correctly, you are trying to achieve a single delivery time. >> > The need for two separate timestamps passed along is only because the >> > kernel is unable to do the time base conversion. >> >> Yes, a correct point. >> >> > >> > Else, ETF could program the qdisc watchdog in system time and later, >> > on dequeue, convert skb->tstamp to the h/w time base before >> > passing it to the device. >> >> Or the skb->tstamp is HW time-stamp and the ETF convert it to system clock based. >> >> > >> > It's still not entirely clear to me why the packet has to be held by >> > ETF initially first, if it is held until delivery time by hardware >> > later. But more on that below. >> >> Let plot a simple scenario. >> App A send a packet with time-stamp 100. >> After arrive a second packet from App B with time-stamp 90. >> Without ETF, the second packet will have to wait till the interface hardware send the first packet on 100. >> Making the second packet late by 10 + first packet send time. >> Obviously other "normal" packets are send to the non-ETF queue, though they do not block ETF packets >> The ETF delta is a barrier that the application have to send the packet before to ensure the packet do not tossed. > > Got it. The assumption here is that devices are FIFO. That is not > necessarily the case, but I do not know whether it is in practice, > e.g., on the i210. On the i210 and i225, that's indeed the case, i.e. only the launch time of the packet at the front of the queue is considered. [...] >> >>>>> It only requires that pacing qdiscs, both sch_etf and sch_fq, >> >>>>> optionally skip queuing in their .enqueue callback and instead allow >> >>>>> the skb to pass to the device driver as is, with skb->tstamp set. Only >> >>>>> to devices that advertise support for h/w pacing offload. >> >>>>> >> >>>> I did not use "Fair Queue traffic policing". >> >>>> As for ETF, it is all about ordering packets from different applications. >> >>>> How can we achive it with skiping queuing? >> >>>> Could you elaborate on this point? >> >>> >> >>> The qdisc can only defer pacing to hardware if hardware can ensure the >> >>> same invariants on ordering, of course. >> >> >> >> Yes, this is why we suggest ETF order packets using the hardware time-stamp. >> >> And pass the packet based on system time. >> >> So ETF query the system clock only and not the PHC. >> > >> > On which note: with this patch set all applications have to agree to >> > use h/w time base in etf_enqueue_timesortedlist. In practice that >> > makes this h/w mode a qdisc used by a single process? >> >> A single process theoretically does not need ETF, just set the skb-> tstamp and use a pass through queue. >> However the only way now to set TC_SETUP_QDISC_ETF in the driver is using ETF. > > Yes, and I'd like to eventually get rid of this constraint. > I'm interested in these kind of ideas :-) What would be your end goal? Something like: - Any application is able to set SO_TXTIME; - We would have a best effort support for scheduling packets based on their transmission time enabled by default; - If the hardware supports, there would be a "offload" flag that could be enabled; More or less this? Cheers. -- Vinicius
