Hi, to, 2025-02-20 kello 18:19 -0500, Willem de Bruijn kirjoitti: > Willem de Bruijn wrote: [clip] > > > > Reclaiming space is really up to whoever needs it. > > > > I'll take a quick look, just to see if there is an obvious path and > > we can postpone this whole conversation to next time we need a bit. > > SKBTX_HW_TSTAMP_USE_CYCLES is only true if SOF_TIMESTAMPING_BIND_PHC. > It cannot be set per cmsg (is not in SOF_TIMESTAMPING_TX_RECORD_MASK), > so no need to record it per skb. > > It only has two drivers using it, which can easily be updated: > > - if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP_USE_CYCLES) > + if (skb->sk && > + READ_ONCE(sk->sk_tsflags) & SOF_TIMESTAMPING_BIND_PHC) > tx_flags |= IGC_TX_FLAGS_TSTAMP_TIMER_1; > > They later call skb_tstamp_tx, which does nothing if !skb->sk. > Only cost is a higher cost of accessing the sk cacheline. > > SKBTX_WIFI_STATUS essentially follows the same argument. It can only > be set in the sockopt. It has a handful more callsites that would need > to be updated. sock_flag(sk, SOCK_WIFI_STATUS) will be tested without > the socket lock held. But this is already the case in the UDP lockless > fast path through ip_make_skb. > > SKBTX_HW_TSTAMP_NETDEV is only used on Rx. Could shadow another bit > that is used only on Tx. > > SKBTX_IN_PROGRESS is only used by the driver to suppress the software > tx timestamp from skb_tx_timestamp if a later hardware timestamp will > be generated. Predates SOF_TIMESTAMPING_OPT_TX_SWHW. > > In short plenty of bits we can reclaim if we try. > > SKBTX_BPF was just merged, so we will have to reclaim one. The first > one seems most straightforward. Ok, I'll go back to tx_flags bit for v5 (= v3 + the minor cleanups), going on top of "net: skb: free up one bit in tx_flags" then. -- Pauli Virtanen
