Fwd: [ofa-general] FW: QLogic vNIC Kernel Submission

Fwd: [ofa-general] FW: QLogic vNIC Kernel Submission

[Amar Mudrankit]

---------- Forwarded message ----------
From: John Russo <john.russo@qlogic.com>
Date: Tue, Jun 17, 2008 at 6:36 PM
Subject: [ofa-general] FW: QLogic vNIC Kernel Submission
To: general@lists.openfabrics.org


It looks as if my original email was "scrubbed" before it made the
mailing list so I am resending it...

QLogic has been attempting to submit our virtual NIC (vNIC) driver to
the Linux kernel for several months.  We have made changes to the code
based on the feedback we have received over four rounds of
submissions. Among the feedback we received during this process was a
request to alter our code to use a single value per file for
configuration of our driver through sysfs interface.  After spending
much time and effort to complete this change to our design we
re-submitted the driver only to receive a response suggesting that we
change once again from this interface to a different API interface
called rtnl_link.  Needless to say I am very frustrated with this
process. This new API interface would require substantial changes to
our code.

QLogic has met the initial request to move to a single valued sysfs
interface and I would hope that this new request will be waived and
will not be a roadblock to inclusion of our driver to the kernel.

_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: Fwd: [ofa-general] FW: QLogic vNIC Kernel Submission

[Patrick McHardy]

Amar Mudrankit wrote:
> It looks as if my original email was "scrubbed" before it made the
> mailing list so I am resending it...
> 
> QLogic has been attempting to submit our virtual NIC (vNIC) driver to
> the Linux kernel for several months.  We have made changes to the code
> based on the feedback we have received over four rounds of
> submissions. Among the feedback we received during this process was a
> request to alter our code to use a single value per file for
> configuration of our driver through sysfs interface.  After spending
> much time and effort to complete this change to our design we
> re-submitted the driver only to receive a response suggesting that we
> change once again from this interface to a different API interface
> called rtnl_link.  Needless to say I am very frustrated with this
> process. This new API interface would require substantial changes to
> our code.

Thats one of the reasons why it should be done before merging it.
The other one being that an API can't be removed easily once its
in the kernel.

Re: Fwd: [ofa-general] FW: QLogic vNIC Kernel Submission

[Stephen Hemminger]

On Tue, 17 Jun 2008 20:34:59 +0200
Patrick McHardy <kaber@trash.net> wrote:

> Amar Mudrankit wrote:
> > It looks as if my original email was "scrubbed" before it made the
> > mailing list so I am resending it...
> > 
> > QLogic has been attempting to submit our virtual NIC (vNIC) driver to
> > the Linux kernel for several months.  We have made changes to the code
> > based on the feedback we have received over four rounds of
> > submissions. Among the feedback we received during this process was a
> > request to alter our code to use a single value per file for
> > configuration of our driver through sysfs interface.  After spending
> > much time and effort to complete this change to our design we
> > re-submitted the driver only to receive a response suggesting that we
> > change once again from this interface to a different API interface
> > called rtnl_link.  Needless to say I am very frustrated with this
> > process. This new API interface would require substantial changes to
> > our code.
> 
> Thats one of the reasons why it should be done before merging it.
> The other one being that an API can't be removed easily once its
> in the kernel.

Understand that this is a community process and it isn't going to follow
a corporate model. There is no external pressures like schedules and users.
As Patrick said, there is also a sense of doing the right thing. The developers
would rather not repeat past mistakes, so are naturally hesitant on API's.
Adding a device that follows existing API's is always much easier. What you are
seeing is in part an internal discomfort with the plethora of API's and the binary
baggage of ioctl's, sysfs, etc.

If you could give a general outline of what the interface you want would do,
perhaps the community could provide some sample code that do what you want.
Netlink interfaces are less common, and there are fewer examples.

Re: Fwd: [ofa-general] FW: QLogic vNIC Kernel Submission

[Patrick McHardy]

Patrick McHardy wrote:
> Amar Mudrankit wrote:
>> It looks as if my original email was "scrubbed" before it made the
>> mailing list so I am resending it...
>>
>> QLogic has been attempting to submit our virtual NIC (vNIC) driver to
>> the Linux kernel for several months.  We have made changes to the code
>> based on the feedback we have received over four rounds of
>> submissions. Among the feedback we received during this process was a
>> request to alter our code to use a single value per file for
>> configuration of our driver through sysfs interface.  After spending
>> much time and effort to complete this change to our design we
>> re-submitted the driver only to receive a response suggesting that we
>> change once again from this interface to a different API interface
>> called rtnl_link.  Needless to say I am very frustrated with this
>> process. This new API interface would require substantial changes to
>> our code.
> 
> Thats one of the reasons why it should be done before merging it.
> The other one being that an API can't be removed easily once its
> in the kernel.


