netdev - Re: pull request: bluetooth-next 2024-05-10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CABBYNZ+Sa1y3mvX+GpCtOUDu_0jZ9MNS69xLSHY5ShkfBuNfzA@mail.gmail.com>
Date: Fri, 7 Feb 2025 12:34:55 -0500
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: Pauli Virtanen <pav@....fi>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>, Jakub Kicinski <kuba@...nel.org>, 
	davem@...emloft.net, linux-bluetooth@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: pull request: bluetooth-next 2024-05-10

Hi Pauli,

On Thu, Feb 6, 2025 at 12:13 PM Pauli Virtanen <pav@....fi> wrote:
> AFAICS, for synchronization (only) guidance in the specification is
> (Version 6.0 | Vol 6, Part G Page 3709)
>
> """When an HCI ISO Data packet sent by the Host does not contain a
> Time_Stamp or the Time_Stamp value is not based on the Controller's
> clock, the Controller should determine the isochronous event to be used
> to transmit the SDU contained in that packet based on the time of
> arrival of that packet."""
>
> which I'm interpreting that Host should queue synchronized packets for
> different CIS to HCI at the same time. But since this seems
> implementation-defined, I don't really know what Intel firmware is
> expecting the Host to do, so maybe pull on completion works (at least
> until user app misses a wakeup).

Yeah, I think this lack the clarity on how the Controller determine
what packet got the what event, in theory the buffer count acts as the
queue, the queue is then used as jitter meaning there will be some
latency but I think that is sort of unavoidable with the way packets
are transmitted over HCI.

With this in mind I think one of the problems is that when we have
multiple connections we probably need to load balances the usage of
the controller buffers, each connection needs at least 2 buffers since
with just 1 it is possible to miss events due to the transport/bus not
being fast enough to notify number of packets complete event and then
the stack to react in time to send the next packet, so we need to have
at least 1 packet queued ahead of time.

Once we can notify the TX complete we can perhaps use it as a trigger
to send the next packet, instead of trying to do it time based like
bluetoothctl is doing nowadays, which imo is simpler and should result
in a better utilization of the controller buffers.

-- 
Luiz Augusto von Dentz