netdev - Re: [PATCH] tcp: make urg+gso work for real this time

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: <1229510713.13305.17.camel@nathan.suse.cz>
Date:	Wed, 17 Dec 2008 11:45:13 +0100
From:	Petr Tesarik <ptesarik@...e.cz>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	ilpo.jarvinen@...sinki.fi, davem@...emloft.net,
	netdev@...r.kernel.org
Subject: Re: [PATCH] tcp: make urg+gso work for real this time

Herbert Xu píše v St 17. 12. 2008 v 21:17 +1100:
> Petr Tesarik <ptesarik@...e.cz> wrote:
> > 
> >  1. Currently this code path will never get run, because large
> >     offloads are avoided both for hardware TSO and software GSO.
> >     You'd also have to modify the conditionals that guard calls
> >     to tcp_mss_split_point().
> 
> Obviously one would revert the existing fixes after this is applied.
> 
> >  2. Is it worth the trouble?
> >     This slows down the software GSO slightly. I mean, urgent
> >     data should be quite rare, so it makes sense to treat
> >     non-urgent data as "fast path" and urgent data as "slow
> >     path". While Ilpo's approach only slows down the slow path,
> >     your patch slows down both.
> 
> Well it might slow down the GSO path slightly, but it speeds
> up the TSO generation path accordingly :) I think the cost is
> negligible in either case so the benefit of TSO dominates.

You're talking about the urgent-data case, right? Yes, for urgent data,
correctly implemented GSO will no doubt be faster than splitting the
skb. But GSO will also get (a bit) slower for the non-urgent-data case,
where the slowdown is not compensated by anything. Or did I miss
something obvious?

Petr Tesarik
 
> > Anyway, we have to keep the code that avoids large offloads with URG,
> > because many NICs are broken in this regard (at least all Intel NICs
> > I've seen so far), so why treat software GSO specially?
> 
> That's not a problem.  Unless the NIC sets NETIF_F_TSO_URG (which
> nobody does currently because it's a new flag), we'll do the
> segmentation in software, but only if the packet is marked as URG.
> 
> This is identical to how we handle ECN which most NICs get wrong
> as well.
> 
> Cheers,

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