Hi Ilya, I am working on Antrea, which has a strong dependency on Windows OVS. We are now expecting to bump up our Windows Node OS version from Server 2019 to Server 2022. During this work, we found the Windows BSoD issue happened very frequently on Server 2022. And now it is a blocker to run OVS on Windows Server 2022
We have tried Wilson's patch on our local testbed, and it can resolve the BSoD issue. The patch is in the "review" status for a long time, and it seems you have a different preference on how to parse the IP Header rather than Windows API "NdisGetDataBuffer". May I know what your concern is? If the thing is about the choices on Windows APIs, I find that " NdisGetDataBuffer" is called not only in the place where the bugfix is referred, then it means even if switching to your suggested function doesn't completely replace the API calls, and some other change is still needed for the purpose. Then is it possible to merge the patch to unblock running OVS on Windows Server 2022 first, then the OVS community can use another change to unify the API calls at one time? Best, Wenying On Wed, Jul 17, 2024 at 8:10 PM Ilya Maximets <[email protected]> wrote: > On 7/17/24 13:42, Wilson Peng via dev wrote: > > From: Wilson Peng <[email protected]> > > > > NdisGetDataBuffer() is called without providing a buffer to copy packet > > data in case it is not contiguous. So, it fails in some scenarios > > where the packet is handled by the general network stack before OVS > > and headers become split in multiple buffers. > > > > In the fix it will supply the stack buffer to copy packet data when > > call NdisGetDataBuffer(). > > > > In the conntrack Action process, it will do OvsPartialCopyNBL firstly > > with the size of layers l7offsets. If the header is split the header > > will be merged to one continuous buffer. > > > > But IPV6 traffic is not handed in this case. > > > > Reported-at: https://github.com/openvswitch/ovs-issues/issues/323 > > Signed-off-by: Wilson Peng <[email protected]> > > --- > > datapath-windows/ovsext/Actions.c | 7 +++++++ > > datapath-windows/ovsext/BufferMgmt.c | 16 +++++++++++++--- > > datapath-windows/ovsext/Conntrack.c | 4 +++- > > datapath-windows/ovsext/IpFragment.c | 8 ++++++-- > > 4 files changed, 29 insertions(+), 6 deletions(-) > > Hi, Wilson. Thanks for the patch! > > Though I wonder why are we using NdisGetDataBuffer directly at all? > We have helper functions OvsGetTcp or OvsGetPacketBytes and these > should be able to handle non-contiguous memory. I tried to use them > in my previous attempt to fix this issue here: > > https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/ > Though I definitely missed a few places and so the patch doesn't work > in its current form. > > Best regards, Ilya Maximets. > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
