RE: [PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver
- Date: Thu, 12 Oct 2017 20:21:04 +0000
- From: Yuval Mintz <yuvalm@xxxxxxxxxxxx>
- Subject: RE: [PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver
> This patchset adds a new hardware offload type in mqprio before adding
> mqprio hardware offload support in hns3 driver.
I think one of the biggest issues in tying this to DCB configuration is the
non-immediate [and possibly non persistent] configuration.
User is configuring mqprio offloaded with 3 TCs while device is in willing mode.
Would you expect the driver to immediately respond with a success or instead
delay the return until the DCBx negotiation is complete and the operational
num of TCs is actually 3?
Assume user explicitly offloaded mqprio with 3 TCs, but now DCB configuration
has changed on the peer side and 4 TCs is the new negotiated operational value.
Your current driver logic would change the number of TCs underneath the user
configuration [and it would actually probably work due to mqprio being a crappy
qdisc]. But was that the user actual intention?
[I think the likely answer in this scenario is 'yes' since the alternative is no better.
But I still thought it was worth mentioning]
> Yunsheng Lin (2):
> mqprio: Add a new hardware offload type in mqprio
> net: hns3: Add mqprio hardware offload support in hns3 driver
> drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 +
> .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 23 +++++++++++
> .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46 ++++++++++++++-
> include/uapi/linux/pkt_sched.h | 1 +
> 4 files changed, 55 insertions(+), 16 deletions(-)