| Message ID | 20220920151419.76050-1-simon.horman@corigine.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | nfp: support VF multi-queues configuration | expand |
On Tue, 20 Sep 2022 16:14:16 +0100 Simon Horman wrote: > this short series adds the max_vf_queue generic devlink device parameter, > the intention of this is to allow configuration of the number of queues > associated with VFs, and facilitates having VFs with different queue > counts. > > The series also adds support for multi-queue VFs to the nfp driver > and support for the max_vf_queue feature described above. I think a similar API was discussed in the past by... Broadcom? IIRC they wanted more flexibility, i.e. being able to set the guaranteed and max allowed queue count. Overall this seems like a typical resource division problem so we should try to use the devlink resource API or similar. More complex policies like guaranteed+max are going to be a pain over params. I wanted to ask a more general question, however. I see that you haven't CCed even the major (for some def.) vendors' maintainers. Would it be helpful for participation if we had a separate mailing list for discussing driver uAPI introduction which would hopefully be lower traffic? Or perhaps we can require a subject tag ([PATCH net-next uapi] ?) so that people can set up email filters? The cost is obviously yet another process thing to remember, and while this is nothing that lore+lei can't already do based on file path filters - I doubt y'all care enough to set that up for yourselves... :)
On Wed, Sep 21, 2022 at 06:34:48AM -0700, Jakub Kicinski wrote: > On Tue, 20 Sep 2022 16:14:16 +0100 Simon Horman wrote: > > this short series adds the max_vf_queue generic devlink device parameter, > > the intention of this is to allow configuration of the number of queues > > associated with VFs, and facilitates having VFs with different queue > > counts. > > > > The series also adds support for multi-queue VFs to the nfp driver > > and support for the max_vf_queue feature described above. > > I think a similar API was discussed in the past by... Broadcom? > IIRC they wanted more flexibility, i.e. being able to set the > guaranteed and max allowed queue count. > > Overall this seems like a typical resource division problem so > we should try to use the devlink resource API or similar. More > complex policies like guaranteed+max are going to be a pain over > params. > > > I wanted to ask a more general question, however. I see that you > haven't CCed even the major (for some def.) vendors' maintainers. Sorry about that. I should have considered doing so in the first place. > Would it be helpful for participation if we had a separate mailing > list for discussing driver uAPI introduction which would hopefully > be lower traffic? Or perhaps we can require a subject tag ([PATCH > net-next uapi] ?) so that people can set up email filters? > > The cost is obviously yet another process thing to remember, and > while this is nothing that lore+lei can't already do based on file > path filters - I doubt y'all care enough to set that up for > yourselves... :) Not defending myself here. And not sure if this is helpful. But the issue for me at the time was not being clear on how to reach the right audience.
On 21/09/2022 16:39, Simon Horman wrote: > On Wed, Sep 21, 2022 at 06:34:48AM -0700, Jakub Kicinski wrote: >> On Tue, 20 Sep 2022 16:14:16 +0100 Simon Horman wrote: >>> this short series adds the max_vf_queue generic devlink device parameter, >>> the intention of this is to allow configuration of the number of queues >>> associated with VFs, and facilitates having VFs with different queue >>> counts. >>> >>> The series also adds support for multi-queue VFs to the nfp driver >>> and support for the max_vf_queue feature described above. >> I think a similar API was discussed in the past by... Broadcom? >> IIRC they wanted more flexibility, i.e. being able to set the >> guaranteed and max allowed queue count. >> >> Overall this seems like a typical resource division problem so >> we should try to use the devlink resource API or similar. More >> complex policies like guaranteed+max are going to be a pain over >> params. >> >> >> I wanted to ask a more general question, however. I see that you >> haven't CCed even the major (for some def.) vendors' maintainers. > Sorry about that. I should have considered doing so in the first place. > >> Would it be helpful for participation if we had a separate mailing >> list for discussing driver uAPI introduction which would hopefully >> be lower traffic? Or perhaps we can require a subject tag ([PATCH >> net-next uapi] ?) so that people can set up email filters? >> >> The cost is obviously yet another process thing to remember, and >> while this is nothing that lore+lei can't already do based on file >> path filters - I doubt y'all care enough to set that up for >> yourselves... :) It's not that simple though, this series for example doesn't touch any uapi files directly. > Not defending myself here. And not sure if this is helpful. > But the issue for me at the time was not being clear on how to > reach the right audience. It's helpful if the right audience is subscribed to such list.
On Thu, 22 Sep 2022 16:37:21 +0300 Gal Pressman wrote: > >> The cost is obviously yet another process thing to remember, and > >> while this is nothing that lore+lei can't already do based on file > >> path filters - I doubt y'all care enough to set that up for > >> yourselves... :) > > It's not that simple though, this series for example doesn't touch any > uapi files directly. Right, the joys of devlink params. I'd suspect a good filter would need to match on both uapi and Documentation paths.
On Wed, Sep 21, 2022 at 06:34:48AM -0700, Jakub Kicinski wrote: > On Tue, 20 Sep 2022 16:14:16 +0100 Simon Horman wrote: > > this short series adds the max_vf_queue generic devlink device parameter, > > the intention of this is to allow configuration of the number of queues > > associated with VFs, and facilitates having VFs with different queue > > counts. <...> > Would it be helpful for participation if we had a separate mailing > list for discussing driver uAPI introduction which would hopefully > be lower traffic? Please don't. It will cause to an opposite situation where UAPI discussions will be hidden from most people. IMHO, every net vendor should be registered to netdev mailing list and read, review and participate. Thanks
On Thu, 22 Sep 2022 19:04:19 +0300 Leon Romanovsky wrote: > > Would it be helpful for participation if we had a separate mailing > > list for discussing driver uAPI introduction which would hopefully > > be lower traffic? > > Please don't. It will cause to an opposite situation where UAPI > discussions will be hidden from most people. Oh, it'd just be an additional list, the patches would still need to CC netdev. > IMHO, every net vendor should be registered to netdev mailing list > and read, review and participate. Alright, so we got two no votes so far.
On Thu, Sep 22, 2022 at 07:04:19PM +0300, Leon Romanovsky wrote: > On Wed, Sep 21, 2022 at 06:34:48AM -0700, Jakub Kicinski wrote: > > On Tue, 20 Sep 2022 16:14:16 +0100 Simon Horman wrote: > > > this short series adds the max_vf_queue generic devlink device parameter, > > > the intention of this is to allow configuration of the number of queues > > > associated with VFs, and facilitates having VFs with different queue > > > counts. > > <...> > > > Would it be helpful for participation if we had a separate mailing > > list for discussing driver uAPI introduction which would hopefully > > be lower traffic? > > Please don't. It will cause to an opposite situation where UAPI > discussions will be hidden from most people. IMHO, every net vendor > should be registered to netdev mailing list and read, review and > participate. Good in theory, but how often do you really see it happen? How many vendor developers really do review other vendors drivers patches. It tends to be vendor neutral reviewers who do reviews across multiple vendors. I wish there was more cross vendor review, it would prevent having to repeat the same review comments again and again. There is probably also a lot of good ideas in some drivers which should be spread to other drivers. But if you don't look outside your silo, you are blind to them. However, i do agree, although netdev is not perfect, i think it is better than another list which will get even more ignored. Andrew
On Thu, Sep 22, 2022 at 09:14:14AM -0700, Jakub Kicinski wrote: > On Thu, 22 Sep 2022 19:04:19 +0300 Leon Romanovsky wrote: > > > Would it be helpful for participation if we had a separate mailing > > > list for discussing driver uAPI introduction which would hopefully > > > be lower traffic? > > > > Please don't. It will cause to an opposite situation where UAPI > > discussions will be hidden from most people. > > Oh, it'd just be an additional list, the patches would still need > to CC netdev. First, there is already such ML: https://lore.kernel.org/linux-api/ Second, you disconnect discussion from actual patches and this can cause to repeating of same arguments while reviewing patches. > > > IMHO, every net vendor should be registered to netdev mailing list > > and read, review and participate. > > Alright, so we got two no votes so far.
On Thu, 22 Sep 2022 22:08:22 +0300 Leon Romanovsky wrote: > > > Please don't. It will cause to an opposite situation where UAPI > > > discussions will be hidden from most people. > > > > Oh, it'd just be an additional list, the patches would still need > > to CC netdev. > > First, there is already such ML: https://lore.kernel.org/linux-api/ > Second, you disconnect discussion from actual patches and this can > cause to repeating of same arguments while reviewing patches. I phrased what I meant poorly. The list would be in addition to netdev. All patches CCing the new list would also have to CC netdev. So if you subscribe and read netdev that'd be enough, no extra effort needed. So no disconnect from patches or repetition. linux-api is obviously not a subset of netdev, it's not a fit.
On Thu, Sep 22, 2022 at 07:37:08PM +0200, Andrew Lunn wrote: > On Thu, Sep 22, 2022 at 07:04:19PM +0300, Leon Romanovsky wrote: > > On Wed, Sep 21, 2022 at 06:34:48AM -0700, Jakub Kicinski wrote: > > > On Tue, 20 Sep 2022 16:14:16 +0100 Simon Horman wrote: > > > > this short series adds the max_vf_queue generic devlink device parameter, > > > > the intention of this is to allow configuration of the number of queues > > > > associated with VFs, and facilitates having VFs with different queue > > > > counts. > > > > <...> > > > > > Would it be helpful for participation if we had a separate mailing > > > list for discussing driver uAPI introduction which would hopefully > > > be lower traffic? > > > > Please don't. It will cause to an opposite situation where UAPI > > discussions will be hidden from most people. IMHO, every net vendor > > should be registered to netdev mailing list and read, review and > > participate. > > Good in theory, but how often do you really see it happen? I agree that the situation in netdev is not ideal, but it can be improved by slightly changing acceptance criteria. As a rough idea (influenced by DRM subsystem), require cross-vendor review prior merge. It doesn't need to be universal, and can be applicable only to most active companies. If reviews are not happening in sensible time frame, there are ways "to punish" vendor that was asked to review. Thanks