| Message ID | 20240912171251.937743-1-sdf@fomichev.me (mailing list archive) |
|---|---|
| Headers | show |
| Series | selftests: ncdevmem: Add ncdevmem to ksft | expand |
On 09/12, Stanislav Fomichev wrote: > The goal of the series is to simplify and make it possible to use > ncdevmem in an automated way from the ksft python wrapper. > > ncdevmem is slowly mutated into a state where it uses stdout > to print the payload and the python wrapper is added to > make sure the arrived payload matches the expected one. Mina, what's your plan/progress on the upstreamable TX side? I hope you're still gonna finish it up? I have a PoC based on your old RFC over here (plus all the selftests to verify it). I also have a 'loopback' mode to test/verify UAPI parts on qemu without real HW. Should I post it as an RFC once the merge window closes? Or maybe send it off list? I don't intent to push those patches further. If you already have the implementation on your side, maybe at least the selftests will be helpful to reuse?
On Thu, Sep 12, 2024 at 12:48 PM Stanislav Fomichev <stfomichev@gmail.com> wrote: > > On 09/12, Stanislav Fomichev wrote: > > The goal of the series is to simplify and make it possible to use > > ncdevmem in an automated way from the ksft python wrapper. > > > > ncdevmem is slowly mutated into a state where it uses stdout > > to print the payload and the python wrapper is added to > > make sure the arrived payload matches the expected one. > > Mina, what's your plan/progress on the upstreamable TX side? I hope > you're still gonna finish it up? > I'm very open to someone pushing the TX side, but there is a bit of a need here to get the TX side done sooner than later. In reality I don't think anyone cares as much as me to push this ASAP so I plan/hope to look into it. I have made some progress but a bit to be worked through at the moment. I hope to have something ready as the merge window reopens; very likely doable. > I have a PoC based on your old RFC over here (plus all the selftests to > verify it). I also have a 'loopback' mode to test/verify UAPI parts on qemu > without real HW. > This sounds excellent. Where is here? Is there a link missing? I'm happy to push those patches forward, giving you full credit of course (either signed-off-by both of us or 'Based on work by stfomichev@gmail.com' etc). > Should I post it as an RFC once the merge window closes? Or maybe send > it off list? I don't intent to push those patches further. If you already > have the implementation on your side, maybe at least the selftests will be > helpful to reuse? Everything would be useful to reuse. Thank you very much, this is amazing. BTW, I was planning on looking into both TX and improving tests and you have looked into both, which is amazing, thank you. Would you Pavel/David/Taehee others would be interested in, say, a monthly face-to-face call to discuss future work? I am under the impression Taehee will push devmem support for bnxt and Pavel for io uring ZC, so we may have a bunch of details to discuss. Any sync would be hosted on bbb, public to anyone to join. No pressure, of course. Communicating on-list via email has worked so far, so in a sense there is no reason to change things :D
On 09/12, Mina Almasry wrote: > On Thu, Sep 12, 2024 at 12:48 PM Stanislav Fomichev > <stfomichev@gmail.com> wrote: > > > > On 09/12, Stanislav Fomichev wrote: > > > The goal of the series is to simplify and make it possible to use > > > ncdevmem in an automated way from the ksft python wrapper. > > > > > > ncdevmem is slowly mutated into a state where it uses stdout > > > to print the payload and the python wrapper is added to > > > make sure the arrived payload matches the expected one. > > > > Mina, what's your plan/progress on the upstreamable TX side? I hope > > you're still gonna finish it up? > > > > I'm very open to someone pushing the TX side, but there is a bit of a > need here to get the TX side done sooner than later. In reality I > don't think anyone cares as much as me to push this ASAP so I > plan/hope to look into it. I have made some progress but a bit to be > worked through at the moment. I hope to have something ready as the > merge window reopens; very likely doable. Perfect! > > I have a PoC based on your old RFC over here (plus all the selftests to > > verify it). I also have a 'loopback' mode to test/verify UAPI parts on qemu > > without real HW. > > > > This sounds excellent. Where is here? Is there a link missing? > > I'm happy to push those patches forward, giving you full credit of > course (either signed-off-by both of us or 'Based on work by > stfomichev@gmail.com' etc). Great, let me clean them up a bit and I'll post an RFC to the list for you to take over sometime tomorrow (or ignore or whatever). Didn't want to send out anything without asking you first.. And this will be based on top of this series. > > Should I post it as an RFC once the merge window closes? Or maybe send > > it off list? I don't intent to push those patches further. If you already > > have the implementation on your side, maybe at least the selftests will be > > helpful to reuse? > > Everything would be useful to reuse. Thank you very much, this is amazing. > > BTW, I was planning on looking into both TX and improving tests and > you have looked into both, which is amazing, thank you. Would you > Pavel/David/Taehee others would be interested in, say, a monthly > face-to-face call to discuss future work? I am under the impression > Taehee will push devmem support for bnxt and Pavel for io uring ZC, so > we may have a bunch of details to discuss. > > Any sync would be hosted on bbb, public to anyone to join. > > No pressure, of course. Communicating on-list via email has worked so > far, so in a sense there is no reason to change things :D If you think it's helpful to coordinate - sure! Doing something once a month is not a huge commitment :-D Set the dates and send out a link.