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