netdev - Re: [net-next 6/9] ice: enable initial devlink support

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]

Message-ID: <61321056-0890-7760-4164-6fdbb9021bd3@intel.com>
Date:   Mon, 23 Mar 2020 10:23:32 -0700
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, nhorman@...hat.com,
        sassmann@...hat.com, Jesse Brandeburg <jesse.brandeburg@...el.com>,
        Andrew Bowers <andrewx.bowers@...el.com>
Subject: Re: [net-next 6/9] ice: enable initial devlink support



On 3/23/2020 10:09 AM, Jakub Kicinski wrote:
> On Sat, 21 Mar 2020 01:10:25 -0700 Jeff Kirsher wrote:
>> From: Jacob Keller <jacob.e.keller@...el.com>
>>
>> Begin implementing support for the devlink interface with the ice
>> driver.
>>
>> The pf structure is currently memory managed through devres, via
>> a devm_alloc. To mimic this behavior, after allocating the devlink
>> pointer, use devm_add_action to add a teardown action for releasing the
>> devlink memory on exit.
>>
>> The ice hardware is a multi-function PCIe device. Thus, each physical
>> function will get its own devlink instance. This means that each
>> function will be treated independently, with its own parameters and
>> configuration. This is done because the ice driver loads a separate
>> instance for each function.
>>
>> Due to this, the implementation does not enable devlink to manage
>> device-wide resources or configuration, as each physical function will
>> be treated independently. This is done for simplicity, as managing
>> a devlink instance across multiple driver instances would significantly
>> increase the complexity for minimal gain.
>>
>> Signed-off-by: Jacob Keller <jacob.e.keller@...el.com>
>> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@...el.com>
>> Tested-by: Andrew Bowers <andrewx.bowers@...el.com>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
> 
> Reviewed-by: Jakub Kicinski <kuba@...nel.org>
> 
> Thanks for posting these!
> 

The remaining patches from the RFCs will be posted as two separate
series after this has merged.

Thanks again for the detailed review and helping find consensus on all
the naming!

Thanks,
Jake