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