Jakub Kicinski wrote: > On Mon, 13 May 2024 18:09:31 -0400 Luiz Augusto von Dentz wrote: > > > There is one more warning in the Intel driver: > > > > > > drivers/bluetooth/btintel_pcie.c:673:33: warning: symbol 'causes_list' > > > was not declared. Should it be static? > > > > We have a fix for that but I was hoping to have it in before the merge > > window and then have the fix merged later. > > > > > It'd also be great to get an ACK from someone familiar with the socket > > > time stamping (Willem?) I'm not sure there's sufficient detail in the > > > commit message to explain the choices to: > > > - change the definition of SCHED / SEND to mean queued / completed, > > > while for Ethernet they mean queued to qdisc, queued to HW. > > > > hmm I thought this was hardware specific, it obviously won't work > > exactly as Ethernet since it is a completely different protocol stack, > > or are you suggesting we need other definitions for things like TX > > completed? > > I don't know anything about queuing in BT, in terms of timestamping > the SEND - SCHED difference is supposed to indicate the level of > host delay or host congestion. If the queuing in BT happens mostly in > the device HW queue then it may make sense to generate SCHED when > handing over to the driver. OTOH if the devices can coalesce or delay > completions the completion timeout may be less accurate than stamping > before submitting to HW... I'm looking for the analysis that the choices > were well thought thru. SCM_TSTAMP_SND is taken before an skb is passed to the device. This matches request SOF_TIMESTAMPING_TX_SOFTWARE. A timestamp returned on transmit completion is requested as SOF_TIMESTAMPING_TX_HARDWARE. We do not have a type for a software timestamp taken at tx completion cleaning. If anything, I would think it would be a passes as a hardware timestamp. Returning SCHED when queuing to a device and SND later on receiving completions seems like not following SO_TIMESTAMPING convention to me. But I don't fully know the HCI model. As for the "experimental" BT_POLL_ERRQUEUE. This is an addition to the ABI, right? So immutable. Is it fair to call that experimental? It might be safer to only suppress the sk_error_report in sock_queue_err_skb. Or at least in bt_sock_poll to check the type of all outstanding errors and only suppress if all are timestamps.
