Closed jonas-schievink closed 4 years ago
8b62569 uses a fork that includes https://github.com/jamesmunns/bbqueue/pull/33. We should move back to the upstream repo or a crates.io release as soon as we can.
@jonas-schievink is this something that would be fixed by https://github.com/jamesmunns/bbqueue/pull/37?
Or do you need one of the proposed grants at https://github.com/jamesmunns/bbqueue/issues/38, maybe grant_largest
or grant_largest_max
?
@jamesmunns Does grant_max_remaining
now work as documented? If so then that's all I need.
Ah no, good catch! It works as documented at the module level (see https://docs.rs/bbqueue/0.4.0-alpha5/bbqueue/atomic/struct.Producer.html), but it is a little vague at the function level, which I will be fixing. For reference:
grant_max_remaining(N)
:
0 < sz <= N
(or receive an error)I think you actually want grant_largest_max()
, which will cause a wraparound if the requested space is NOT available at the end, but IS available at the beginning.
I need to come up with a consistent naming scheme, but in general:
remaining
methods do NOT cause premature wrapslargest
methods MAY cause premature wrapsmax
methods limit the upper bound of grantable sizeI think you actually want
grant_largest_max()
, which will cause a wraparound if the requested space is NOT available at the end, but IS available at the beginning.
The only remaining use of bbqueue is in the logging utilities, which should be fine with getting a small buffer first, and then wrap around and get another buffer. It will only "fail" (it will consider data to be lost) if the function returns Err
.
I also plan to offer split grants in the future, which will give you the buf at the start and end, so you can decide at once if there is enough space, but I haven't put any detailed design or dev into that, planning on doing that post 0.4.0.
Fixed by #100
As discovered in https://github.com/jonas-schievink/rubble/pull/64, bbqueue's
grant_max
doesn't work as documented (https://github.com/jamesmunns/bbqueue/issues/29), so our usage of it is wrong and can lead to packet processing stalling.This either needs a
documentationfix and additional methods in bbqueue, or we should switch to a different queue. Ideally, that queue would also support thumbv6 while still having efficient batch operations.