netdev - Re: [PATCH net-next 1/2] mqprio: Add a new hardware offload type in mqprio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 13 Oct 2017 10:12:38 +0800
From:   Yunsheng Lin <linyunsheng@...wei.com>
To:     Yuval Mintz <yuvalm@...lanox.com>,
        "davem@...emloft.net" <davem@...emloft.net>
CC:     "huangdaode@...ilicon.com" <huangdaode@...ilicon.com>,
        "xuwei5@...ilicon.com" <xuwei5@...ilicon.com>,
        "liguozhu@...ilicon.com" <liguozhu@...ilicon.com>,
        "Yisen.Zhuang@...wei.com" <Yisen.Zhuang@...wei.com>,
        "gabriele.paoloni@...wei.com" <gabriele.paoloni@...wei.com>,
        "john.garry@...wei.com" <john.garry@...wei.com>,
        "linuxarm@...wei.com" <linuxarm@...wei.com>,
        "salil.mehta@...wei.com" <salil.mehta@...wei.com>,
        "lipeng321@...wei.com" <lipeng321@...wei.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 1/2] mqprio: Add a new hardware offload type in
 mqprio

Hi, Yuval

On 2017/10/13 4:10, Yuval Mintz wrote:
>> When a driver supports both dcb and hardware offloaded mqprio, and
>> user is running mqprio and dcb tool concurrently, the configuration
>> set by each tool may be conflicted with each other because the dcb
> (for second 'each') s/each/the
> 

Will do, Thanks

>> and mqprio may be using the same hardwere offload component and share
> s/hardwere/hardware

Will do, Thanks

> 
>> the tc system in the network stack.
>>
>> This patch adds a new offload type to indicate that the underlying
>> driver offload prio mapping as part of DCB. If the driver would be
> 'should' offload

Will do, Thanks

> 
>> incapable of that it would refuse the offload. User would then have
>> to explicitly request that qdisc offload.
> 
> 
>