On Wed, Dec 9, 2020 at 10:25 AM Geva, Erez <erez.geva.ext@xxxxxxxxxxx> wrote: > > > On 09/12/2020 15:48, Willem de Bruijn wrote: > > On Wed, Dec 9, 2020 at 9:37 AM Erez Geva <erez.geva.ext@xxxxxxxxxxx> wrote: > >> > >> Configure and send TX sending hardware timestamp from > >> user space application to the socket layer, > >> to provide to the TC ETC Qdisc, and pass it to > >> the interface network driver. > >> > >> - New flag for the SO_TXTIME socket option. > >> - New access auxiliary data header to pass the > >> TX sending hardware timestamp. > >> - Add the hardware timestamp to the socket cookie. > >> - Copy the TX sending hardware timestamp to the socket cookie. > >> > >> Signed-off-by: Erez Geva <erez.geva.ext@xxxxxxxxxxx> > > > > Hardware offload of pacing is definitely useful. > > > Thanks for your comment. > I agree, it is not limited of use. > > > I don't think this needs a new separate h/w variant of SO_TXTIME. > > > I only extend SO_TXTIME. The patchset passes a separate timestamp from skb->tstamp along through the ip cookie, cork (transmit_hw_time) and with the skb in shinfo. I don't see the need for two timestamps, one tied to software and one to hardware. When would we want to pace twice? > > Indeed, we want pacing offload to work for existing applications. > > > As the conversion of the PHC and the system clock is dynamic over time. > How do you propse to achive it? Can you elaborate on this concern? The simplest solution for offloading pacing would be to interpret skb->tstamp either for software pacing, or skip software pacing if the device advertises a NETIF_F hardware pacing feature. Clockbase is an issue. The device driver may have to convert to whatever format the device expects when copying skb->tstamp in the device tx descriptor. > > > 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. Btw: this is quite a long list of CC:s
