[PATCH 0/2][RFC] virtio_net: MAC filtering

[PATCH 0/2][RFC] virtio_net: MAC filtering

[Alex Williamson]

This series builds on some of the patches Mark McLoughlin has sent out
recently, so likely won't apply to any current trees until those get
upstream.  The goal is to enable MAC filtering at the kvm/qemu level for
virtio-net packets.  Promiscuous and allmulti mode are handled by adding
bits to Mark's proposed status field.  I also add a 16 entry MAC table
for additional unicast and multicast addresses to filter.  If this looks
reasonable, I'll follow-up with VLAN filtering.

As noted in the RFC thread adding the kvm/qemu backing, this does
increase the size of the virtio-net device I/O port space, up to 1kB
with PCI rounding if we add a 4k entry VLAN bitmap.  A 64 device limit
is still pretty high for a VM, but maybe we should think about adding
MMIO space for virtio-pci.  Thanks,

Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: [PATCH 0/2][RFC] virtio_net: MAC filtering

[Anthony Liguori]

Alex Williamson wrote:
> This series builds on some of the patches Mark McLoughlin has sent out
> recently, so likely won't apply to any current trees until those get
> upstream.  The goal is to enable MAC filtering at the kvm/qemu level for
> virtio-net packets.  Promiscuous and allmulti mode are handled by adding
> bits to Mark's proposed status field.  I also add a 16 entry MAC table
> for additional unicast and multicast addresses to filter.  If this looks
> reasonable, I'll follow-up with VLAN filtering.
>
> As noted in the RFC thread adding the kvm/qemu backing, this does
> increase the size of the virtio-net device I/O port space, up to 1kB
> with PCI rounding if we add a 4k entry VLAN bitmap.  A 64 device limit
> is still pretty high for a VM, but maybe we should think about adding
> MMIO space for virtio-pci.  Thanks,
>   

I'm not quite sure the best way to address this.  Maybe another control 
queue for sending commands to control this sort of stuff?  What are your 
thoughts Rusty?

Regards,

Anthony Liguori

> Alex
>
>   

Re: [PATCH 0/2][RFC] virtio_net: MAC filtering

[Alex Williamson]

On Wed, 2009-01-07 at 12:14 -0600, Anthony Liguori wrote:
> Alex Williamson wrote:
> >
> > As noted in the RFC thread adding the kvm/qemu backing, this does
> > increase the size of the virtio-net device I/O port space, up to 1kB
> > with PCI rounding if we add a 4k entry VLAN bitmap.  A 64 device limit
> > is still pretty high for a VM, but maybe we should think about adding
> > MMIO space for virtio-pci.  Thanks,
> >   
> 
> I'm not quite sure the best way to address this.  Maybe another control 
> queue for sending commands to control this sort of stuff?  What are your 
> thoughts Rusty?

This is also a good time to decide if a fixed 16 entry MAC filter table
is sufficient.  Should the size be programmed into the config space?
There's plenty of room to make it a bigger fixed size and still stay at
1kB of I/O port space with the VLAN table.  This implementation is a
little wasteful of space in using 8 bytes to store the MAC and a valid
bit, but I suspect there's some endian issues I'm ignoring and a
standard data type might make that easier later.

Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: [PATCH 0/2][RFC] virtio_net: MAC filtering

[Anthony Liguori]

Alex Williamson wrote:
> On Wed, 2009-01-07 at 12:14 -0600, Anthony Liguori wrote:
>   
>> Alex Williamson wrote:
>>     
>>> As noted in the RFC thread adding the kvm/qemu backing, this does
>>> increase the size of the virtio-net device I/O port space, up to 1kB
>>> with PCI rounding if we add a 4k entry VLAN bitmap.  A 64 device limit
>>> is still pretty high for a VM, but maybe we should think about adding
>>> MMIO space for virtio-pci.  Thanks,
>>>   
>>>       
>> I'm not quite sure the best way to address this.  Maybe another control 
>> queue for sending commands to control this sort of stuff?  What are your 
>> thoughts Rusty?
>>     
>
> This is also a good time to decide if a fixed 16 entry MAC filter table
> is sufficient.  Should the size be programmed into the config space?
> There's plenty of room to make it a bigger fixed size and still stay at
> 1kB of I/O port space with the VLAN table.  This implementation is a
> little wasteful of space in using 8 bytes to store the MAC and a valid
> bit, but I suspect there's some endian issues I'm ignoring and a
> standard data type might make that easier later.
>   

If we switch to a command queue, then there's no need to have any fixed 
limitation.

Regards,

Anthony Liguori

> Alex
>
>   

Re: [PATCH 0/2][RFC] virtio_net: MAC filtering

[Avi Kivity]

Anthony Liguori wrote:
> Alex Williamson wrote:
>> This series builds on some of the patches Mark McLoughlin has sent out
>> recently, so likely won't apply to any current trees until those get
>> upstream.  The goal is to enable MAC filtering at the kvm/qemu level for
>> virtio-net packets.  Promiscuous and allmulti mode are handled by adding
>> bits to Mark's proposed status field.  I also add a 16 entry MAC table
>> for additional unicast and multicast addresses to filter.  If this looks
>> reasonable, I'll follow-up with VLAN filtering.
>>
>> As noted in the RFC thread adding the kvm/qemu backing, this does
>> increase the size of the virtio-net device I/O port space, up to 1kB
>> with PCI rounding if we add a 4k entry VLAN bitmap.  A 64 device limit
>> is still pretty high for a VM, but maybe we should think about adding
>> MMIO space for virtio-pci.  Thanks,
>>   
>
> I'm not quite sure the best way to address this.  Maybe another 
> control queue for sending commands to control this sort of stuff?  
> What are your thoughts Rusty?

Reducing the amount of shared state will make maintaining compatibility 
easier.  A command queue introduces asynchronity and its associated 
problems, but I think it's worthwhile.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

[PATCH 0/4] virtio_net: MAC filtering

[Alex Williamson]

Here's an update to the patches I sent last week.  The goal of this
series is to add RX mode bits, MAC table filtering, and I'll follow up
with VLAN filtering, so that the virtio_net device doesn't always run in
promiscuous mode.

This version now uses a virtqueue for outbound commands for setting mode
bits and table entries.  The size of the MAC filter table can be
configured by the guest at initialization.  I'm no longer bloating the
I/O port space of the virtnet device, in fact, I couldn't find any
reason to store the RX mode bits in the status register, so I also moved
those into the virtqueue channel so we have less shared data.  Please
comment.  Thanks,

Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.