netdev - Re: sunvnet and ->xmit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <9BB04EDE-1842-4DB0-93BE-5186B2D187AB@oracle.com>
Date:	Tue, 7 Oct 2014 13:38:07 -0700
From:	Raghuram Kothakota <Raghuram.Kothakota@...cle.com>
To:	David Miller <davem@...emloft.net>
Cc:	sowmini.varadhan@...cle.com, netdev@...r.kernel.org,
	david.stevens@...cle.com
Subject: Re: sunvnet and ->xmit_more


On Oct 7, 2014, at 12:38 PM, David Miller <davem@...emloft.net> wrote:

> 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()

In case of sunvnet,  consumer starting as soon as possible would help
as the consumer is slower as it copies the data to local buffers. The recent
change by DLS avoids the copy in the Tx side, so the producer could be
faster than the receiver.  If the trigger is sent after n packets, then consumer
will really start after n packets in the ring and it may have lost that much time
to pickup the packets.

-Raghuram

> 
>> 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