Protocol/Miniport negotiation with OID_TCP_TASK_OFFLOAD

NTDEV
1

In my NDIS 5.0 Miniport, after initialization I’m queried by the protocol stack with OID_TCP_TASK_OFFLOAD where I’m being asked what sort of checksumming I do via hardware. I respond by saying that I do everything receive side. The protocol stack then calls the Set side of OID_TCP_TASK_OFFLOAD and enables offload checksumming for TCP and IP, but not UDP. Why does the protocol stack insist on checksumming UDP regardless of hardware checksumming? Is there a way to modify this behavior?

2

The protocol stack does not support UDP checksum until Vista.
JJ
wrote in message news:xxxxx@ntdev…
> In my NDIS 5.0 Miniport, after initialization I’m queried by the protocol
> stack with OID_TCP_TASK_OFFLOAD where I’m being asked what sort of
> checksumming I do via hardware. I respond by saying that I do everything
> receive side. The protocol stack then calls the Set side of
> OID_TCP_TASK_OFFLOAD and enables offload checksumming for TCP and IP, but
> not UDP. Why does the protocol stack insist on checksumming UDP
> regardless of hardware checksumming? Is there a way to modify this
> behavior?
>

3

Does that mean it insists upon calculating the checksum? All of my inbound UDP packets get dropped, presumably because the stack IS calculating the checksum and finding that the one built into the packet is incorrect. I’d have to recheck, but I was pretty sure that outgoing packets already had a proper checksum by the time they hit my miniport.

4

It does mean that it will insist on calculating the checksum. Something that
may work however is if you were to essentially ignore the
OID_TCP_TASK_OFFLOAD setting with regards to UDP receive checksum, allow the
hardware to perform the checksum, and then set the appropriate bit in the
NDIS_TCP_IP_CHECKSUM_PACKET_INFO area of all incoming UDP packets. The
protocol stack may then skip the checksum operation. This may help with
regards to performance. Keep in mind that this may cause problems with WHQL
however.

I sort of doubt that the packets are being rejected because your hardware is
calculating the checksum.

Thanks,
JJ

wrote in message news:xxxxx@ntdev…
> Does that mean it insists upon calculating the checksum? All of my
> inbound UDP packets get dropped, presumably because the stack IS
> calculating the checksum and finding that the one built into the packet is
> incorrect. I’d have to recheck, but I was pretty sure that outgoing
> packets already had a proper checksum by the time they hit my miniport.
>

5

Thanks JJ… There is no hardware though, it’s a couple of virtual machines trying to talk to each other without packets ever leaving the box. I’ll try to mess with the NDIS_TCP_IP_CHECKSUM_PACKET_INFO and see if I can get anywhere with that…

Thanks for your insight
Steve

6

Are your packets being fragmented? Please note that if this is the case, than the (UDP) checksum is being calculated only once, and is being checked after the re-assembly.

Another thing to note is this:
What are you seeting in:
NDIS_PER_PACKET_INFO_FROM_PACKET(NdisPacket, TcpIpChecksumPacketInfo)

Thanks
Tzachi

7

Hi Tzachi, since I’m the miniport I’m actually setting the bits in the TcpIpChecksumPacketInfo.
pPacketChecksumInfo=(PNDIS_TCP_IP_CHECKSUM_PACKET_INFO)&(ULONG_PTR)NDIS_PER_PACKET_INFO_FROM_PACKET(pInternal->ppReceivePackets[rx->id], TcpIpChecksumPacketInfo);
*((PULONG)pPacketChecksumInfo)=0;
pPacketChecksumInfo->Receive.NdisPacketIpChecksumSucceeded=1;
pPacketChecksumInfo->Receive.NdisPacketTcpChecksumSucceeded=1;
pPacketChecksumInfo->Receive.NdisPacketUdpChecksumSucceeded=1;

From what others have said, it would seem that the protocol driver verifies the checksum in the UDP case regardless of these flags…

Thanks,
Steve