[dpdk-dev] FW: [PATCH v7 3/5] ethdev: redesign link speed config API

[Zhang, Helin]

>From: marc.sune at gmail.com [mailto:marc.sune at gmail.com] On Behalf Of Marc
>Sent: Tuesday, February 2, 2016 8:04 AM
>To: Zhang, Helin
>Cc: Ananyev, Konstantin; Thomas Monjalon; dev at dpdk.org; Lu, Wenzhuo; Harish Patil; Chen, Jing D; Mcnamara, John
>Subject: Re: [dpdk-dev] [PATCH v7 3/5] ethdev: redesign link speed config API
>
>
>
>On 1 February 2016 at 01:40, Zhang, Helin <helin.zhang at intel.com> wrote:
>
>
>> -----Original Message-----
>> From: Ananyev, Konstantin
>> Sent: Friday, January 29, 2016 6:18 PM
>> To: Thomas Monjalon
>> Cc: dev at dpdk.org; Marc Sune; Lu, Wenzhuo; Zhang, Helin; Harish Patil; Chen,
>> Jing D; Mcnamara, John
>> Subject: RE: [dpdk-dev] [PATCH v7 3/5] ethdev: redesign link speed config
>> API
>>
>>
>>
>> > -----Original Message-----
>> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> > Sent: Friday, January 29, 2016 9:54 AM
>> > To: Ananyev, Konstantin
>> > Cc: dev at dpdk.org; Marc Sune; Lu, Wenzhuo; Zhang, Helin; Harish Patil;
>> > Chen, Jing D; Mcnamara, John
>> > Subject: Re: [dpdk-dev] [PATCH v7 3/5] ethdev: redesign link speed
>> > config API
>> >
>> > 2016-01-29 09:47, Ananyev, Konstantin:
>> > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> > > > 2016-01-29 09:24, Ananyev, Konstantin:
>> > > > > Can you avoid modifications in the e1000/base code?
>> > > > > We do not modify (and maintain) that part on our own.
>> > > > > Instead we take it straight from Intel ND.
>> > > > > So if you feel like these changes are really necessary - please
>> > > > > submit a patch to ND first, and if your changes will be applied, will pick
>> it up from them.
>> > > >
>> > > > I was not aware we can submit a change to ND for Intel base drivers.
>> > > > What is the procedure please?
>> > >
>> > > I meant not to the ND directly, but probably to the freebsd e1000 kernel
>> driver.
>> > > As I remember, that is the closest one to what we have.
>> > > From my understanding (I might be wrong here):
>> > > If they will be accepted, we should see these changes In next code drops
>> from ND.
>> >
>> > These base drivers are used in several places.
>> > We are allowed to submit a patch in Linux or FreeBSD but not in DPDK
>> > where the base driver is verbatim?
>>
>> Yes, that's my understanding.
>>
>> > We have an agreement to not touch them in DPDK
>>
>> Yes.
>>
>> > but I still think the
>> > ND team could consider some patches from dpdk.org.
>>
>> I personally think that would be a good thing, but it is up to ND guys to make
>> such decision.
>[Zhang, Helin] The key reason of not touching base driver is we don't want to
>maintain those source files, and just reuse others. 
>
>So files under base/ strictly copies of what is in this other Intel repository (ND) or there are modifications?
Long time ago, those source files were copied from FreeBSD version of driver, without any modification.
Though there is a bit different from that time, but they are similar.
Note that 'base/i40e_osdep.h or ixgbe_osdep.h' is the only file we can modify to support DPDK.
Of cause, all other files than base driver are what we developed, and can be modified.

>
>If IIRC rte_link was crafted so that matches e1000 (at least) so that link reads can be done atomically. I think it makes more sense that ethdev has a generic, device independent struct and that drivers handle the translation, if necessary. Do we agree on this?
I agree with you to have a generic structure in ethdev, and it can be filled with information obtained from base driver.

>
>This can help us a lot.
>We should try to avoid touching source files in base driver, but if you still insist
>something critical or a bug should be faced. First of all we can try to do something
>in the dpdk developed source files (e.g. i40e_ethdev.c, i40e_rxtx.c, i40e_osdep.h).
>This was what we have done for a long time, and it works quite well.
>If there is no other way to fix a bug in base driver, we can try the way like
>Konstantin indicated, or let me know, I will try to influence ND. But note that this
>might be the lowest efficiency way, due to the complicated process. 
>
>Sorry for any inconvenience! This the way we are using now might be the best for
>us right now.
>
>I will go back and redesign commit 3 in the series once more. I will need some time (other things in the pipeline). I would have appreciated rising this red flag in one of the 6 previous versions.
Thank you very much for the helps, and patience!

Regards,
Helin

>
>marc
> 
>
>Regards,
>Heiln
>
>>
>> Konstantin
>