Besides that, the state machine triggered device registration
and the sysfs based checksumming settings of also need to go (both
should be about 5 minutes of work by the way).

RE: Fwd: [ofa-general] FW: QLogic vNIC Kernel Submission

[John Russo]

Stephen,

>> Understand that this is a community process and it isn't going to
follow 
>> a corporate model. There is no external pressures like schedules and
>> users.

With all due respect...
In my mind, that is just not realistic.  Work done in this community has
very strong corporate repercussions and these issues can't simply be
ignored. I am not saying that the community should ever alter their
ideals for any company, just that some people/groups/companies will be
reluctant to even try to contribute if they feel that guidelines like
this can be changed this way and make their efforts wasted.

>> As Patrick said, there is also a sense of doing the right thing. The 
>> developers would rather not repeat past mistakes, so are naturally 
>> hesitant on API's.

I completely understand the sense of doing the right thing. That is why
we put in the effort to migrate our code to sysfs in the first place.
We had a different solution but agreed to change it to meet the
guidelines of other contributors to the InfiniBand (OFED) stack.  What I
can't understand is the ease of which some people say "let's just change
to this great new design even if it means a large rewrite of existing
code which may increase the likelihood of injecting errors".  I
apologize if I come off as being agitated but it is very frustrating to
spend time and effort attempting to conform to a groups requests only to
have it changed at the end. 

>> Adding a device that follows existing API's is always much easier.
What 
>> you are seeing is in part an internal discomfort with the plethora of

>> API's and the binary baggage of ioctl's, sysfs, etc.

Again, I completely understand the level of discomfort.  We are trying
to work to the same 'rules' that other members of our community have
used.

>> If you could give a general outline of what the interface you want
would >> do, perhaps the community could provide some sample code that
do what you 
>> want.
>> Netlink interfaces are less common, and there are fewer examples.

-----Original Message-----
From: Stephen Hemminger [mailto:shemminger@vyatta.com]
Sent: Wed 6/18/2008 12:44 AM
To: Patrick McHardy
Cc: Amar Mudrankit (Contractor - ); netdev@vger.kernel.org;
rdreier@cisco.com; Kuchimanchi, Ramachandra (Contractor - ); Poornima
Kamath (Contractor - )
Subject: Re: Fwd: [ofa-general] FW: QLogic vNIC Kernel Submission
 
On Tue, 17 Jun 2008 20:34:59 +0200
Patrick McHardy <kaber@trash.net> wrote:

> Amar Mudrankit wrote:
> > It looks as if my original email was "scrubbed" before it made the
> > mailing list so I am resending it...
> > 
> > QLogic has been attempting to submit our virtual NIC (vNIC) driver
to
> > the Linux kernel for several months.  We have made changes to the
code
> > based on the feedback we have received over four rounds of
> > submissions. Among the feedback we received during this process was
a
> > request to alter our code to use a single value per file for
> > configuration of our driver through sysfs interface.  After spending
> > much time and effort to complete this change to our design we
> > re-submitted the driver only to receive a response suggesting that
we
> > change once again from this interface to a different API interface
> > called rtnl_link.  Needless to say I am very frustrated with this
> > process. This new API interface would require substantial changes to
> > our code.
> 
> Thats one of the reasons why it should be done before merging it.
> The other one being that an API can't be removed easily once its
> in the kernel.

Re: Fwd: [ofa-general] FW: QLogic vNIC Kernel Submission

[Patrick McHardy]

John Russo wrote:
>>> As Patrick said, there is also a sense of doing the right thing. The 
>>> developers would rather not repeat past mistakes, so are naturally 
>>> hesitant on API's.
>>>       
>
> I completely understand the sense of doing the right thing. That is why
> we put in the effort to migrate our code to sysfs in the first place.
> We had a different solution but agreed to change it to meet the
> guidelines of other contributors to the InfiniBand (OFED) stack.  What I
> can't understand is the ease of which some people say "let's just change
> to this great new design even if it means a large rewrite of existing
> code which may increase the likelihood of injecting errors".  I
> apologize if I come off as being agitated but it is very frustrating to
> spend time and effort attempting to conform to a groups requests only to
> have it changed at the end. 
>   

Frankly, you didn't even try to fix the most obvious mistakes in your
interface, like duplication of existing interfaces (csum settings)
and very unusual behaviour (state machine triggered device registation)
before you started complaining (and both of these are *really* easy to
do).

