[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VE1PR04MB64967EB9ED113EF77B48D7E8922A0@VE1PR04MB6496.eurprd04.prod.outlook.com>
Date: Fri, 27 Dec 2019 02:11:41 +0000
From: Po Liu <po.liu@....com>
To: David Miller <davem@...emloft.net>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"vinicius.gomes@...el.com" <vinicius.gomes@...el.com>,
Claudiu Manoil <claudiu.manoil@....com>,
Vladimir Oltean <vladimir.oltean@....com>,
Alexandru Marginean <alexandru.marginean@....com>,
Xiaoliang Yang <xiaoliang.yang_1@....com>,
Roy Zang <roy.zang@....com>, Mingkai Hu <mingkai.hu@....com>,
Jerry Huang <jerry.huang@....com>, Leo Li <leoyang.li@....com>,
"ivan.khoronzhuk@...aro.org" <ivan.khoronzhuk@...aro.org>
Subject: RE: [EXT] Re: [net-next] enetc: add support time specific departure
base on the qos etf
Br,
Po Liu
> -----Original Message-----
> From: David Miller <davem@...emloft.net>
> Sent: 2019年12月27日 7:10
> To: Po Liu <po.liu@....com>
> Cc: linux-kernel@...r.kernel.org; netdev@...r.kernel.org;
> vinicius.gomes@...el.com; Claudiu Manoil <claudiu.manoil@....com>;
> Vladimir Oltean <vladimir.oltean@....com>; Alexandru Marginean
> <alexandru.marginean@....com>; Xiaoliang Yang
> <xiaoliang.yang_1@....com>; Roy Zang <roy.zang@....com>; Mingkai Hu
> <mingkai.hu@....com>; Jerry Huang <jerry.huang@....com>; Leo Li
> <leoyang.li@....com>; ivan.khoronzhuk@...aro.org
> Subject: [EXT] Re: [net-next] enetc: add support time specific departure base on
> the qos etf
>
> Caution: EXT Email
>
> From: Po Liu <po.liu@....com>
> Date: Mon, 23 Dec 2019 03:42:39 +0000
>
> > - Transmit checksum offloads and time specific departure operation are
> > mutually exclusive.
>
> I do not see anything which enforces this conflict.
>
> It looks to me like if the user configures time specific departure, and TX SKBs will
> be checksum offloaded, the time specific departure will simply not be performed.
>
> If true, this behavior will be very surprising for the user.
>
> Instead, the configuration operation that creates the conflict should throw and
> error and fail.
I would fix it.
>
> Thank you.
Powered by blists - more mailing lists