Re: sunvnet and ->xmit_more

[David Miller <davem@davemloft.net>]

From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Tue, 7 Oct 2014 15:29:22 -0400

> I'm not sure how this can be useful to sunvnet- in sunvnet's case
> we send the TX indication at the *start* of a burst, so if xmit_more
> was set, sure- we can send out another packet immediately, and
> avoid another START message (which we already do today), but 
> nothing else to be gained from xmit_more?

If you defer that __vnet_tx_trigger() call through all the ->xmit_more
SKBs, then you are less likely to see the DRING_STOPPED event from the
peer which will make you have to send a START again.

So, for an xmit_more burst of 3, instead of:

	->ndo_start_xmit()
		__vnet_tx_trigger()
	->ndo_start_xmit()
IRQ -> vnet_ack() -> STOPPED
	->ndo_start_xmit()
		__vnet_tx_trigger()

You would do something like:

	->ndo_start_xmit()
	->ndo_start_xmit()
	->ndo_start_xmit()
		__vnet_tx_trigger()

> BTW, I have most of the NAPI done, getting it stress-tested etc
> (the recent jumbo commit added a few more races between vnet_port_remove
> and vnet_start_xmit, thanks to the extra clean_timer) but I figure
> I might as well fully test this internally since net-next is closed
> for the moment anyway?

Yeah no rush.