Hi Florian, On Thu, Nov 3, 2016 at 8:58 AM, Florian Fainelli <f.faine...@gmail.com> wrote: > On 11/02/2016 05:52 PM, Gao Feng wrote: >> Hi Cong, >> >> On Thu, Nov 3, 2016 at 4:22 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote: >>> On Wed, Nov 2, 2016 at 2:59 AM, <f...@ikuai8.com> wrote: >>>> From: Gao Feng <f...@ikuai8.com> >>>> >>>> Current veth_xmit always returns NETDEV_TX_OK whatever if it is really >>>> sent successfully. Now return the actual value instead of NETDEV_TX_OK >>>> always. >>>> >>>> Signed-off-by: Gao Feng <f...@ikuai8.com> >>>> --- >>>> drivers/net/veth.c | 7 +++++-- >>>> 1 file changed, 5 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/drivers/net/veth.c b/drivers/net/veth.c >>>> index fbc853e..769a3bd 100644 >>>> --- a/drivers/net/veth.c >>>> +++ b/drivers/net/veth.c >>>> @@ -111,15 +111,18 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, >>>> struct net_device *dev) >>>> struct veth_priv *priv = netdev_priv(dev); >>>> struct net_device *rcv; >>>> int length = skb->len; >>>> + int ret = NETDEV_TX_OK; >>>> >>>> rcu_read_lock(); >>>> rcv = rcu_dereference(priv->peer); >>>> if (unlikely(!rcv)) { >>>> kfree_skb(skb); >>>> + ret = NET_RX_DROP; >>> >>> >>> Returning NET_RX_DROP doesn't look correct in a xmit function. >> >> Yes. But I don't find good macro. >> NETDEV_TX_BUSY or NET_RX_DROP, which is better ? > > There is no much choice you need to return a correct value from the > netdev_tx_t enum, which NET_RX_DROP is not part of, so that probably > means using NETDEV_TX_OK here, the packet has been freed, and there is > no flow control problem mandating the return of NETDEV_TX_BUSY it seems... > -- > Florian
Thanks your explanation. It means the veth_xmit must return NETDEV_TX_OK. Regards Feng