Re: [RFC PATCH 0/2] make mac programming for virtio net more robust

Re: [RFC PATCH 0/2] make mac programming for virtio net more robust

[Michael S. Tsirkin]

On Fri, Jan 11, 2013 at 12:53:07PM +1030, Rusty Russell wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Thu, Jan 10, 2013 at 10:45:39PM +0800, akong@redhat.com wrote:
> >> From: Amos Kong <akong@redhat.com>
> >> 
> >> Currenly mac is programmed byte by byte. This means that we
> >> have an intermediate step where mac is wrong. 
> >> 
> >> Second patch introduced a new vq control command to set mac
> >> address in one time.
> >
> > As you mention we could alternatively do it without
> > new commands, simply add a feature bit that says that MACs are
> > in the mac table.
> > This would be a much bigger patch, and I'm fine with either way.
> > Rusty what do you think?
> 
> Hmm, mac filtering and "my mac address" are not quite the same thing.  I
> don't know if it matters for anyone: does it?
> The mac address is abused
> for things like identifying machines, etc.

I don't know either. I think net core differentiates between mac and
uc_list because linux has to know which mac to use when building
up packets, so at some level, I agree it might be useful to identify the
machine.

BTW netdev/davem should have been copied on this, Amos I think it's a
good idea to remember to do it next time you post.

> 
> If we keep it as a separate concept, Amos' patch seems to make sense.

Yes. It also keeps the patch small, I just thought I'd mention the
option.

> 
> Cheers,
> Rusty.

-- 
MST

Re: [RFC PATCH 0/2] make mac programming for virtio net more robust

[John Fastabend]

On 1/10/2013 11:46 PM, Michael S. Tsirkin wrote:
> On Fri, Jan 11, 2013 at 12:53:07PM +1030, Rusty Russell wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>>
>>> On Thu, Jan 10, 2013 at 10:45:39PM +0800, akong@redhat.com wrote:
>>>> From: Amos Kong <akong@redhat.com>
>>>>
>>>> Currenly mac is programmed byte by byte. This means that we
>>>> have an intermediate step where mac is wrong.
>>>>
>>>> Second patch introduced a new vq control command to set mac
>>>> address in one time.
>>>
>>> As you mention we could alternatively do it without
>>> new commands, simply add a feature bit that says that MACs are
>>> in the mac table.
>>> This would be a much bigger patch, and I'm fine with either way.
>>> Rusty what do you think?
>>
>> Hmm, mac filtering and "my mac address" are not quite the same thing.  I
>> don't know if it matters for anyone: does it?
>> The mac address is abused
>> for things like identifying machines, etc.
>
> I don't know either. I think net core differentiates between mac and
> uc_list because linux has to know which mac to use when building
> up packets, so at some level, I agree it might be useful to identify the
> machine.
>
> BTW netdev/davem should have been copied on this, Amos I think it's a
> good idea to remember to do it next time you post.
>
>>
>> If we keep it as a separate concept, Amos' patch seems to make sense.
>
> Yes. It also keeps the patch small, I just thought I'd mention the
> option.
>
>>
>> Cheers,
>> Rusty.
>

Don't have the entire context here but if you implement the
ndo_fdb_dump() probably hooking it up to ndo_dflt_fdb_dump() you could
use the 'bridge' tool dump the uc_list.

Then use ndo_fdb_add() and ndo_fdb_del() to add and remove entries
from the uc_list. We do this today in macvlan and the ixgbe driver when
it is in SR-IOV mode and the embedded switch needs to be programmed.

fdb is "forwarding database" its a bit different then mac filtering
in that its telling the "switch" how to forward mac addresses, in
ixgbe and macvlan at least we have been overloading it a bit to also
stop filtering the mac address. I think this makes sense if you setup
forwarding to a port it doesn't make much sense to then drop them.

Maybe its not entirely applicable here just thought I would mention it.

Thanks,
John