From: Paolo Abeni <pabeni@redhat.com> Date: 2017-06-21 08:49:30
On UDP packets processing, if the BH is the bottle-neck, it
always sees a cache miss while updating rmem_alloc; try to
avoid it prefetching the value as soon as we have the socket
available.
Performances under flood with multiple NIC rx queues used are
unaffected, but when a single NIC rx queue is in use, this
gives ~10% performance improvement.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
net/ipv4/udp.c | 1 +
1 file changed, 1 insertion(+)
From: David Miller <davem@davemloft.net> Date: 2017-06-21 16:20:49
From: Paolo Abeni <pabeni@redhat.com>
Date: Wed, 21 Jun 2017 10:24:40 +0200
On UDP packets processing, if the BH is the bottle-neck, it
always sees a cache miss while updating rmem_alloc; try to
avoid it prefetching the value as soon as we have the socket
available.
Performances under flood with multiple NIC rx queues used are
unaffected, but when a single NIC rx queue is in use, this
gives ~10% performance improvement.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com> Date: 2017-06-21 16:22:59
On Wed, 2017-06-21 at 11:41 -0400, David Miller wrote:
From: Paolo Abeni <pabeni@redhat.com>
Date: Wed, 21 Jun 2017 10:24:40 +0200
quoted
On UDP packets processing, if the BH is the bottle-neck, it
always sees a cache miss while updating rmem_alloc; try to
avoid it prefetching the value as soon as we have the socket
available.
Performances under flood with multiple NIC rx queues used are
unaffected, but when a single NIC rx queue is in use, this
gives ~10% performance improvement.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied, but what about ipv6?
You are right, that was unintentionally left out. I'll do some tests
and send another patch for ipv6, too.
Thanks,
Paolo