[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20141007.153829.1919460115976279645.davem@davemloft.net>
Date: Tue, 07 Oct 2014 15:38:29 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: sowmini.varadhan@...cle.com
Cc: netdev@...r.kernel.org, david.stevens@...cle.com,
Raghuram.Kothakota@...cle.com
Subject: Re: sunvnet and ->xmit_more
From: Sowmini Varadhan <sowmini.varadhan@...cle.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists