Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

LSO or RSC enabled even if Checksum offload is disabled

ronakdoshironakdoshi Member Posts: 6

Hi Team,

I had a query regarding LSO and RSC features. These features allow the OS to send and receive large TCP packets (> mtu) by offloading the processing to the nic. My understanding is for these features checksum offload should be enabled. When checksum offload is disabled, these features should be disabled and OS will segment the packets and send further. However, I have noticed that when checksum offload is disabled, LSO or RSC features are not disabled automatically. I still do see large packets being received with checksum offloaded.

The above link mentions that LSO/RSC will be disabled when checksum offload is disabled. But, this does not happen. Is this a bug in windows Or it is expected that miniport drivers will handle it? Or they expect user should disable LSO/RSC when disabling checksum offloads. Any pointers will be appreciated.

PS: On linux, when tx checksum is disabled TSO is automatically disabled which is what makes sense.



  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,251

    Call for Mr. Tippet... Mr. Tippet, please come to the white courtesy phone... Mr. J Tippet...


    Peter Viscarola

  • Jeffrey_Tippet_[MSFT]Jeffrey_Tippet_[MSFT] Member - All Emails Posts: 520
    edited September 2018

    Mr Viscarola appears to be laboring under the mistaken belief that repeating my name 3 times has magical summoning powers. In truth, the magical summoning powers are properly attributed to changing the mailing list and breaking my mail client's rules.

    As you've already pointed out, it logically doesn't make sense to disable checksum offload (CSO), yet still attempt to coalesce or segment packets. NDIS itself doesn't attempt to block this configuration. Perhaps it should have a guardrail here, but I'm too timid to change behavior that's been like this for years. (Presumably there are 1000's of customers who have carefully loaded the footgun, aimed downward, and disabled CSO.)

    There's a principled argument to be made that if you are in this awkward position, you should obstinately perform segmentation without fixing up the checksum. But that's almost certainly not what our mutual customers want. So in the spirit of "do what the customers want", here's my guidance for a NIC driver.

    Assume NdisReadConfiguration reports that CSO is disabled, but LSO/RSC is enabled.

    During initialization:

    • Do not advertise CSO capability.
    • Advertise LSO/RSC capability.

    When transmitting packets:

    • Do not look for the checksum NBL info field.
    • Do not write out a new checksum.
    • Look for the LSO info field. If it requests LSO, perform the segmentation and fix the checksums of the segmented frames.

    When receiving packts:

    • Do not attempt to validate the checksum unconditionally. (It's harmless if you do, though.)
    • If you do perform coalescing, validate the checksum, and put the result into each received packet.

    For any sysadmins that stumble across this post: LSO and RSC implicitly use CSO. So don't disable CSO unless you also disable LSO and RSC.

  • ronakdoshironakdoshi Member Posts: 6

    Great. Thanks for your help Jeffrey.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA