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: <61edd390-af20-2787-565c-207222f0510f@huawei.com>
Date:   Tue, 15 Nov 2022 18:27:22 +0800
From:   "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" 
        <longpeng2@...wei.com>
To:     Leon Romanovsky <leon@...nel.org>
CC:     Oliver O'Halloran <oohall@...il.com>, <bhelgaas@...gle.com>,
        <linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <jianjay.zhou@...wei.com>, <zhuangshengen@...wei.com>,
        <arei.gonglei@...wei.com>, <yechuan@...wei.com>,
        <huangzhichao@...wei.com>, <xiehong@...wei.com>
Subject: Re: [RFC 0/4] pci/sriov: support VFs dynamic addition



在 2022/11/15 18:02, Leon Romanovsky 写道:
> On Tue, Nov 15, 2022 at 05:36:38PM +0800, Longpeng (Mike, Cloud Infrastructure Service Product Dept.) wrote:
>>
>>
>> 在 2022/11/15 16:32, Leon Romanovsky 写道:
>>> On Tue, Nov 15, 2022 at 12:50:34PM +1100, Oliver O'Halloran wrote:
>>>> On Tue, Nov 15, 2022 at 1:27 AM Leon Romanovsky <leon@...nel.org> wrote:
>>>>>
>>>>> *snip*
>>>>>
>>>>> Anyway, I'm aware of big cloud providers who are pretty happy with live
>>>>> migration in production.
>>>>
>>>> I could see someone sufficiently cloudbrained deciding that rebooting
>>>> the hypervisor is fine provided the downtime doesn't violate any
>>>> customer uptime SLAs. Personally I'd only be brave enough to do that
>>>> for a HV hosting internal services which I know are behind a load
>>>> balancer, but apparently there are people at Huawei far braver than I.
>>>
>>> My main point in this discussion that Huawei team doesn't actually
>>> provide any meaningful justification why it is great idea to add new
>>> sysfs file. They use HPC as an argument, but in that world, you won't
>>> see many VMs on one server, as it is important to provide separate MSI-X
>>> vectors and CPUs to each VM.
>>>
>>> They ask from us optimization (do not add device hierarchy for existing HW)
>>> that doesn't exist in the kernel.
>>>
>>> I would say that they are trying to meld SIOV architecture of subfunctions
>>> (SFs) into PCI and SR-IOV world.
>>>
>> I may not agree with you on this point.
> 
> The bright side of open source that you don't need to agree with everyone.
> If you success to convince others, it will be merged.
> 
Yes, but patches be merged is not the only purpose of open source, but 
learning from the disscussion is much more important.
I'm not care about these patches will be merged or not, at least you've 
pointed some disadvantages of this solution.

>> The sriov_numvfs interface mixes the
>> operation of enabling hardware VFs and the addition of VFs. I just want to
>> split these two operations and also can selectively add some VFs earlier
>> than others. I think there's no violation of PCI spec.
> 
> Right, it just doesn't fit into Linux kernel device initialization model.
> 
> Thanks
> 
>>
>>> Thanks
>>> .
> .

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