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

[Marc]

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?

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
>
> >
> > Konstantin
>
>