netdev - Re: [PATCHv8 net-next 2/4] sunvnet: make transmit path zero-copy in the kernel

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]

Date:	Mon, 29 Sep 2014 16:54:40 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	david.stevens@...cle.com
Cc:	netdev@...r.kernel.org, sowmini.varadhan@...cle.com,
	raghuram.kothakota@...cle.com
Subject: Re: [PATCHv8 net-next 2/4] sunvnet: make transmit path zero-copy
 in the kernel

From: David L Stevens <david.stevens@...cle.com>
Date: Mon, 29 Sep 2014 16:44:08 -0400

> On 09/29/2014 04:29 PM, David Miller wrote:
> 
>> 
>> It doesn't work to liberate SKBs in the TX ring purely from the
>> ->ndo_start_xmit() method.
>> 
>> All SKBs given to a device must be liberated in a finite, short,
>> amount of time.
> 
> I did consider putting a garbage-collector via timer on them, since
> we got such a boost from not ACKing every packet. I guess the question
> is "how short?"
> 
> For example, I could leave the "normal" path like this and just start/mod
> a timer to do it after 1 sec if we haven't done it through start_xmit. Do
> you think that's sufficiently short?

To be honest I'm not %100 sure.

SKB liberation frees up space in the TCP socket send buffer, so... but
arguably if the connection actually cares and is in steady state then
we'll be liberating via the ->ndo_start_xmit() flush you do here.

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