On (10/30/15 19:13), Sowmini Varadhan wrote:
> > In looking at a couple other drivers, I see the difference being that
> > they typically are writing the primary mac filter on probe (and any
> > other reset), whereas the i40e "knows" that the default mac address is
> > already set up as the filter and doesn't bother with a redundant write.
> > If you want to add this Open Filter code, you'll need to arrange for
> > this write to happen. You can't call i40e_set_mac() to do it, but you
> > can see the i40e_aq_mac_address_write() code there that is involved in
> > updating the mac address as an example. You probably will want to look
> > at section 4.2.1.5.3 of the XL710 data sheet in order to know how to
> > use i40e_aq_mac_address_write() for your situation.
>
> ok. I'll look into it (and also why this did not show up in my testing).
So I figured out why it all "seemed to work" - my test env had another
obscure init process that was marking the link promiscuous. I guess
that was having the side-effect of somehow setting the filters above.
But looks like there's more to getting this right than just calling
i40e_aq_mac_address_write() - I think it also needs a i40e_aq_add_macvlan().
I was able to get this to work by calling a the core part of
i40e_set_mac just before register_netdev. In my patch (RFC patch
in a separate thread - please review) I now have this sequence in
i40e_probe
err = i40e_get_platform_mac_addr(pdev, hw->mac.addr);
if (err)
i40e_get_mac_addr(hw, hw->mac.addr);
:
i40e_setup_pf_switch(..);
And the resulting i40e_vsi_setup() from i40e_setup_pf_switch()
will end up doing the right thing by invoking the guts of
i40e_set_mac(), which is basically the sequence:
i40e_aq_mac_address_write()
i40e_aq_add_macvlan()
I dont know if it is necessary/possible/important to set up the
filters sooner in the sequence- the add_macvlan needs an "seid",
and I could not tell when (in the ":" code above) the right seid
can be found.
Please review the RFC patch I'll be sending shortly.
--Sowmini
> -----Original Message-----
> From: Sowmini Varadhan [mailto:[email protected]]
> Sent: Sunday, November 01, 2015 8:24 AM
>
[...]
> So I figured out why it all "seemed to work" - my test env had another
> obscure init process that was marking the link promiscuous. I guess
> that was having the side-effect of somehow setting the filters above.
>
> But looks like there's more to getting this right than just calling
> i40e_aq_mac_address_write() - I think it also needs a
> i40e_aq_add_macvlan().
>
> I was able to get this to work by calling a the core part of
> i40e_set_mac just before register_netdev. In my patch (RFC patch
> in a separate thread - please review) I now have this sequence in
> i40e_probe
>
> err = i40e_get_platform_mac_addr(pdev, hw->mac.addr);
> if (err)
> i40e_get_mac_addr(hw, hw->mac.addr);
> :
> i40e_setup_pf_switch(..);
>
> And the resulting i40e_vsi_setup() from i40e_setup_pf_switch()
> will end up doing the right thing by invoking the guts of
> i40e_set_mac(), which is basically the sequence:
> i40e_aq_mac_address_write()
> i40e_aq_add_macvlan()
>
> I dont know if it is necessary/possible/important to set up the
> filters sooner in the sequence- the add_macvlan needs an "seid",
> and I could not tell when (in the ":" code above) the right seid
> can be found.
>
> Please review the RFC patch I'll be sending shortly.
>
> --Sowmini
Yeah, because of the underlying HW we need to manage, and the fact that we can't ask it for the filters it knows, it becomes a bit convoluted. To manage and replay the filter lists, we use the i40e_{add,del}_filter() routines on the individual VSI filter lists. I'm thinking you're on the right track, but we may not want to bypass the VSI's filter list.
My brain's not in gear this weekend so I'll review the patch later. In the meantime, be sure to test what happens over a reset, such as what happens when the MTU is changed. This will make sure that the replay of mac and vlan filters happens correctly. You'll want to test this with and without vlans.
sln