On 9/29/23 6:48 AM, Ferruh Yigit wrote:
On 6/7/2023 7:47 PM, Ferruh Yigit 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 <[email protected]> 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?
Hi David,
If API update is not planned, what do you think to just solve the build
error without changing functionality with a change something like below:
```
- (strlen(mac_byte) == strspn(mac_byte,
- ETH_TAP_CMP_MAC_FMT))) {
+ (strlen(mac_byte) == strspn(mac_byte, ETH_TAP_CMP_MAC_FMT)) &&
+ index < RTE_ETHER_ADDR_LEN) {
```
Hi David,
If you can confirm above fixes the issue, I can send a patch for it.
Confirmed that your proposed change resolves the build issue on ppc64le.
Appreciate if you can submit the patch.
Dave
