[dpdk-dev] [PATCH v8 03/14] eal/pci, ethdev: Remove assumption that port will not be detached

Iremonger, Bernard bernard.iremonger at intel.com
Wed Feb 18 10:27:02 CET 2015



> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa
> Sent: Wednesday, February 18, 2015 6:10 AM
> To: Thomas Monjalon
> Cc: dev at dpdk.org; Neil Horman
> Subject: Re: [dpdk-dev] [PATCH v8 03/14] eal/pci, ethdev: Remove assumption that port will not be
> detached
> 
> On 2015/02/18 10:54, Tetsuya Mukawa wrote:
> > On 2015/02/18 9:31, Thomas Monjalon wrote:
> >> 2015-02-17 15:14, Tetsuya Mukawa:
> >>> On 2015/02/17 9:36, Thomas Monjalon wrote:
> >>>> 2015-02-16 13:14, Tetsuya Mukawa:
> >>>> Is uint8_t sill a good size for hotpluggable virtual device ids?
> >>> I am not sure it's enough, but uint8_t is widely used in "rte_ethdev.c"
> >>> as port id.
> >>> If someone reports it doesn't enough, I guess it will be the time to
> >>> write a patch to change all uint_8 in one patch.
> >> It's a big ABI breakage. So if we feel it's going to be required,
> >> it's better to do it now in 2.0 release I think.
> >>
> >> Any opinion?
> >>
> > Hi Thomas,
> >
> > I agree with it.
> > I will add an one more patch to change uint8_t to uint16_t.
> >
> > Thanks,
> > Tetsuya
> >
> 
> Hi Thomas,
> 
> Could I make sure.
> After changing uint8_t to uint16_t in "rte_ethdev.[ch]", must I also need to change other applications
> and libraries that call ethdev APIs?
> If so, I would not finish it by 23rd.
> 
> I've counted how many lines call ethdev APIs that are related to port_id.
> Could you please check an attached file?
> It's over 1200 lines. Probably to fix  one of caller, I will need to check how port_id is used, and fix more
> related lines. So probably thousands lines may need to be fixed.
> 
> When is deadline for fixing this changing?
> Also, if you have a good idea to fix it easier, could you please let me know?
> 
> Thanks,
> Tetsuya

Hi Tetsuya, Thomas,

As uint8_t is already widely used for port_id, I don't think it should be changed in this patchset.
If it is to be changed to uint16_t it should be done as a separate task (in a new patchset).

Regards,

Bernard.





More information about the dev mailing list