On 11/15/2018 02:45 PM, Edward Cree wrote:
> On 15/11/18 22:01, Eric Dumazet wrote:
>> On 11/15/2018 01:45 PM, Edward Cree wrote:
>>> If napi->poll() is only handling one packet, surely GRO can't do anything
>>> useful either? (AIUI at the end of the poll the GRO lists get flushed.)
>> That is
On 15/11/18 22:01, Eric Dumazet wrote:
> On 11/15/2018 01:45 PM, Edward Cree wrote:
>> If napi->poll() is only handling one packet, surely GRO can't do anything
>> useful either? (AIUI at the end of the poll the GRO lists get flushed.)
> That is my point.
>
> Adding yet another layer that will ad
Some corrections as it looks like I didn't proofread this carefully enough
before sending it...
On 14/11/18 18:07, Edward Cree wrote:
> Payload_size in all tests was 8000 bytes.
This was for TCP tests; the UDP test used 1-byte payloads.
> UDP Stream (GRO off):
> net-next: 7.808 Gb/s
> after #4:
On 11/15/2018 01:45 PM, Edward Cree wrote:
>
> If napi->poll() is only handling one packet, surely GRO can't do anything
> useful either? (AIUI at the end of the poll the GRO lists get flushed.)
That is my point.
Adding yet another layer that will add no gain but add more waste of cpu cycle
On 15/11/18 20:08, Eric Dumazet wrote:
> On 11/15/2018 10:43 AM, Edward Cree wrote:
>
> Most of the packet isn't touched and thus won't be brought into cache.
>> Only the headers of each packet (worst-case let's say 256 bytes) will
>> be touched during batch processing, that's 16kB.
> You assume p
On 11/15/2018 10:43 AM, Edward Cree wrote:
Most of the packet isn't touched and thus won't be brought into cache.
> Only the headers of each packet (worst-case let's say 256 bytes) will
> be touched during batch processing, that's 16kB.
You assume perfect use of the caches, but part of the ca
On 15/11/18 07:22, Eric Dumazet wrote:
> On 11/14/2018 10:07 AM, Edward Cree wrote:
>> Conclusion:
>> * TCP b/w is 16.5% faster for traffic which cannot be coalesced by GRO.
> But only for traffic that actually was perfect GRO candidate, right ?
>
> Now what happens if all the packets you are batch
On 11/14/2018 10:07 AM, Edward Cree wrote:
>
> Conclusion:
> * TCP b/w is 16.5% faster for traffic which cannot be coalesced by GRO.
>
But only for traffic that actually was perfect GRO candidate, right ?
Now what happens if all the packets you are batching are hitting different TCP
sockets ?
This series listifies part of GRO processing, in a manner which allows those
packets which are not GROed (i.e. for which dev_gro_receive returns
GRO_NORMAL) to be passed on to the listified regular receive path.
dev_gro_receive() itself is not listified, nor the per-protocol GRO
callback, since
