> >> >>>> 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? Exactly. Pacing is stateless, so relatively amenable to offload. For applications that offload pacing to the OS with SO_TXTIME, such as QUIC, further reduce jitter and timer wake-ups (and thus cycles) by offloading to hardware. Not only for SO_TXTIME, also for pacing initiated by the kernel TCP stack. Initially, in absence of hardware support, at least in virtual environments offload from guest to host OS.
