| Message ID | 20230427020917.12029-1-emil.s.tantilov@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce Intel IDPF driver | expand |
On Wed, 26 Apr 2023 19:09:02 -0700 Emil Tantilov wrote: > This patch series introduces the Intel Infrastructure Data Path Function > (IDPF) driver. It is used for both physical and virtual functions. Except > for some of the device operations the rest of the functionality is the > same for both PF and VF. IDPF uses virtchnl version2 opcodes and > structures defined in the virtchnl2 header file which helps the driver > to learn the capabilities and register offsets from the device > Control Plane (CP) instead of assuming the default values. This is not the right time to post patches, see below. Please have Tony/Jesse take over posting of this code to the list going forward. Intel has a history of putting upstream training on the community, we're not going thru this again. ## Form letter - net-next-closed The merge window for v6.3 has begun and therefore net-next is closed for new drivers, features, code refactoring and optimizations. We are currently accepting bug fixes only. Please repost when net-next reopens after May 8th. RFC patches sent for review only are obviously welcome at any time. See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle
On 4/26/2023 7:46 PM, Jakub Kicinski wrote: > On Wed, 26 Apr 2023 19:09:02 -0700 Emil Tantilov wrote: >> This patch series introduces the Intel Infrastructure Data Path Function >> (IDPF) driver. It is used for both physical and virtual functions. Except >> for some of the device operations the rest of the functionality is the >> same for both PF and VF. IDPF uses virtchnl version2 opcodes and >> structures defined in the virtchnl2 header file which helps the driver >> to learn the capabilities and register offsets from the device >> Control Plane (CP) instead of assuming the default values. > > This is not the right time to post patches, see below. > > Please have Tony/Jesse take over posting of this code to the list > going forward. Intel has a history of putting upstream training on > the community, we're not going thru this again. > > > ## Form letter - net-next-closed > > The merge window for v6.3 has begun and therefore net-next is closed > for new drivers, features, code refactoring and optimizations. > We are currently accepting bug fixes only. > > Please repost when net-next reopens after May 8th. > > RFC patches sent for review only are obviously welcome at any time. > > See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle The v3 series are primarily for review on IWL (to intel-wired-lan, netdev cc-ed) as follow up for the feedback we received on v2. Was I not supposed to cc netdev in the quiet period? Thanks, Emil
On Wed, 26 Apr 2023 19:55:06 -0700 Tantilov, Emil S wrote: > The v3 series are primarily for review on IWL (to intel-wired-lan, > netdev cc-ed) as follow up for the feedback we received on v2. Well, you put net-next in the subject. > Was I not supposed to cc netdev in the quiet period? That's what you got from my previous email? Did you read it? The answer was there :| The community volunteers can't be expected to help teach every team of every vendor the process. That doesn't scale and leads to maintainer frustration. You have a team at Intel which is strongly engaged upstream (Jesse, Jake K, Maciej F, Alex L, Tony etc.) - I'd much rather interface with them. Jesse, does it sound workable to you? What do you have in mind in terms of the process long term if/once this driver gets merged?
On 4/26/2023 8:29 PM, Jakub Kicinski wrote: > On Wed, 26 Apr 2023 19:55:06 -0700 Tantilov, Emil S wrote: >> The v3 series are primarily for review on IWL (to intel-wired-lan, >> netdev cc-ed) as follow up for the feedback we received on v2. > > Well, you put net-next in the subject. We tried to convey intent via the To: and CC: lists, but this review is continuing across multiple merge windows and we previously had been sending with net-next in the Subject and had continued in that vein, so we intended to convey the "request for continued review" via the headers, but didn't mean to violate the "net-next is closed! Don't send patches with the Subject net-next!" rule. I reviewed these patches but didn't block Emil from sending v3 (right now vs waiting until net-next opens). from the other reply: > RFC patches sent for review only are obviously welcome at any time. In the past, we had developed an allergy to using RFC when we want comments back as the patches had sometimes been ignored when RFC and then heavily commented upon/rejected as a "real submittal". This may not be the case anymore, and if so, we need to adjust our expectations and would be glad to do so. In this case, it didn’t feel right to switch a series from “in-review” to RFC on v3. > Jesse, does it sound workable to you? What do you have in mind in terms > of the process long term if/once this driver gets merged? Sorry for the thrash on this one. We have a proposal by doing these two things in the future: 1) to: intel-wired-lan, cc: netdev until we've addressed review comments 2) use [iwl-next ] or [iwl-net] in the Subject: when reviewing on intel-wired-lan, and cc:netdev, to make clear the intent in both headers and Subject line. There are two discussions here 1) we can solve the "net-next subject" vs cc:netdev via my proposal above, would appreciate your feedback. 2) Long term, this driver will join the "normal flow" of individual patch series that are sent to intel-wired-lan and cc:netdev, but I'd like those that are sent from Intel non-maintainers to always use [iwl-next], [iwl-net], and Tony or I will provide series to: maintainers, cc:netdev with the Subject: [net-next] or [net]
On Thu, 27 Apr 2023 15:23:12 -0700 Jesse Brandeburg wrote: > > Jesse, does it sound workable to you? What do you have in mind in terms > > of the process long term if/once this driver gets merged? > > Sorry for the thrash on this one. > > We have a proposal by doing these two things in the future: > 1) to: intel-wired-lan, cc: netdev until we've addressed review comments > 2) use [iwl-next ] or [iwl-net] in the Subject: when reviewing on > intel-wired-lan, and cc:netdev, to make clear the intent in both headers > and Subject line. > > There are two discussions here > 1) we can solve the "net-next subject" vs cc:netdev via my proposal > above, would appreciate your feedback. > 2) Long term, this driver will join the "normal flow" of individual > patch series that are sent to intel-wired-lan and cc:netdev, but I'd > like those that are sent from Intel non-maintainers to always use > [iwl-next], [iwl-net], and Tony or I will provide series to: > maintainers, cc:netdev with the Subject: [net-next] or [net] Sounds like a good scheme, let's try it! Thanks!
On 5/2/2023 7:20 PM, Jakub Kicinski wrote: > On Thu, 27 Apr 2023 15:23:12 -0700 Jesse Brandeburg wrote: >> We have a proposal by doing these two things in the future: >> 1) to: intel-wired-lan, cc: netdev until we've addressed review comments >> 2) use [iwl-next ] or [iwl-net] in the Subject: when reviewing on >> intel-wired-lan, and cc:netdev, to make clear the intent in both headers >> and Subject line. > > Sounds like a good scheme, let's try it! > Thanks! Ok, we'll start implementing.