On 8/5/24 08:37, Wenying Dong wrote: > 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?
Hi, Wenying. The thing about API call is that we have a group of helper functions that supposed to abstract this kind of header accesses and ideally we should use those instead of accessing headers directly. In general, it seems OK to get the change as-is without moving to those helpers. The main problem I have is that I have no real way to test Windows driver code and so I'm not comfortable merging it. Alin planned to look at the currently under-review windows patches. Hopefully he can get to them this week. If not, I can consider applying these patches myself, but I'll be fully relying on your testing, which may be OK, since you're the main and possibly the only users of the Windows datapath. But it's still not the best option since we don't have any kind of CI, except for checking that it compiles. Best regards, Ilya Maximets. > > Best, > Wenying > > On Wed, Jul 17, 2024 at 8:10 PM Ilya Maximets <[email protected] > <mailto:[email protected]>> wrote: > > On 7/17/24 13:42, Wilson Peng via dev wrote: > > From: Wilson Peng <[email protected] <mailto:[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 > <https://github.com/openvswitch/ovs-issues/issues/323> > > Signed-off-by: Wilson Peng <[email protected] > <mailto:[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]/ > > <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