That you were asked to migrate to sysfs is unfortunate. The fact is
though that your driver is a virtual ethernet device, not an infiniband
device, so it should use the proper APIs for this kind of device. Work
has been going on for years to provide a uniform interface to the network
and your interface is a move in the opposite direction.

Re: Fwd: [ofa-general] FW: QLogic vNIC Kernel Submission

[Jeff Garzik]

Patrick McHardy wrote:
> Frankly, you didn't even try to fix the most obvious mistakes in your
> interface, like duplication of existing interfaces (csum settings)
> and very unusual behaviour (state machine triggered device registation)
> before you started complaining (and both of these are *really* easy to
> do).
> 
> That you were asked to migrate to sysfs is unfortunate. The fact is
> though that your driver is a virtual ethernet device, not an infiniband
> device, so it should use the proper APIs for this kind of device. Work
> has been going on for years to provide a uniform interface to the network
> and your interface is a move in the opposite direction.

That's pretty much my feeling.

	Jeff

Re: Fwd: [ofa-general] FW: QLogic vNIC Kernel Submission

[Jeff Garzik]

Amar Mudrankit wrote:
> ---------- Forwarded message ----------
> From: John Russo <john.russo@qlogic.com>
> Date: Tue, Jun 17, 2008 at 6:36 PM
> Subject: [ofa-general] FW: QLogic vNIC Kernel Submission
> To: general@lists.openfabrics.org
> 
> 
> It looks as if my original email was "scrubbed" before it made the
> mailing list so I am resending it...
> 
> QLogic has been attempting to submit our virtual NIC (vNIC) driver to
> the Linux kernel for several months.  We have made changes to the code
> based on the feedback we have received over four rounds of
> submissions. Among the feedback we received during this process was a
> request to alter our code to use a single value per file for
> configuration of our driver through sysfs interface.  After spending
> much time and effort to complete this change to our design we
> re-submitted the driver only to receive a response suggesting that we
> change once again from this interface to a different API interface
> called rtnl_link.  Needless to say I am very frustrated with this
> process. This new API interface would require substantial changes to
> our code.
> 
> QLogic has met the initial request to move to a single valued sysfs
> interface and I would hope that this new request will be waived and
> will not be a roadblock to inclusion of our driver to the kernel.

One option is to get the base driver into the tree, sans sysfs 
interface, and wait for the netlink interface.

As Patrick noted, it is very important to -not- just throw new user 
interfaces into the tree, because that essentially sets them in stone at 
that point, needing to be supported as an Application Binary Interface 
(ABI).

The other stuff, like duplication of existing interfaces and strange 
FSM-based netdev registration, are problems that could be worked out 
in-tree, I suppose.

	Jeff

Re: Fwd: [ofa-general] FW: QLogic vNIC Kernel Submission

[Patrick McHardy]

Jeff Garzik wrote:
> Amar Mudrankit wrote:
>> ---------- Forwarded message ----------
>> From: John Russo <john.russo@qlogic.com>
>> Date: Tue, Jun 17, 2008 at 6:36 PM
>> Subject: [ofa-general] FW: QLogic vNIC Kernel Submission
>> To: general@lists.openfabrics.org
>>
>>
>> It looks as if my original email was "scrubbed" before it made the
>> mailing list so I am resending it...
>>
>> QLogic has been attempting to submit our virtual NIC (vNIC) driver to
>> the Linux kernel for several months.  We have made changes to the code
>> based on the feedback we have received over four rounds of
>> submissions. Among the feedback we received during this process was a
>> request to alter our code to use a single value per file for
>> configuration of our driver through sysfs interface.  After spending
>> much time and effort to complete this change to our design we
>> re-submitted the driver only to receive a response suggesting that we
>> change once again from this interface to a different API interface
>> called rtnl_link.  Needless to say I am very frustrated with this
>> process. This new API interface would require substantial changes to
>> our code.
>>
>> QLogic has met the initial request to move to a single valued sysfs
>> interface and I would hope that this new request will be waived and
>> will not be a roadblock to inclusion of our driver to the kernel.
> 
> One option is to get the base driver into the tree, sans sysfs 
> interface, and wait for the netlink interface.
> 
> As Patrick noted, it is very important to -not- just throw new user 
> interfaces into the tree, because that essentially sets them in stone at 
> that point, needing to be supported as an Application Binary Interface 
> (ABI).
> 
> The other stuff, like duplication of existing interfaces and strange 
> FSM-based netdev registration, are problems that could be worked out 
> in-tree, I suppose.

That sounds fine to me. The duplication is even going away
automatically with removal of the sysfs interface.