On Wed, 7 Jun 2023 19:47:04 +0100 Ferruh Yigit <ferruh.yi...@amd.com> wrote:
> On 5/16/2023 10:55 AM, Ferruh Yigit wrote: > > On 5/16/2023 2:28 AM, Stephen Hemminger wrote: > >> On Tue, 16 May 2023 00:35:56 +0100 > >> Ferruh Yigit <ferruh.yi...@amd.com> wrote: > >> > >>> Yes only some scripts and possible applications that hotplug tap > >>> interface with hardcoded parameters may impacted, don't know how big is > >>> this amount but this ends up breaking something that was working before > >>> upgrading DPDK for them. > >>> > >>> And I believe the motivation is weak to break the behavior. > >>> > >>> Won't it be better to update 'rte_ether_unformat_addr()' to accept more > >>> flexible syntax, and use it? Is there any disadvantage of this approach? > >> > >> It is already more flexible than the standard ether_aton(). > > > > I mean to accept single chars, as 'tap' currently does, like "a:a:a:a:a:a". > > > > Agree that impact of tap change is small, but if we can eliminate it > > completely without any side affect, why not? > > > > > > As accepting single char will be expanding 'rte_ether_unformat_addr()' > > capability, it will be backward compatible, am I missing anything? I did a little poking around. The single character format is actually non standard. It would be good to extend rte_unformat_ether_addr to allow a wider range of formats including all those used by Windows, IEEE, and network vendors.
