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]

Date:	Sun, 03 Nov 2013 23:10:41 -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 14:26 +0800, Herbert Xu wrote:

> Also if your scenario had all GRO candidates then not using
> frag_list would seem to be a bad workaround for an underlying
> latency problem.  Rather than arbitrarily limiting the aggregation
> to 22K surely it would make more sense to limit it based on your
> actual latency requirements?

I have never limited GRO aggregation to 22K.

You did this in commit 81705ad1b2f926d
("gro: Do not merge paged packets into frag_list")


I exactly implemented what you suggested in your patch :

"In future we can optimise this further by doing frag_list merging
but making sure that we continue to fill in the page array."

Using frag_list for skb meant to be delivered to local stack is mostly
fine. Its for forwarding that its not a win, since no driver actually
supports frag_list and we revert to skb_segment().

So my latest patch about _not_ building fat skbs with frag_list on a
router makes sense.



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