[PATCH] net/tap: add new macpair option for split MAC address

[Morten Brørup]

> From: Isaac Boukris [mailto:iboukris at gmail.com]
> Sent: Tuesday, 17 September 2024 08.49
> 
> Hi Stephen
> 
> On Tue, Sep 17, 2024 at 6:36 AM Stephen Hemminger
> <stephen at networkplumber.org> wrote:
> >
> > On Mon, 16 Sep 2024 20:38:51 +0300
> > Isaac Boukris <iboukris at gmail.com> wrote:
> >
> > > +             if (mac_pair) {
> > > +                     struct rte_ether_addr *mac;
> > > +                     mac = (struct
> rte_ether_addr*)ifr.ifr_hwaddr.sa_data;
> > > +                     mac->addr_bytes[3]++;
> >
> > You need to generate a new MAC to be safe, just incrementing by one can
> > easily cause address conflicts.
> 
> I assumed these two MACs would be the only ones connected to the link,
> so it should be ok. If I generate a new random one, should I just
> assume it is unlikely I got the same?

When not using globally administered MAC addresses (which are globally unique, due to their creation process), there's always a risk of address conflicts.

The best option available to generate a random address is rte_eth_random_addr(), also in this case.
With 46 random bits, it is extremely unlikely that you get the same address. Regardless, it doesn't hurt checking.