public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: "Longpeng (Mike,
	Cloud Infrastructure Service Product Dept.)" 
	<longpeng2@huawei.com>
Cc: Oliver O'Halloran <oohall@gmail.com>,
	bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, jianjay.zhou@huawei.com,
	zhuangshengen@huawei.com, arei.gonglei@huawei.com,
	yechuan@huawei.com, huangzhichao@huawei.com, xiehong@huawei.com
Subject: Re: [RFC 0/4] pci/sriov: support VFs dynamic addition
Date: Tue, 15 Nov 2022 12:02:26 +0200	[thread overview]
Message-ID: <Y3NjslijVKfLQo3W@unreal> (raw)
In-Reply-To: <638b2550-7da8-1b48-4038-52f71947ff05@huawei.com>

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@kernel.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.

> 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
> > .

  reply	other threads:[~2022-11-15 10:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11 14:27 [RFC 0/4] pci/sriov: support VFs dynamic addition Longpeng(Mike)
2022-11-11 14:27 ` [RFC 1/4] pci/sriov: extract sriov_numvfs common helper Longpeng(Mike)
2022-11-11 14:27 ` [RFC 2/4] pci/sriov: add vf_bitmap to mark the vf id allocation Longpeng(Mike)
2022-11-11 14:27 ` [RFC 3/4] pci/sriov: add sriov_numfs_no_scan interface Longpeng(Mike)
2022-11-11 14:27 ` [RFC 4/4] pci/sriov: add sriov_scan_vf_id interface Longpeng(Mike)
2022-11-11 16:39 ` [RFC 0/4] pci/sriov: support VFs dynamic addition Leon Romanovsky
2022-11-13 13:47   ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2022-11-14  7:04     ` Leon Romanovsky
2022-11-14 12:38       ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2022-11-14 13:09         ` Leon Romanovsky
2022-11-14 14:06           ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2022-11-14 14:20             ` Leon Romanovsky
2022-11-15  1:38               ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2022-11-15  1:50               ` Oliver O'Halloran
2022-11-15  8:32                 ` Leon Romanovsky
2022-11-15  9:36                   ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2022-11-15 10:02                     ` Leon Romanovsky [this message]
2022-11-15 10:27                       ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2022-11-15 12:49                   ` Oliver O'Halloran
2022-11-15  2:06             ` Oliver O'Halloran
2022-11-16  0:52               ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2022-11-11 23:07 ` Bjorn Helgaas
2022-11-13 13:49   ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y3NjslijVKfLQo3W@unreal \
    --to=leon@kernel.org \
    --cc=arei.gonglei@huawei.com \
    --cc=bhelgaas@google.com \
    --cc=huangzhichao@huawei.com \
    --cc=jianjay.zhou@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=longpeng2@huawei.com \
    --cc=oohall@gmail.com \
    --cc=xiehong@huawei.com \
    --cc=yechuan@huawei.com \
    --cc=zhuangshengen@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox