none
NDIS Tx Flow Control RRS feed

  • Question

  • Hi All,

    I am developing a wireless network driver. Most of it is now developed and it can Tx/Rx at speeds up to 30MBps.

    My current problem, is that I cannot find the function will will block the function MPSendNetBufferLists.

    Say that an application is asking for 40MBps and I can only support 30MBps. How can I stop the OS from sending new packets to be transmitted if my queues are getting filled up?

    Tuesday, November 17, 2015 9:42 AM

Answers

  • It's very simple, you just don't do this. You only have to properly indicate completion of TX, so that protocols can track how many packets are outstanding. And don't forget to indicate the actual (or estimated) link throughput.

    If your driver or device have some "hard limit" for number of in-flight packets, and upper layers still send you more, you'll have to drop these packets and indicate send error.

    -- pa

     
    Tuesday, November 17, 2015 11:39 AM

All replies

  • Hi Pavel,

    Many thanks for your support. I have two questions on your response.

    If I understand correctly, you propose that this functionality goes into the:

    NDIS_MINIPORT_DRIVER_CHARACTERISTICS.SendNetBufferListsHandler(
       NDIS_HANDLE            MiniportAdapterContext,
       PNET_BUFFER_LIST    NetBufferLists,
       NDIS_PORT_NUMBER  PortNumber,
       ULONG                      SendFlags
    ),

    If the packet was not transmitted due to throughput reach, then I should use the function NdisMSendNetBufferListsComplete in order to notify the OS of the failed packets. My question then is what should be the status of the failed packets? From the following link:

    https://msdn.microsoft.com/en-us/library/windows/hardware/ff563668%28v=vs.85%29.aspx

    there seems to be the following options available:
    NDIS_STATUS_SUCCESS
    NDIS_STATUS_INVALID_LENGTH
    NDIS_STATUS_RESOURCES
    NDIS_STATUS_PAUSED
    NDIS_STATUS_SEND_ABORTED
    NDIS_STATUS_RESET_IN_PROGRESS
    NDIS_STATUS_FAILURE
    Should I use just NDIS_STATUS_FAILURE or NDIS_STATUS_RESOURCES?

    Also how should the estimated link throughput be indicated? Should this be through the OIDs?

    All the best,

    Angelos
    Tuesday, November 17, 2015 12:30 PM
  • OK. So the solution is to not call this function at all for the packets that I have discarded... Is this correct? Or should I call another function to note that some packets have been discarded?
    Tuesday, November 17, 2015 2:07 PM
  • Hi Pavel,

    I have written a sample code to test this case. In the code below, I wait until the first 7000 packets have been transmitted and then I transmit 50% of the packets that are incoming.
    VOID
    MPSendNetBufferLists(
    NDIS_HANDLE             MiniportAdapterContext,
    PNET_BUFFER_LIST        NetBufferLists,
    NDIS_PORT_NUMBER        PortNumber,
    ULONG                   SendFlags
    )
    {
    	PADAPTER adapter = (PADAPTER)MiniportAdapterContext;
    	NDIS_STATUS ndisStatus = NDIS_STATUS_SUCCESS;
    	PMP_PORT destinationPort = NULL;
    	PNET_BUFFER_LIST currentNetBufferList;
    	static counter = 0;
    
    
    	MP_INCREMENT_PORTLIST_REFCOUNT(adapter);
    
    	if (counter == 7000)
    		counter--;
    	else
    		counter++;
    
    	if (counter == 7000) {
    		NET_BUFFER_LIST_STATUS(NetBufferLists) = NDIS_STATUS_RESOURCES;
    		NdisMSendNetBufferListsComplete(
    			adapter->MiniportAdapterHandle,
    			NetBufferLists,
    			(NDIS_TEST_SEND_AT_DISPATCH_LEVEL(SendFlags) ? NDIS_SEND_COMPLETE_FLAGS_DISPATCH_LEVEL : 0)
    		);
    		MP_DECREMENT_PORTLIST_REFCOUNT(adapter);
    		return;
    	}
            // Proper sending code here...
    }
    

    I can see that the driver does discard 50% of the packets after it reaches 7000, but they OS doesn't seem to take notice of it. I have used both NDIS_STATUS_RESOURCES and NDIS_STATUS_SEND_ABORTED. The OS doesn't get the feedback that the packets have been discarded. Any ideas?
    Tuesday, November 17, 2015 3:38 PM
  • Hi Pavel,

    Yes. I run iperf. The following command is being run

    iperf -i 2 -u -c 192.168.2.1 -b 40M -t 3600

    On Linux as well as on a previous Windows driver implementation that was based on RNDIS, this would cause the iperf to limit itself to the available throughput, e.g. 30MBps.

    However, with the current NDIS implementation I can see that iperf doesn't get any feedback from the OS about reaching the throughput and keeps on sending data at 40MBps.

    Tuesday, November 17, 2015 4:42 PM
  • Hi Pavel,

    Many thanks for the suggestion.

    Speed reporting is only requested when the user opensthe properties window of the wireless adapter. It is an indication of the nominal speed, but not of the real speed that is supported by the interface. I can see that the OS will ask for this speed only when the user opens this window and not during real-time transmission.

    All the best,

    Angelos
    Wednesday, November 18, 2015 9:26 AM
  • Would you know where can I download this tool?
    Friday, November 20, 2015 9:51 AM