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?
