aya: Implement RingBuf #294

ishitatsuyuki · 2022-06-01T09:43:33Z

Based on @willfindlay's branch, fixed the bugs I found and it appears to be working fine for my setup.

Branch based on #290.

Closes: #12
Closes: #201

netlify · 2022-06-01T09:43:41Z

✅ Deploy Preview for aya-rs-docs ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	`52b4f44`
🔍 Latest deploy log	https://app.netlify.com/sites/aya-rs-docs/deploys/6366735d9368030008590b3e
😎 Deploy Preview	https://deploy-preview-294--aya-rs-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

ishitatsuyuki · 2022-06-01T09:45:13Z

Doing async with tokio is a little bit more verbose, but I'm doing it like this:

    loop {
        let mut guard = ring.readable_mut().await?;
        guard.get_inner_mut().process_ring(&mut |e| {
            // Do things
            Ok(())
        })?;
        guard.clear_ready();
    }

bpf/aya-bpf/src/maps/ringbuf.rs

ishitatsuyuki · 2022-06-01T13:56:48Z

Looks like this can get stuck with epoll (miss the notification somehow). I'll investigate.

ishitatsuyuki · 2022-06-01T14:25:22Z

Throwing SeqCst at the consumer pos store fixes this.

unsafe { (*self.consumer_pos_ptr).store(consumer_pos, Ordering::SeqCst) };

I'm not very good at reasoning with concurrency, but it's possible that the libbpf implementation has bogus synchronization. Cilium (Go) defaults to SeqCst, so it won't see the same issue.

EDIT: it might be due to tokio migrating the read function across thread too, while libbpf essentially assumes single thread polling.

dave-tucker

Looking good so far.
I think that in async version of this code we should - instead of using callback - use the the tx side of an mpsc channel.
i.e:

So Sender<T>

This way:

Ring processing speed is not bounded by the efficiency of callback
Ring processing is not stopped on error
We don't need to wrap user error types to return back to the caller - so no anyhow dependency

Depending on the implementation we may want to use try_send() to give errors on channel closed or buffer full

xtask/src/codegen/aya.rs

dave-tucker · 2022-06-01T13:58:19Z

aya/Cargo.toml

