* [PATCH net-next] r8169: use netif_receive_skb_list batching
@ 2019-03-31 13:18 Heiner Kallweit
2019-03-31 18:11 ` David Miller
0 siblings, 1 reply; 9+ messages in thread
From: Heiner Kallweit @ 2019-03-31 13:18 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller
Cc: netdev@vger.kernel.org, Jesper Dangaard Brouer, Edward Cree
Use netif_receive_skb_list() instead of napi_gro_receive() to benefit
from batched skb processing.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index a8ca26c2a..c9ee1c8eb 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6426,6 +6426,7 @@ static int rtl_rx(struct net_device *dev, struct rtl8169_private *tp, u32 budget
{
unsigned int cur_rx, rx_left;
unsigned int count;
+ LIST_HEAD(rx_list);
cur_rx = tp->cur_rx;
@@ -6501,7 +6502,7 @@ static int rtl_rx(struct net_device *dev, struct rtl8169_private *tp, u32 budget
if (skb->pkt_type == PACKET_MULTICAST)
dev->stats.multicast++;
- napi_gro_receive(&tp->napi, skb);
+ list_add_tail(&skb->list, &rx_list);
u64_stats_update_begin(&tp->rx_stats.syncp);
tp->rx_stats.packets++;
@@ -6516,6 +6517,8 @@ static int rtl_rx(struct net_device *dev, struct rtl8169_private *tp, u32 budget
count = cur_rx - tp->cur_rx;
tp->cur_rx = cur_rx;
+ netif_receive_skb_list(&rx_list);
+
return count;
}
--
2.21.0
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH net-next] r8169: use netif_receive_skb_list batching
2019-03-31 13:18 [PATCH net-next] r8169: use netif_receive_skb_list batching Heiner Kallweit
@ 2019-03-31 18:11 ` David Miller
2019-04-01 9:17 ` Eric Dumazet
0 siblings, 1 reply; 9+ messages in thread
From: David Miller @ 2019-03-31 18:11 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev, brouer, ecree
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 31 Mar 2019 15:18:48 +0200
> Use netif_receive_skb_list() instead of napi_gro_receive() to benefit
> from batched skb processing.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next] r8169: use netif_receive_skb_list batching
2019-03-31 18:11 ` David Miller
@ 2019-04-01 9:17 ` Eric Dumazet
2019-04-01 12:53 ` Jesper Dangaard Brouer
2019-04-01 17:14 ` David Miller
0 siblings, 2 replies; 9+ messages in thread
From: Eric Dumazet @ 2019-04-01 9:17 UTC (permalink / raw)
To: David Miller, hkallweit1; +Cc: nic_swsd, netdev, brouer, ecree
On 03/31/2019 11:11 AM, David Miller wrote:
> From: Heiner Kallweit <hkallweit1@gmail.com>
> Date: Sun, 31 Mar 2019 15:18:48 +0200
>
>> Use netif_receive_skb_list() instead of napi_gro_receive() to benefit
>> from batched skb processing.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>
> Applied.
>
This means no GRO at all, and reduced performance in many useful cases.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next] r8169: use netif_receive_skb_list batching
2019-04-01 9:17 ` Eric Dumazet
@ 2019-04-01 12:53 ` Jesper Dangaard Brouer
2019-04-01 17:41 ` David Miller
2019-04-01 17:14 ` David Miller
1 sibling, 1 reply; 9+ messages in thread
From: Jesper Dangaard Brouer @ 2019-04-01 12:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, hkallweit1, nic_swsd, netdev, ecree, brouer
On Mon, 1 Apr 2019 02:17:12 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On 03/31/2019 11:11 AM, David Miller wrote:
> > From: Heiner Kallweit <hkallweit1@gmail.com>
> > Date: Sun, 31 Mar 2019 15:18:48 +0200
> >
> >> Use netif_receive_skb_list() instead of napi_gro_receive() to benefit
> >> from batched skb processing.
> >>
> >> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> >
> > Applied.
> >
>
> This means no GRO at all, and reduced performance in many useful
> cases.
As Eric says, this in-effect disables GRO for this driver. This will
very likely give a slowdown for local TCP delivery (while it might
helps for UDP and forwarding).
That is why I was saying we need a GRO version of this...
(which need to be combined with bulk SKB alloc, to compete with GRO
fast-recycle of same SKB).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next] r8169: use netif_receive_skb_list batching
2019-04-01 12:53 ` Jesper Dangaard Brouer
@ 2019-04-01 17:41 ` David Miller
2019-04-01 21:33 ` Eric Dumazet
0 siblings, 1 reply; 9+ messages in thread
From: David Miller @ 2019-04-01 17:41 UTC (permalink / raw)
To: brouer; +Cc: eric.dumazet, hkallweit1, nic_swsd, netdev, ecree
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Mon, 1 Apr 2019 14:53:26 +0200
> On Mon, 1 Apr 2019 02:17:12 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> On 03/31/2019 11:11 AM, David Miller wrote:
>> > From: Heiner Kallweit <hkallweit1@gmail.com>
>> > Date: Sun, 31 Mar 2019 15:18:48 +0200
>> >
>> >> Use netif_receive_skb_list() instead of napi_gro_receive() to benefit
>> >> from batched skb processing.
>> >>
>> >> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> >
>> > Applied.
>> >
>>
>> This means no GRO at all, and reduced performance in many useful
>> cases.
>
> As Eric says, this in-effect disables GRO for this driver.
Really? __netif_receive_skb_list_core() does GRO.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next] r8169: use netif_receive_skb_list batching
2019-04-01 17:41 ` David Miller
@ 2019-04-01 21:33 ` Eric Dumazet
0 siblings, 0 replies; 9+ messages in thread
From: Eric Dumazet @ 2019-04-01 21:33 UTC (permalink / raw)
To: David Miller, brouer; +Cc: eric.dumazet, hkallweit1, nic_swsd, netdev, ecree
On 04/01/2019 10:41 AM, David Miller wrote:
> From: Jesper Dangaard Brouer <brouer@redhat.com>
>>
>> As Eric says, this in-effect disables GRO for this driver.
>
> Really? __netif_receive_skb_list_core() does GRO.
At least on current public trees, it can not do GRO,
since we do not pass a napi context.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next] r8169: use netif_receive_skb_list batching
2019-04-01 9:17 ` Eric Dumazet
2019-04-01 12:53 ` Jesper Dangaard Brouer
@ 2019-04-01 17:14 ` David Miller
2019-04-01 17:31 ` Edward Cree
1 sibling, 1 reply; 9+ messages in thread
From: David Miller @ 2019-04-01 17:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: hkallweit1, nic_swsd, netdev, brouer, ecree
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 1 Apr 2019 02:17:12 -0700
> This means no GRO at all
I do not think that is true as the SKB list layer does queue up to
GRO.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next] r8169: use netif_receive_skb_list batching
2019-04-01 17:14 ` David Miller
@ 2019-04-01 17:31 ` Edward Cree
2019-04-01 17:39 ` Heiner Kallweit
0 siblings, 1 reply; 9+ messages in thread
From: Edward Cree @ 2019-04-01 17:31 UTC (permalink / raw)
To: David Miller, eric.dumazet; +Cc: hkallweit1, nic_swsd, netdev, brouer
On 01/04/2019 18:14, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 1 Apr 2019 02:17:12 -0700
>
>> This means no GRO at all
> I do not think that is true as the SKB list layer does queue up to
> GRO.
No, Eric is right; the current list layer bypasses GRO completely.
netif_receive_skb_list() ends up doing the same things netif_receive_skb()
would do on each SKB in the list, and that does not include GRO.
(For this reason the sfc driver only uses netif_receive_skb_list() for
non-TCP packets; TCP packets go to napi_gro_frags().)
I had a patch series to add napi_gro_receive_list() which would use the
SKB list layer to handle the packets GRO didn't coalesce ([1]) but the
performance tests I ran were inconclusive and it never got applied.
-Ed
[1]: https://marc.info/?l=linux-netdev&m=154221888012410&w=2
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next] r8169: use netif_receive_skb_list batching
2019-04-01 17:31 ` Edward Cree
@ 2019-04-01 17:39 ` Heiner Kallweit
0 siblings, 0 replies; 9+ messages in thread
From: Heiner Kallweit @ 2019-04-01 17:39 UTC (permalink / raw)
To: Edward Cree, David Miller, eric.dumazet; +Cc: nic_swsd, netdev, brouer
On 01.04.2019 19:31, Edward Cree wrote:
> On 01/04/2019 18:14, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Mon, 1 Apr 2019 02:17:12 -0700
>>
>>> This means no GRO at all
>> I do not think that is true as the SKB list layer does queue up to
>> GRO.
> No, Eric is right; the current list layer bypasses GRO completely.
>
> netif_receive_skb_list() ends up doing the same things netif_receive_skb()
> would do on each SKB in the list, and that does not include GRO.
> (For this reason the sfc driver only uses netif_receive_skb_list() for
> non-TCP packets; TCP packets go to napi_gro_frags().)
> I had a patch series to add napi_gro_receive_list() which would use the
> SKB list layer to handle the packets GRO didn't coalesce ([1]) but the
> performance tests I ran were inconclusive and it never got applied.
>
> -Ed
>
> [1]: https://marc.info/?l=linux-netdev&m=154221888012410&w=2
>
Patch 0a25d92c6f4f ("dpaa2-eth: use netif_receive_skb_list") was well
perceived [1], therefore I was under the assumption that
netif_receive_skb_list is kind of successor for napi_gro_receive().
Does what you say apply to that patch too?
Based on feedback so far it seems to best if I revert the patch.
Heiner
[1] https://patchwork.ozlabs.org/patch/1064334/
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-04-01 21:33 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-31 13:18 [PATCH net-next] r8169: use netif_receive_skb_list batching Heiner Kallweit
2019-03-31 18:11 ` David Miller
2019-04-01 9:17 ` Eric Dumazet
2019-04-01 12:53 ` Jesper Dangaard Brouer
2019-04-01 17:41 ` David Miller
2019-04-01 21:33 ` Eric Dumazet
2019-04-01 17:14 ` David Miller
2019-04-01 17:31 ` Edward Cree
2019-04-01 17:39 ` Heiner Kallweit
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).