netdev - Re: [PATCH v3 net-next] net: introduce dev_set

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: <1383538982.4291.80.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Sun, 03 Nov 2013 20:23:02 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Ben Hutchings <bhutchings@...arflare.com>,
	David Miller <davem@...emloft.net>,
	christoph.paasch@...ouvain.be, netdev@...r.kernel.org,
	hkchu@...gle.com, mwdalton@...gle.com
Subject: Re: [PATCH v3 net-next] net: introduce dev_set_forwarding()

On Mon, 2013-11-04 at 12:11 +0800, Herbert Xu wrote:
> On Sun, Nov 03, 2013 at 09:26:43AM -0800, Eric Dumazet wrote:
> > 
> > Not really.
> > 
> > Have you took a look at the GSO path recently ?
> > 
> > The days it was handling only IP+TCP are gone.
> > 
> > If you think you can do better, please do so.
> 
> OK maybe I overreacted.
> 
> With regards to your point 2), GRO does not introduce any latencies
> because it simply relies on NAPI to do the aggregation.  IOW it is
> no better or worse latency-wise compared to NAPI.  If you need to
> tune it, just use the usual NAPI toggles.
> 

Well, GRO adds latencies for sure.

You seem to assume the transmit only can happen when NAPI is done, but
its not true. As soon as GRO fills one packet (reaches max capacity),
packet is delivered and forwarded, even if NAPI handler is not yet
complete for the flow.

Say you have 1 us per MSS, then filling 45 MSS per skb means we add a 45
us delay transit, instead of 16 us, or 1 us if no GRO is used on the
router.



> With repsect to point 3), sure we can allow the generation of TSO
> segments in skb_segment.
> 
> You may be right that this is all too hard, since I haven't actually
> sat down and tried to do it yet.
> 
> But please give me chance to have a look first before we give up and
> install a permanent user-space toggle.

I don't think I ever said it was permanent, I am sorry you understood
this.

I will be happy to change skb_segment() in the future, but I already
said I would not expect doing so for linux-3.13, given we were too late
in the linux-3.12-rc.

Thanks


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