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,

quoted

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

quoted

it up from them.

quoted

quoted

quoted

I was not aware we can submit a change to ND for Intel base

drivers.

quoted

quoted

quoted

quoted

What is the procedure please?

I meant not to the ND directly, but probably to the freebsd e1000

kernel

quoted

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

quoted

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

quoted

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?

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?

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.

marc

Regards,
Heiln

quoted

Konstantin