From: Andrew Lunn <andrew@lunn.ch>
To: Wei Fang <wei.fang@nxp.com>
Cc: Alexander Lobakin <alexandr.lobakin@intel.com>,
Shenwei Wang <shenwei.wang@nxp.com>,
Clark Wang <xiaoning.wang@nxp.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"edumazet@google.com" <edumazet@google.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"simon.horman@corigine.com" <simon.horman@corigine.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
dl-linux-imx <linux-imx@nxp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2 net-next] net: fec: add CBS offload support
Date: Tue, 21 Feb 2023 03:25:24 +0100 [thread overview]
Message-ID: <Y/QrlM011Jw2hsnG@lunn.ch> (raw)
In-Reply-To: <DB9PR04MB8106C0ADA70B24BFCF9D2BD988A69@DB9PR04MB8106.eurprd04.prod.outlook.com>
> Unfortunately, FEC IP itself not follows the standard 802.1Qav spec completely.
> We only can program DMAnCFG[IDLE_SLOPE] field to calculate bandwidth fraction.
> And IDLE_SLOPE is restricted to certain values. It's far away from CBS QDisc implemented
> in Linux TC framework. It is more difficult to guarantee similar software behavior when
> the link speed changes.
> If the method of keeping the bandwidth ratio unchanged is not sensible, I can only give up
> CBS offload and use pure software CBS. :(
I know the hardware supports less parameters. But if you restrict the
CBS configuration such that the parameters you don't support are 0,
can you accurately implement what you do support?
If the user configures TC such that it matches the hardware
capabilities, you can accept the offload. If not return -EOPNOTSUPP,
and the software CBS should take over. And then you need to clearly
document what parameters can be set for hardware offload to work.
Andrew
next prev parent reply other threads:[~2023-02-21 2:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 9:29 [PATCH V2 net-next] net: fec: add CBS offload support wei.fang
2023-02-13 13:32 ` Andrew Lunn
2023-02-14 8:02 ` Wei Fang
2023-02-13 16:04 ` Alexander Lobakin
2023-02-13 16:21 ` Andrew Lunn
2023-02-13 17:44 ` Alexander Lobakin
2023-02-13 18:07 ` Andrew Lunn
2023-02-14 13:22 ` Wei Fang
2023-02-14 14:28 ` Andrew Lunn
2023-02-16 12:43 ` Wei Fang
2023-02-18 1:15 ` Andrew Lunn
2023-02-18 1:59 ` Wei Fang
2023-02-21 2:25 ` Andrew Lunn [this message]
2023-02-14 9:34 ` Wei Fang
2023-02-14 13:49 ` Andrew Lunn
2023-02-14 16:49 ` Alexander Lobakin
2023-02-16 13:03 ` Wei Fang
2023-02-16 15:28 ` Alexander Lobakin
2023-02-17 2:18 ` Wei Fang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y/QrlM011Jw2hsnG@lunn.ch \
--to=andrew@lunn.ch \
--cc=alexandr.lobakin@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shenwei.wang@nxp.com \
--cc=simon.horman@corigine.com \
--cc=wei.fang@nxp.com \
--cc=xiaoning.wang@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).