@@ -23,6 +23,7 @@ tokio = { version = "1.2.0", features = ["macros", "rt", "rt-multi-thread", "net
 async-std = { version = "1.9.0", optional = true }
 async-io = { version = "1.3", optional = true }
 log = "0.4"
+anyhow = "1.0.41"


I'm not sure how I feel about this...

I think the callback error handling was indeed pretty crude — I'll evaluate options that doesn't require boxing.

dave-tucker · 2022-06-01T14:09:53Z

aya/src/maps/ringbuf.rs

+    /// Returns when either the callback returns an Err or there's no more events.
+    pub fn process_ring(
+        &mut self,
+        callback: &mut dyn FnMut(&[u8]) -> Result<(), CallbackError>,


I would make callback just a FnMut(&[u8]). I don't think we ought to stop ring processing on error...
The only way to stop would be to panic in callback, which given this isn't async is probably the best we could hope for

ishitatsuyuki · 2022-06-01T14:34:48Z

Thanks for your review.

I think that in async version of this code we should - instead of using callback - use the the tx side of an mpsc channel.

Using mpsc necessitates a copy — ring processing speed isn't really the concern here, as the application has the freedom to size the ring buffer. (Also mpsc means double ring buffering — not sure that's on point.)

The only other zero-copy option would be returning a guard object that updates consumer pointer on Drop — but that's not much better I'd say.

willfindlay · 2022-06-01T23:29:31Z

Thanks for taking this over!

ishitatsuyuki · 2022-06-02T03:07:29Z

Re: the "stuck" polling issue, it's an actual upstream flaw. The ringbuf claims to be designed around acquire-release ordering but it's actually relying on sequential consistency implicitly in the kernel space, while the userspace counterpart is simply busted. Consider the following simplified example, where the "reserve" and "commit" operation is fused and simply increments the producer counter. A notification is sent if and only if the incremented producer counter == consumer counter + 1.

kernel: write p 2 -> read c X -> write p 3 -> read c 1 (X doesn't matter)
user  : write c 2 -> read p 2

With sequential consistency it's guaranteed that once p is updated from 2 to 3, c == 1 cannot be observed since the write of c == 2 precedes the read of p == 2 which must happen before the write of p = 3. However, with acq-rel there's no meaningful causal relation here at all: the relationship is only established on reads, and the read of c == 1 nor p == 2 only builds causal relationship for operations happened before the first operation in the above diagram.

And what this means is that we need a SeqCst fence after both sides of the write. For the userspace, we use a SeqCst store; but the kernel space might seem doomed. Luckily, it actually does a xchg operation to update the BUSY flag which implicitly serves as a full SeqCst barrier. Therefore, the kernel side doesn't actually need to be changed; but rather unintentionally, since the comments only suggest acq-rel relationship which is insuffcient.

ishitatsuyuki · 2022-06-03T09:02:06Z

A bunch of updates — documentation for aya-bpf, a reserve/commit API that is actually safe, and addressing review comments about process_ring error handling, plus the fix (+ a small explanation) for the awful coherence issue that I tried to figure out the right solution for days. I'll open a separate PR for the codegen soon.

ishitatsuyuki · 2022-06-03T10:04:17Z

Updated RingBufEntry to consume self on discard/submit.

ishitatsuyuki · 2022-06-03T10:13:52Z

Suppressed a clippy lint, see code for details.

dave-tucker · 2022-06-03T10:25:05Z

@ishitatsuyuki codegen changes are in main so feel free to rebase to pick those up when you're ready.
will take a look at the updates and see if I've got any review comments to add, but I think we're waiting on @alessandrod to take a look (at this and #290) before this is ok to merge.

dave-tucker · 2022-06-03T10:39:46Z

Using mpsc necessitates a copy — ring processing speed isn't really the concern here, as the application has the freedom to size the ring buffer. (Also mpsc means double ring buffering — not sure that's on point.)

The only other zero-copy option would be returning a guard object that updates consumer pointer on Drop — but that's not much better I'd say.

Having thought on this more, I agree - you're right. Different applications are going to have different requirements, some which can be met by sizing the ringbuf, data notification control etc.. Either way, the API as it stands seems flexible enough that I could do whatever I want.

ishitatsuyuki · 2022-06-09T16:13:22Z

Rebased now that the &self PR is merged.

alessandrod

This looks amazing, see comments

bpf/aya-bpf/src/maps/ringbuf.rs

aya/src/maps/ringbuf.rs

alessandrod · 2022-06-13T20:05:59Z

aya/src/maps/ringbuf.rs

+
+    /// Retrieve an event from the ring, pass it to the callback, mark it as consumed, then repeat.
+    /// Returns when there's no more events.
+    pub fn process_ring(&mut self, callback: &mut impl FnMut(&[u8])) {


Have we considered returning an iterator that consumes events instead of having a callback?

We might be able to do that, but not with an Iterator, because then we get into the streaming iterator and self reference hell.

Return a non-Iterator handle struct that mutably borrows the RingBuf will probably work, and that can be used easily with a while loop like while let Some(entry) = ringbuf.next(). The reader pointer is incremented on Drop. What do you think?

It's not immediately clear to me why it would be self referential?

Oops, it's not a self reference, but since we can't use lifetime without GATs, the entry returned from the iterator will need something like Rc that references the main RingBuf to properly work.

alessandrod · 2022-06-13T20:09:30Z

aya/src/maps/ringbuf.rs

+        })
+    }
+
+    /// Retrieve an event from the ring, pass it to the callback, mark it as consumed, then repeat.


Meta comment about docs: for consistency the format we use is the same as rust's libstd. The format is roughly:

First line describes briefly and in 3rd person what the function does. Second paragraph expands on details, mentioning in discursive form the arguments and the return value. More paragraphs might be needed to explain caveats and edge cases. # Example ...

Sentences always end with periods. Paragraphs are separated by an empty line.

I added some newlines. I don't write explanation for most of the arguments because most of the time they are the only argument and the meaning is obvious, but if you have any feedback around how docs is written in this PR, let me know.

alessandrod · 2022-06-13T20:11:33Z

Also forgot to say in the review: I think we should implement the async bits of this, like we do for perf buffers

ishitatsuyuki · 2022-06-18T02:21:30Z

On async impl: For the callback model there's not much thing we can do inside aya to support an async model (see #294 (comment)); though, if we move to an iterator-like model then it probably make sense to do that.

vadorovsky · 2022-07-25T20:07:40Z

@ishitatsuyuki Hi! Do you have time to address the remaining comments? If not, I would be happy to take over.

ishitatsuyuki · 2022-07-26T01:34:20Z

I'll try to get a revision on this later today.

ajwerner · 2023-06-19T20:59:30Z

I put up #629 as a rebase of this change and an integration test. It does not do anything towards an async API, but I agree that we should leave that for a subsequent PR.

ajwerner · 2023-07-13T02:17:52Z

@ishitatsuyuki did you ever have an example of a test program that demonstrated the epoll hang? I couldn't exactly follow your arguments enough to justify the fences in code, so I went with memory accesses like in libbpf for #629. I'd love to understand when that fails and how.

ishitatsuyuki · 2023-07-13T03:15:03Z

Make sure that the epoll fd is configured with edge trigger. Level trigger is why libbpf "accidentally" works (after a memory fence, it calls into a kernel function that tests the ring counter again).

ajwerner · 2023-07-13T18:11:52Z

Make sure that the epoll fd is configured with edge trigger. Level trigger is why libbpf "accidentally" works (after a memory fence, it calls into a kernel function that tests the ring counter again).

I am using EPOLLET (via AsyncFd, via mio here). I tried spawning many producer threads. The RingBuf is not Send, so the consumer, as far as I understand, can't move between threads. Maybe that makes it all okay? I'd love to have a repro. If you can help find one, please open an issue. I'm going to move forward with #629 as is until then.

ishitatsuyuki · 2023-07-13T18:27:16Z

Just realized I previously created a repro as described here. Please try it and let me know if this one gets stuck.

As I described at the time of investigation a SeqCst write is definitely necessary for correctness, when:

The producer is trying to skip the notification, or
The consumer is about to go into sleep.
Otherwise, cases like the example outlined in the email was fairly reproducible at the time I worked on the PR.

ishitatsuyuki · 2023-07-13T18:28:34Z

As for threads, you don't need more than one producer thread to reproduce this; this "race" can happen between just one consumer and one producer.

ajwerner · 2023-07-14T00:27:30Z

Your repro program was helpful, thanks for it. I was being saved on my side by using AtomicU32::fetch_add(&self, Release) that became lock; addl. Taking this insight, we can see that if one uses xchg (which we observe in rust with AtomicU32::store(&self, SeqCst) when writing the consumer position, then everything is good -- there's not risk that the kernel will see a stale consumer position.

I don't have a sense of the cost of these various approaches, but in general my sense is that a complete fence before sleeping is probably more expensive. What do you think?

ajwerner · 2023-07-14T01:27:43Z

I suppose that the reason the SeqCst store for the consumer offset works is because of the effective SeqCst store that occurs when the kernel clears the ready bit. If the write to the consumer offset came after the kernel had cleared the busy bit, then the consumer will see the newly produced message. If the write to the consumer offset came before the kernel had cleared the busy bit, then the read of the consumer position will see that the consumer is caught up.

ishitatsuyuki · 2023-07-14T02:55:29Z

In general on x86 I consider any instruction with the lock prefix to have a similar "base" cost, as they serialize memory access by acting as a barrier. (That said, do note that contended atomics can be far more expensive.) Using fetch_add means that we pay that cost on every position update; while with a memory barrier before sleep, we only pay that cost once per sleep.

Aside, relying on atomic release RMW to provide SeqCst semantics is technically an ill assumption (iirc AcqRel RMW is actually equivalent to SeqCst even in the spec).

This patch fixes enhances the synchronization between libbpf and the producer in the kernel so that notifications cannot be lost because the producer reads a stale view of the consumer position while the consumer also reads a stale view of either the producer position or the header. The problem before this change was that nothing enforced a happens before relationship between either of the writes and the subsequent reads. The use of a sequentially consistent write ensures that the write to the consumer position is either ordered before the producer clears the busy bit, in which case the producer will see that the consumer caught up, or the write will occur after the producer has cleared the busy bit, in which case the new message will be visible. All of this is in service of using EPOLLET, which will perform fewer wakeups and generally less work. This is borne out in the benchmark data below. Note that without the atomics change, the use of EPOLLET does not work, and the benchmarks and tests show it. The below raw benchmarks are below (I've omitted the irrelevant ones for brevity). The benchmarks were run on a 32-thread AMD Ryzen 9 7950X 16-Core Processor. The summary of the results is that the producer is that in almost all cases, the benchmarks are substantially improved. The only case which seems worse is "Ringbuf sampled, reserve+commit vs output", for the "reserve" case. I guess this makes sense because the consumer piece is more expensive, and the sampled notifications mean there's not a lot of time interacting with epoll. Credit for the discovery of the bug[1] and guidance on how to fix it[2] belong to Tatsuyuki Ishi <ishitatsuyuki@gmail.com>. New: ``` Single-producer, parallel producer ================================== rb-libbpf 43.366 ± 0.277M/s (drops 0.848 ± 0.027M/s) Single-producer, parallel producer, sampled notification ======================================================== rb-libbpf 41.163 ± 0.031M/s (drops 0.000 ± 0.000M/s) Single-producer, back-to-back mode ================================== rb-libbpf 60.671 ± 0.274M/s (drops 0.000 ± 0.000M/s) rb-libbpf-sampled 59.229 ± 0.422M/s (drops 0.000 ± 0.000M/s) Ringbuf back-to-back, effect of sample rate =========================================== rb-sampled-1 1.507 ± 0.004M/s (drops 0.000 ± 0.000M/s) rb-sampled-5 7.095 ± 0.016M/s (drops 0.000 ± 0.000M/s) rb-sampled-10 13.091 ± 0.046M/s (drops 0.000 ± 0.000M/s) rb-sampled-25 26.259 ± 0.061M/s (drops 0.000 ± 0.000M/s) rb-sampled-50 39.831 ± 0.122M/s (drops 0.000 ± 0.000M/s) rb-sampled-100 51.536 ± 2.984M/s (drops 0.000 ± 0.000M/s) rb-sampled-250 67.850 ± 1.267M/s (drops 0.000 ± 0.000M/s) rb-sampled-500 75.257 ± 0.438M/s (drops 0.000 ± 0.000M/s) rb-sampled-1000 74.939 ± 0.295M/s (drops 0.000 ± 0.000M/s) rb-sampled-2000 81.481 ± 0.769M/s (drops 0.000 ± 0.000M/s) rb-sampled-3000 82.637 ± 0.448M/s (drops 0.000 ± 0.000M/s) Ringbuf back-to-back, reserve+commit vs output ============================================== reserve 78.142 ± 0.104M/s (drops 0.000 ± 0.000M/s) output 68.418 ± 0.032M/s (drops 0.000 ± 0.000M/s) Ringbuf sampled, reserve+commit vs output ========================================= reserve-sampled 30.577 ± 2.122M/s (drops 0.000 ± 0.000M/s) output-sampled 30.075 ± 1.089M/s (drops 0.000 ± 0.000M/s) Single-producer, consumer/producer competing on the same CPU, low batch count ============================================================================= rb-libbpf 0.570 ± 0.004M/s (drops 0.000 ± 0.000M/s) Ringbuf, multi-producer contention ================================== rb-libbpf nr_prod 1 44.359 ± 0.319M/s (drops 0.091 ± 0.027M/s) rb-libbpf nr_prod 2 23.722 ± 0.024M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 3 14.128 ± 0.011M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 4 14.896 ± 0.020M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 8 6.056 ± 0.061M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 12 4.612 ± 0.042M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 16 4.684 ± 0.040M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 20 5.007 ± 0.046M/s (drops 0.001 ± 0.004M/s) rb-libbpf nr_prod 24 5.207 ± 0.093M/s (drops 0.006 ± 0.013M/s) rb-libbpf nr_prod 28 4.951 ± 0.073M/s (drops 0.030 ± 0.069M/s) rb-libbpf nr_prod 32 4.509 ± 0.069M/s (drops 0.582 ± 0.057M/s) rb-libbpf nr_prod 36 4.361 ± 0.064M/s (drops 0.733 ± 0.126M/s) rb-libbpf nr_prod 40 4.261 ± 0.049M/s (drops 0.713 ± 0.116M/s) rb-libbpf nr_prod 44 4.150 ± 0.207M/s (drops 0.841 ± 0.191M/s) rb-libbpf nr_prod 48 4.033 ± 0.064M/s (drops 1.009 ± 0.082M/s) rb-libbpf nr_prod 52 4.025 ± 0.049M/s (drops 1.012 ± 0.069M/s) ``` Old: ``` Single-producer, parallel producer ================================== rb-libbpf 20.755 ± 0.396M/s (drops 0.000 ± 0.000M/s) Single-producer, parallel producer, sampled notification ======================================================== rb-libbpf 29.347 ± 0.087M/s (drops 0.000 ± 0.000M/s) Single-producer, back-to-back mode ================================== rb-libbpf 60.791 ± 0.188M/s (drops 0.000 ± 0.000M/s) rb-libbpf-sampled 60.125 ± 0.207M/s (drops 0.000 ± 0.000M/s) Ringbuf back-to-back, effect of sample rate =========================================== rb-sampled-1 1.534 ± 0.006M/s (drops 0.000 ± 0.000M/s) rb-sampled-5 7.062 ± 0.029M/s (drops 0.000 ± 0.000M/s) rb-sampled-10 13.093 ± 0.107M/s (drops 0.000 ± 0.000M/s) rb-sampled-25 26.292 ± 0.118M/s (drops 0.000 ± 0.000M/s) rb-sampled-50 40.230 ± 0.030M/s (drops 0.000 ± 0.000M/s) rb-sampled-100 54.123 ± 0.334M/s (drops 0.000 ± 0.000M/s) rb-sampled-250 66.054 ± 0.282M/s (drops 0.000 ± 0.000M/s) rb-sampled-500 76.130 ± 0.648M/s (drops 0.000 ± 0.000M/s) rb-sampled-1000 80.531 ± 0.169M/s (drops 0.000 ± 0.000M/s) rb-sampled-2000 83.170 ± 0.376M/s (drops 0.000 ± 0.000M/s) rb-sampled-3000 83.702 ± 0.046M/s (drops 0.000 ± 0.000M/s) Ringbuf back-to-back, reserve+commit vs output ============================================== reserve 77.829 ± 0.178M/s (drops 0.000 ± 0.000M/s) output 67.974 ± 0.153M/s (drops 0.000 ± 0.000M/s) Ringbuf sampled, reserve+commit vs output ========================================= reserve-sampled 33.925 ± 0.101M/s (drops 0.000 ± 0.000M/s) output-sampled 30.610 ± 0.070M/s (drops 0.000 ± 0.000M/s) Single-producer, consumer/producer competing on the same CPU, low batch count ============================================================================= rb-libbpf 0.565 ± 0.002M/s (drops 0.000 ± 0.000M/s) Ringbuf, multi-producer contention ================================== rb-libbpf nr_prod 1 18.486 ± 0.067M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 2 22.009 ± 0.023M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 3 11.908 ± 0.023M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 4 11.302 ± 0.031M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 8 5.799 ± 0.032M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 12 4.296 ± 0.008M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 16 4.248 ± 0.005M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 20 4.530 ± 0.032M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 24 4.607 ± 0.012M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 28 4.470 ± 0.017M/s (drops 0.002 ± 0.007M/s) rb-libbpf nr_prod 32 4.348 ± 0.051M/s (drops 0.703 ± 0.072M/s) rb-libbpf nr_prod 36 4.248 ± 0.062M/s (drops 0.603 ± 0.102M/s) rb-libbpf nr_prod 40 4.227 ± 0.051M/s (drops 0.805 ± 0.053M/s) rb-libbpf nr_prod 44 4.100 ± 0.049M/s (drops 0.828 ± 0.063M/s) rb-libbpf nr_prod 48 4.056 ± 0.065M/s (drops 0.922 ± 0.083M/s) rb-libbpf nr_prod 52 4.051 ± 0.053M/s (drops 0.935 ± 0.093M/s) ``` [1]: https://lore.kernel.org/bpf/CANqewP1RFzD9TWgyyZy00ZVQhQr8QjmjUgyaaNK0g0_GJse=KA@mail.gmail.com/#r [2]: aya-rs/aya#294 (comment)

mergify · 2023-09-14T23:50:52Z

@ishitatsuyuki, this pull request is now in conflict and requires a rebase.

brevilo · 2023-10-12T08:04:04Z

Seems like this PR is obsolete now that #629 got merged, no?

ishitatsuyuki force-pushed the ringbuf branch from 0672d20 to 9fb0403 Compare June 1, 2022 09:44

ishitatsuyuki force-pushed the ringbuf branch from 9fb0403 to 977a59e Compare June 1, 2022 09:57

ishitatsuyuki commented Jun 1, 2022

View reviewed changes

bpf/aya-bpf/src/maps/ringbuf.rs Outdated Show resolved Hide resolved

dave-tucker requested changes Jun 1, 2022

View reviewed changes

ishitatsuyuki force-pushed the ringbuf branch from 977a59e to e13f586 Compare June 3, 2022 08:57

ishitatsuyuki mentioned this pull request Jun 3, 2022

Codegen changes for RingBuf #295

Merged

ishitatsuyuki force-pushed the ringbuf branch from e13f586 to 3a67f75 Compare June 3, 2022 10:03

ishitatsuyuki force-pushed the ringbuf branch from 3a67f75 to c396f26 Compare June 3, 2022 10:13

ishitatsuyuki force-pushed the ringbuf branch 2 times, most recently from 40969bc to 7656849 Compare June 9, 2022 16:13

alessandrod requested changes Jun 13, 2022

View reviewed changes

ishitatsuyuki force-pushed the ringbuf branch 2 times, most recently from f32ee79 to c16591a Compare June 18, 2022 02:20

ajwerner mentioned this pull request Jun 19, 2023

aya,aya-ebpf: implement RingBuf #629

Merged

mergify bot added aya This is about aya (userspace) aya-bpf This is about aya-bpf (kernel) labels Sep 14, 2023

mergify bot added the needs-rebase label Sep 14, 2023

ajwerner closed this Oct 12, 2023

mergify bot removed the needs-rebase label Oct 12, 2023

aya: Implement RingBuf #294

aya: Implement RingBuf #294

Conversation

ishitatsuyuki commented Jun 1, 2022 • edited

netlify bot commented Jun 1, 2022 • edited

✅ Deploy Preview for aya-rs-docs ready!

ishitatsuyuki commented Jun 1, 2022 • edited

ishitatsuyuki commented Jun 1, 2022

ishitatsuyuki commented Jun 1, 2022 • edited

dave-tucker left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ishitatsuyuki commented Jun 1, 2022

willfindlay commented Jun 1, 2022

ishitatsuyuki commented Jun 2, 2022

ishitatsuyuki commented Jun 3, 2022 • edited

ishitatsuyuki commented Jun 3, 2022

ishitatsuyuki commented Jun 3, 2022

dave-tucker commented Jun 3, 2022 • edited

dave-tucker commented Jun 3, 2022

ishitatsuyuki commented Jun 9, 2022

alessandrod left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alessandrod commented Jun 13, 2022

ishitatsuyuki commented Jun 18, 2022

vadorovsky commented Jul 25, 2022

ishitatsuyuki commented Jul 26, 2022

ajwerner commented Jun 19, 2023

ajwerner commented Jul 13, 2023

ishitatsuyuki commented Jul 13, 2023

ajwerner commented Jul 13, 2023

ishitatsuyuki commented Jul 13, 2023

ishitatsuyuki commented Jul 13, 2023 • edited

ajwerner commented Jul 14, 2023

ajwerner commented Jul 14, 2023

ishitatsuyuki commented Jul 14, 2023

mergify bot commented Sep 14, 2023

brevilo commented Oct 12, 2023

ishitatsuyuki commented Jun 1, 2022 •

edited

netlify bot commented Jun 1, 2022 •

edited

ishitatsuyuki commented Jun 1, 2022 •

edited

ishitatsuyuki commented Jun 1, 2022 •

edited

ishitatsuyuki commented Jun 3, 2022 •

edited

dave-tucker commented Jun 3, 2022 •

edited

ishitatsuyuki commented Jul 13, 2023 •

edited