[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+6hz4rVCL2oxeQUojcqptNfcZdtLZdgEA2_j7iU1-B=s12SHg@mail.gmail.com>
Date: Mon, 21 Nov 2016 21:24:37 +0800
From: Gao Feng <fgao@...ai8.com>
To: Florian Westphal <fw@...len.de>
Cc: mareklindner@...mailbox.ch,
Simon Wunderlich <sw@...onwunderlich.de>, a@...table.cc,
"David S. Miller" <davem@...emloft.net>,
b.a.t.m.a.n@...ts.open-mesh.org,
Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH net v2 1/1] net: batman-adv: Treat NET_XMIT_CN as transmit successfully
Hi Florian,
On Mon, Nov 21, 2016 at 7:09 PM, Florian Westphal <fw@...len.de> wrote:
> fgao@...ai8.com <fgao@...ai8.com> wrote:
>> From: Gao Feng <fgao@...ai8.com>
>>
>> The tc could return NET_XMIT_CN as one congestion notification, but
>> it does not mean the packet is lost. Other modules like ipvlan,
>> macvlan, and others treat NET_XMIT_CN as success too.
>>
>> So batman-adv should add the NET_XMIT_CN check.
>
> "The tc could return NET_XMIT_CN as one congestion notification, but
> it means another packet got dropped. Other modules like batman do not
> treat NET_XMIT_CN as success, so modules like ipvlan, macvlan, ..
> should ignore it as well."
>
> What I am asking is:
> Are you sure adding NET_XMIT_CN handling everywhere is the right way to
> resolve the inconsistency?
Or create one new macro to handle this case like net_xmit_eval.
For example,
#define net_xmit_ok(ret) (ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)
Is it ok? But it should be done for net-next.
Best Regards
Feng
Powered by blists - more mailing lists