[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230620113325.3e9172e3@kernel.org>
Date: Tue, 20 Jun 2023 11:33:25 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Cambda Zhu <cambda@...ux.alibaba.com>
Cc: Simon Horman <simon.horman@...igine.com>, netdev@...r.kernel.org, Eric
Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, "David S.
Miller" <davem@...emloft.net>, David Ahern <dsahern@...nel.org>, Lu Wei
<luwei32@...wei.com>, "t.feng" <fengtao40@...wei.com>, Xin Long
<lucien.xin@...il.com>, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Dust Li
<dust.li@...ux.alibaba.com>, Tony Lu <tonylu@...ux.alibaba.com>
Subject: Re: [PATCH net v1] ipvlan: Fix return value of ipvlan_queue_xmit()
On Fri, 16 Jun 2023 17:40:29 +0800 Cambda Zhu wrote:
> > ipvlan_rcv_frame can return two distinct values - RX_HANDLER_CONSUMED and
> > RX_HANDLER_ANOTHER. Is it correct to treat these both as NET_XMIT_SUCCESS
> > in the xmit path? If so, perhaps it would be useful to explain why
> > in the commit message.
>
> The ipvlan_rcv_frame() will only return RX_HANDLER_CONSUMED in
> ipvlan_xmit_mode_l2/l3() for local is true. It's equal to NET_XMIT_SUCCESS.
> The dev_forward_skb() can return NET_RX_SUCCESS and NET_RX_DROP, and
> returning NET_RX_DROP(NET_XMIT_DROP) will increase both ipvlan and
> ipvlan->phy_dev drops counter. I think the drops should belong to
> the rcv side, and the xmit side should return NET_XMIT_SUCCESS even
> if rcv failed. However, I'm not sure if my opinion is right.
Please add the explanation to the commit msg and CC Mahesh on the v2.
Powered by blists - more mailing lists