From: marc.sune@gmail.com [mailto:marc.sune@gmail.com] On Behalf Of Marc
Sent: Tuesday, February 2, 2016 8:04 AM
To: Zhang, Helin
Cc: Ananyev, Konstantin; Thomas Monjalon; dev@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 [off-list ref] wrote:

quoted

-----Original Message-----
From: Ananyev, Konstantin
Sent: Friday, January 29, 2016 6:18 PM
To: Thomas Monjalon
Cc: dev@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

quoted

-----Original Message-----
From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
Sent: Friday, January 29, 2016 9:54 AM
To: Ananyev, Konstantin
Cc: dev@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:

quoted

From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]

quoted

2016-01-29 09:24, Ananyev, Konstantin:

quoted

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.

quoted

quoted

quoted

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.

quoted

quoted

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.

quoted

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.

quoted

We have an agreement to not touch them in DPDK

Yes.

quoted

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

quoted

Konstantin