git: 68a46f11eada - main - e1000: Restore VF interface random MAC

[Kyle Evans]

I think it'd be the right choice, but it needs a little work first.
e.g., it's not a good fit right now for VMs that don't use loader, for
instance, because it relies on the hostuuid actually being somewhat
unique or else it generates the same MAC address across different VMs
and you end up with conflicts in the broadcast domain. I think there's
a good argument to make for having it check if the hostuuid is the
default all-0 hostuuid and just generating a random address as this
does right now. I might go ahead and prepare such a change and
document the KPI in the process.

On Thu, Apr 15, 2021 at 3:06 PM Kevin Bowling <kevin.bowling at kev009.com> wrote:
>
> I would like to discuss this further, it crossed my mind, but none of
> the intel drivers currently use it.  If this is the right KPI I think
> a review should be prepared that updates e1000, ixgbe (ixv), ixl
> (iavf) in one go.
>
> Regards,
> Kevin
>
> On Thu, Apr 15, 2021 at 12:36 PM Kyle Evans <kevans at freebsd.org> wrote:
> >
> > On Thu, Apr 15, 2021 at 2:32 PM Ronald Klop <ronald-lists at klop.ws> wrote:
> > >
> > > On 4/15/21 8:48 PM, Kevin Bowling wrote:
> > > > The branch main has been updated by kbowling (ports committer):
> > > >
> > > > URL: https://cgit.FreeBSD.org/src/commit/?id=68a46f11eadab48a1da9e3d3900569a6a1ce142e
> > > >
> > > > commit 68a46f11eadab48a1da9e3d3900569a6a1ce142e
> > > > Author:     Kevin Bowling <kbowling at FreeBSD.org>
> > > > AuthorDate: 2021-04-15 18:45:02 +0000
> > > > Commit:     Kevin Bowling <kbowling at FreeBSD.org>
> > > > CommitDate: 2021-04-15 18:45:02 +0000
> > > >
> > > >      e1000: Restore VF interface random MAC
> > > >
> > > >      Restore 525e07418c77 after the iflib conversion of igb(4). This
> > > >      reenables random MAC address generation when attaching to a VF with a
> > > >      zeroed MAC.
> > > >
> > > >      PR:             253535
> > > >      Reported by:    Balaev PA <mail at void.so>
> > > >      Reviewed by:    markj
> > > >      MFC after:      2 weeks
> > > >      Differential Revision:  https://reviews.freebsd.org/D29785
> > > > ---
> > > >   sys/dev/e1000/if_em.c | 21 ++++++++++++++++++---
> > > >   1 file changed, 18 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/sys/dev/e1000/if_em.c b/sys/dev/e1000/if_em.c
> > > > index 6f022c80c01c..79a617b3342f 100644
> > > > --- a/sys/dev/e1000/if_em.c
> > > > +++ b/sys/dev/e1000/if_em.c
> > > > @@ -1061,9 +1061,17 @@ em_if_attach_pre(if_ctx_t ctx)
> > > >       }
> > > >
> > > >       if (!em_is_valid_ether_addr(hw->mac.addr)) {
> > > > -             device_printf(dev, "Invalid MAC address\n");
> > > > -             error = EIO;
> > > > -             goto err_late;
> > > > +             if (adapter->vf_ifp) {
> > > > +                     u8 addr[ETHER_ADDR_LEN];
> > > > +                     arc4rand(&addr, sizeof(addr), 0);
> > > > +                     addr[0] &= 0xFE;
> > > > +                     addr[0] |= 0x02;
> > > > +                     bcopy(addr, hw->mac.addr, sizeof(addr));
> > > > +             } else {
> > > > +                     device_printf(dev, "Invalid MAC address\n");
> > > > +                     error = EIO;
> > > > +                     goto err_late;
> > > > +             }
> > >
> > >
> > > Just curious. Would ether_gen_addr() be useful here?
> > > It is implemented in net/if_ethersubr.c.
> > >
> >
> > I had asked myself the same question, but I suspect these machines may
> > not necessarily have a hostuuid preloaded to avoid collisions from the
> > generated addresses.
> >
> > Thanks,
> >
> > Kyle Evans