* [dpdk-dev] [PATCH v2] kni: use netif_rx instead of netif_receive_skb in which ocurr deallock on userpace contex
@ 2014-07-11 15:37 Yao-Po Wang
2014-07-17 12:02 ` Thomas Monjalon
0 siblings, 1 reply; 4+ messages in thread
From: Yao-Po Wang @ 2014-07-11 15:37 UTC (permalink / raw)
To: dev
Per netif_receive_skb function description, it may only be called from
interrupt contex, but KNI is run on kthread that like as user-space
contex. It may occur deallock, if netif_receive_skb called from kthread,
so it should be repleaced by netif_rx or adding local_bh_disable/enable
around netif_receive_skb.
Signed-off-by: Yao-Po Wang <blue119@gmail.com>
---
lib/librte_eal/linuxapp/kni/kni_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/kni/kni_net.c b/lib/librte_eal/linuxapp/kni/kni_net.c
index d3c0190..28cc5ab 100644
--- a/lib/librte_eal/linuxapp/kni/kni_net.c
+++ b/lib/librte_eal/linuxapp/kni/kni_net.c
@@ -179,7 +179,7 @@ kni_net_rx_normal(struct kni_dev *kni)
skb->ip_summed = CHECKSUM_UNNECESSARY;
/* Call netif interface */
- netif_receive_skb(skb);
+ netif_rx(skb);
/* Update statistics */
kni->stats.rx_bytes += len;
--
2.0.0
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dpdk-dev] [PATCH v2] kni: use netif_rx instead of netif_receive_skb in which ocurr deallock on userpace contex
2014-07-11 15:37 [dpdk-dev] [PATCH v2] kni: use netif_rx instead of netif_receive_skb in which ocurr deallock on userpace contex Yao-Po Wang
@ 2014-07-17 12:02 ` Thomas Monjalon
2014-07-17 12:24 ` Alex Markuze
0 siblings, 1 reply; 4+ messages in thread
From: Thomas Monjalon @ 2014-07-17 12:02 UTC (permalink / raw)
To: dev
Hi,
2014-07-11 23:37, Yao-Po Wang:
> Per netif_receive_skb function description, it may only be called from
> interrupt contex, but KNI is run on kthread that like as user-space
> contex. It may occur deallock, if netif_receive_skb called from kthread,
> so it should be repleaced by netif_rx or adding local_bh_disable/enable
> around netif_receive_skb.
>
> Signed-off-by: Yao-Po Wang <blue119@gmail.com>
> --- a/lib/librte_eal/linuxapp/kni/kni_net.c
> +++ b/lib/librte_eal/linuxapp/kni/kni_net.c
> /* Call netif interface */
> - netif_receive_skb(skb);
> + netif_rx(skb);
Is there someone confident to approve this change?
--
Thomas
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dpdk-dev] [PATCH v2] kni: use netif_rx instead of netif_receive_skb in which ocurr deallock on userpace contex
2014-07-17 12:02 ` Thomas Monjalon
@ 2014-07-17 12:24 ` Alex Markuze
2014-07-19 0:03 ` Thomas Monjalon
0 siblings, 1 reply; 4+ messages in thread
From: Alex Markuze @ 2014-07-17 12:24 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Thu, Jul 17, 2014 at 3:02 PM, Thomas Monjalon
<thomas.monjalon@6wind.com> wrote:
> Hi,
>
> 2014-07-11 23:37, Yao-Po Wang:
>> Per netif_receive_skb function description, it may only be called from
>> interrupt contex, but KNI is run on kthread that like as user-space
>> contex. It may occur deallock, if netif_receive_skb called from kthread,
>> so it should be repleaced by netif_rx or adding local_bh_disable/enable
>> around netif_receive_skb.
>>
>> Signed-off-by: Yao-Po Wang <blue119@gmail.com>
>
>> --- a/lib/librte_eal/linuxapp/kni/kni_net.c
>> +++ b/lib/librte_eal/linuxapp/kni/kni_net.c
>> /* Call netif interface */
>> - netif_receive_skb(skb);
>> + netif_rx(skb);
>
> Is there someone confident to approve this change?
Yao-Po is correct.
Please see this comment In Linux source code .
http://lxr.free-electrons.com/source/net/core/dev.c#L3715
Context:
All todays network drivers use(ixgbe is no exception) NAPI which is a
soft irq context of the receive flow .
This is the context in which netif_receive_skb should be called in.
KNI is not soft IRQ context so the generic netif_rx is the
right function.
>
> --
> Thomas
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dpdk-dev] [PATCH v2] kni: use netif_rx instead of netif_receive_skb in which ocurr deallock on userpace contex
2014-07-17 12:24 ` Alex Markuze
@ 2014-07-19 0:03 ` Thomas Monjalon
0 siblings, 0 replies; 4+ messages in thread
From: Thomas Monjalon @ 2014-07-19 0:03 UTC (permalink / raw)
To: Yao-Po Wang; +Cc: dev
2014-07-17 15:24, Alex Markuze:
> On Thu, Jul 17, 2014 at 3:02 PM, Thomas Monjalon
> > 2014-07-11 23:37, Yao-Po Wang:
> >> Per netif_receive_skb function description, it may only be called from
> >> interrupt contex, but KNI is run on kthread that like as user-space
> >> contex. It may occur deallock, if netif_receive_skb called from kthread,
> >> so it should be repleaced by netif_rx or adding local_bh_disable/enable
> >> around netif_receive_skb.
> >>
> >> Signed-off-by: Yao-Po Wang <blue119@gmail.com>
> >
> >> --- a/lib/librte_eal/linuxapp/kni/kni_net.c
> >> +++ b/lib/librte_eal/linuxapp/kni/kni_net.c
> >> /* Call netif interface */
> >> - netif_receive_skb(skb);
> >> + netif_rx(skb);
> >
> > Is there someone confident to approve this change?
>
> Yao-Po is correct.
>
> Please see this comment In Linux source code .
> http://lxr.free-electrons.com/source/net/core/dev.c#L3715
>
> Context:
> All todays network drivers use(ixgbe is no exception) NAPI which is a
> soft irq context of the receive flow .
> This is the context in which netif_receive_skb should be called in.
> KNI is not soft IRQ context so the generic netif_rx is the
> right function.
Thanks for confirmation.
Assuming Acked-by: Alex Markuze <alex@weka.io>
Applied for version 1.7.1
Thanks
--
Thomas
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-07-19 0:02 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-11 15:37 [dpdk-dev] [PATCH v2] kni: use netif_rx instead of netif_receive_skb in which ocurr deallock on userpace contex Yao-Po Wang
2014-07-17 12:02 ` Thomas Monjalon
2014-07-17 12:24 ` Alex Markuze
2014-07-19 0:03 ` Thomas Monjalon
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).