> 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. Scenario #1: 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? Scenario #2: 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] Cheers, Yuval > > 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(-) > > -- > 1.9.1
