Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-4580-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Mon, 13 May 2024 21:32:24 -0400
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>, 
 Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>, 
 davem@davemloft.net, 
 linux-bluetooth@vger.kernel.org, 
 netdev@vger.kernel.org, 
 Pauli Virtanen <pav@iki.fi>
Message-ID: <6642bf28469d6_203b4c294bc@willemb.c.googlers.com.notmuch>
In-Reply-To: <20240513154332.16e4e259@kernel.org>
References: <20240510211431.1728667-1-luiz.dentz@gmail.com>
 <20240513142641.0d721b18@kernel.org>
 <CABBYNZKn5YBRjj+RT_TVDtjOBS6V_H7BQmFMufQj-cOTC=RXDA@mail.gmail.com>
 <20240513154332.16e4e259@kernel.org>
Subject: Re: pull request: bluetooth-next 2024-05-10
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: 7bit

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.