[PATCH 0/5][RFC] virtio-net: MAC filtering

[PATCH 0/5][RFC] virtio-net: MAC filtering

[Alex Williamson]

This series is based on some of the work Mark McLoughlin has been doing,
so isn't going to apply until that makes it into the tree.  The goal is
to enable MAC filtering at the qemu/kvm level for virtio-net packets.  I
start by adding the capability to set the MAC address, naming the bits
in the status field, enabling filtering, and finally adding a MAC table
for additional MAC addresses.  If this looks reasonable, I'll follow up
with VLAN filtering support.

A concern here is the growing size of the virtio-net I/O port space
config.  This series brings it up to 256 bytes with PCI resource
rounding.  The VLAN filter bitmap would increase that by another 512
bytes, making it 1kB and limiting us to something less than 64 such
devices per guest.  Is anyone worried?  Should filter tables live in
MMIO space for virtio devices?  I'll send out the guest side patches for
virtio-net in a separate thread.  Thanks,

Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

[Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering

[Alex Williamson]

This series is based on some of the work Mark McLoughlin has been doing,
so isn't going to apply until that makes it into the tree.  The goal is
to enable MAC filtering at the qemu/kvm level for virtio-net packets.  I
start by adding the capability to set the MAC address, naming the bits
in the status field, enabling filtering, and finally adding a MAC table
for additional MAC addresses.  If this looks reasonable, I'll follow up
with VLAN filtering support.

A concern here is the growing size of the virtio-net I/O port space
config.  This series brings it up to 256 bytes with PCI resource
rounding.  The VLAN filter bitmap would increase that by another 512
bytes, making it 1kB and limiting us to something less than 64 such
devices per guest.  Is anyone worried?  Should filter tables live in
MMIO space for virtio devices?  I'll send out the guest side patches for
virtio-net in a separate thread.  Thanks,

Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: [Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering

[Paul Brook]

> A concern here is the growing size of the virtio-net I/O port space
> config.  This series brings it up to 256 bytes with PCI resource
> rounding.  The VLAN filter bitmap would increase that by another 512
> bytes, making it 1kB and limiting us to something less than 64 such
> devices per guest.  Is anyone worried?  Should filter tables live in
> MMIO space for virtio devices?  I'll send out the guest side patches for
> virtio-net in a separate thread.  Thanks,

This is one reason why IO ports are a reallybad idea. Use memory mapped 
register spaces like any other sane system and you won't have a problem.

Paul

Re: [Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering

[Paul Brook]

> A concern here is the growing size of the virtio-net I/O port space
> config.  This series brings it up to 256 bytes with PCI resource
> rounding.  The VLAN filter bitmap would increase that by another 512
> bytes, making it 1kB and limiting us to something less than 64 such
> devices per guest.  Is anyone worried?  Should filter tables live in
> MMIO space for virtio devices?  I'll send out the guest side patches for
> virtio-net in a separate thread.  Thanks,

This is one reason why IO ports are a reallybad idea. Use memory mapped 
register spaces like any other sane system and you won't have a problem.

Paul

Re: [Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering

[Avi Kivity]

Paul Brook wrote:
>> A concern here is the growing size of the virtio-net I/O port space
>> config.  This series brings it up to 256 bytes with PCI resource
>> rounding.  The VLAN filter bitmap would increase that by another 512
>> bytes, making it 1kB and limiting us to something less than 64 such
>> devices per guest.  Is anyone worried?  Should filter tables live in
>> MMIO space for virtio devices?  I'll send out the guest side patches for
>> virtio-net in a separate thread.  Thanks,
>>     
>
> This is one reason why IO ports are a reallybad idea. Use memory mapped 
> register spaces like any other sane system and you won't have a problem.
>   

mmio is slower for virtualization.  But I agree pio is baroque.

Luckily we didn't implement the 768 pci slot thing, that wouldn't have 
flown (for yet another reason).

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

Re: [Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering

[Avi Kivity]

Paul Brook wrote:
>> A concern here is the growing size of the virtio-net I/O port space
>> config.  This series brings it up to 256 bytes with PCI resource
>> rounding.  The VLAN filter bitmap would increase that by another 512
>> bytes, making it 1kB and limiting us to something less than 64 such
>> devices per guest.  Is anyone worried?  Should filter tables live in
>> MMIO space for virtio devices?  I'll send out the guest side patches for
>> virtio-net in a separate thread.  Thanks,
>>     
>
> This is one reason why IO ports are a reallybad idea. Use memory mapped 
> register spaces like any other sane system and you won't have a problem.
>   

mmio is slower for virtualization.  But I agree pio is baroque.

Luckily we didn't implement the 768 pci slot thing, that wouldn't have 
flown (for yet another reason).

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

Re: [Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering

[Anthony Liguori]

Paul Brook wrote:
>> A concern here is the growing size of the virtio-net I/O port space
>> config.  This series brings it up to 256 bytes with PCI resource
>> rounding.  The VLAN filter bitmap would increase that by another 512
>> bytes, making it 1kB and limiting us to something less than 64 such
>> devices per guest.  Is anyone worried?  Should filter tables live in
>> MMIO space for virtio devices?  I'll send out the guest side patches for
>> virtio-net in a separate thread.  Thanks,
>>     
>
> This is one reason why IO ports are a reallybad idea. Use memory mapped 
> register spaces like any other sane system and you won't have a problem.
>   

IO ports are much faster for notification than MMIO in KVM which is why 
the space is currently IO ports.  It was never meant to hold very large 
amounts of data.

Regards,

Anthony Liguori

> Paul
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: [Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering

[Anthony Liguori]

Paul Brook wrote:
>> A concern here is the growing size of the virtio-net I/O port space
>> config.  This series brings it up to 256 bytes with PCI resource
>> rounding.  The VLAN filter bitmap would increase that by another 512
>> bytes, making it 1kB and limiting us to something less than 64 such
>> devices per guest.  Is anyone worried?  Should filter tables live in
>> MMIO space for virtio devices?  I'll send out the guest side patches for
>> virtio-net in a separate thread.  Thanks,
>>     
>
> This is one reason why IO ports are a reallybad idea. Use memory mapped 
> register spaces like any other sane system and you won't have a problem.
>   

IO ports are much faster for notification than MMIO in KVM which is why 
the space is currently IO ports.  It was never meant to hold very large 
amounts of data.

Regards,

Anthony Liguori

> Paul
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: [Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering

[Paul Brook]

> >> A concern here is the growing size of the virtio-net I/O port space
> >> config.  This series brings it up to 256 bytes with PCI resource
> >
> > This is one reason why IO ports are a reallybad idea. Use memory mapped
> > register spaces like any other sane system and you won't have a problem.
>
> IO ports are much faster for notification than MMIO in KVM which is why
> the space is currently IO ports.  It was never meant to hold very large
> amounts of data.

Huh, I'm surprised it makes any real difference. Other that initial setup, 
isn't it just used to "kick" the devieonce after new dscriptors have been 
added to the ring buffer? I'd expect to be a fairly expensive operation 
(bouncing back to userspace).

Paul

Re: [Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering

[Paul Brook]

> >> A concern here is the growing size of the virtio-net I/O port space
> >> config.  This series brings it up to 256 bytes with PCI resource
> >
> > This is one reason why IO ports are a reallybad idea. Use memory mapped
> > register spaces like any other sane system and you won't have a problem.
>
> IO ports are much faster for notification than MMIO in KVM which is why
> the space is currently IO ports.  It was never meant to hold very large
> amounts of data.

Huh, I'm surprised it makes any real difference. Other that initial setup, 
isn't it just used to "kick" the devieonce after new dscriptors have been 
added to the ring buffer? I'd expect to be a fairly expensive operation 
(bouncing back to userspace).

Paul

Re: [Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering

[Anthony Liguori]

Paul Brook wrote:
>>>> A concern here is the growing size of the virtio-net I/O port space
>>>> config.  This series brings it up to 256 bytes with PCI resource
>>>>         
>>> This is one reason why IO ports are a reallybad idea. Use memory mapped
>>> register spaces like any other sane system and you won't have a problem.
>>>       
>> IO ports are much faster for notification than MMIO in KVM which is why
>> the space is currently IO ports.  It was never meant to hold very large
>> amounts of data.
>>     
>
> Huh, I'm surprised it makes any real difference. Other that initial setup, 
> isn't it just used to "kick" the devieonce after new dscriptors have been 
> added to the ring buffer? I'd expect to be a fairly expensive operation 
> (bouncing back to userspace).
>   

It's about 2x as expensive to go to userspace but only probably 1.5x 
expensive to do MMIO compared to PIO.  In the grand scheme of things, 
I'm not sure that it matters that much.  It's relatively simple for 
someone to try out the change and do some benchmarking.

The tougher thing is providing backwards compatible support.

Regards,

Anthony Liguori

> Paul
>   

Re: [Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering

[Anthony Liguori]

Paul Brook wrote:
>>>> A concern here is the growing size of the virtio-net I/O port space
>>>> config.  This series brings it up to 256 bytes with PCI resource
>>>>         
>>> This is one reason why IO ports are a reallybad idea. Use memory mapped
>>> register spaces like any other sane system and you won't have a problem.
>>>       
>> IO ports are much faster for notification than MMIO in KVM which is why
>> the space is currently IO ports.  It was never meant to hold very large
>> amounts of data.
>>     
>
> Huh, I'm surprised it makes any real difference. Other that initial setup, 
> isn't it just used to "kick" the devieonce after new dscriptors have been 
> added to the ring buffer? I'd expect to be a fairly expensive operation 
> (bouncing back to userspace).
>   

It's about 2x as expensive to go to userspace but only probably 1.5x 
expensive to do MMIO compared to PIO.  In the grand scheme of things, 
I'm not sure that it matters that much.  It's relatively simple for 
someone to try out the change and do some benchmarking.

The tougher thing is providing backwards compatible support.

Regards,

Anthony Liguori

> Paul
>   

Re: [Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering

[Avi Kivity]

Anthony Liguori wrote:
> Paul Brook wrote:
>>> A concern here is the growing size of the virtio-net I/O port space
>>> config.  This series brings it up to 256 bytes with PCI resource
>>> rounding.  The VLAN filter bitmap would increase that by another 512
>>> bytes, making it 1kB and limiting us to something less than 64 such
>>> devices per guest.  Is anyone worried?  Should filter tables live in
>>> MMIO space for virtio devices?  I'll send out the guest side patches 
>>> for
>>> virtio-net in a separate thread.  Thanks,
>>>     
>>
>> This is one reason why IO ports are a reallybad idea. Use memory 
>> mapped register spaces like any other sane system and you won't have 
>> a problem.
>>   
>
> IO ports are much faster for notification than MMIO in KVM which is 
> why the space is currently IO ports.  It was never meant to hold very 
> large amounts of data.

We can, btw, fix the mmio speed issue by adding two new hypercalls: 
mmio_read() and mmio_write().  We could then hook <asm/io.h> to use the 
hypercalls instead of reading directly.  This would speed up most 
emulated devices, not just virtio.

I don't know whether Windows drivers access mmio using helpers or directly.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 0/5][RFC] virtio-net: MAC filtering

[Avi Kivity]

Anthony Liguori wrote:
> Paul Brook wrote:
>>> A concern here is the growing size of the virtio-net I/O port space
>>> config.  This series brings it up to 256 bytes with PCI resource
>>> rounding.  The VLAN filter bitmap would increase that by another 512
>>> bytes, making it 1kB and limiting us to something less than 64 such
>>> devices per guest.  Is anyone worried?  Should filter tables live in
>>> MMIO space for virtio devices?  I'll send out the guest side patches 
>>> for
>>> virtio-net in a separate thread.  Thanks,
>>>     
>>
>> This is one reason why IO ports are a reallybad idea. Use memory 
>> mapped register spaces like any other sane system and you won't have 
>> a problem.
>>   
>
> IO ports are much faster for notification than MMIO in KVM which is 
> why the space is currently IO ports.  It was never meant to hold very 
> large amounts of data.

We can, btw, fix the mmio speed issue by adding two new hypercalls: 
mmio_read() and mmio_write().  We could then hook <asm/io.h> to use the 
hypercalls instead of reading directly.  This would speed up most 
emulated devices, not just virtio.

I don't know whether Windows drivers access mmio using helpers or directly.

-- 
error compiling committee.c: too many arguments to function

[PATCH 0/5] 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 MAC setting and filtering support to the virtio-net
backend in qemu/kvm.

This version now makes use of a virtqueue for outbound commands from the
guest driver.  This allows us to support numerous features without
trying to pack them into the virtio-net I/O port config space.  A
separate patch series shows the guest driver changes to enable this.
Please comment.  Thanks,

Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

[Qemu-devel] [PATCH 0/5] 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 MAC setting and filtering support to the virtio-net
backend in qemu/kvm.

This version now makes use of a virtqueue for outbound commands from the
guest driver.  This allows us to support numerous features without
trying to pack them into the virtio-net I/O port config space.  A
separate patch series shows the guest driver changes to enable this.
Please comment.  Thanks,

Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: [PATCH 0/5] virtio-net: MAC filtering

[Anthony Liguori]

Alex Williamson wrote:
> Here's an update to the patches I sent last week.  The goal of this
> series is to add MAC setting and filtering support to the virtio-net
> backend in qemu/kvm.
>
> This version now makes use of a virtqueue for outbound commands from the
> guest driver.  This allows us to support numerous features without
> trying to pack them into the virtio-net I/O port config space.  A
> separate patch series shows the guest driver changes to enable this.
> Please comment.  Thanks,
>   

The backend bits look good to me.

Regards,

Anthony Liguori

> Alex
>
>   

[Qemu-devel] Re: [PATCH 0/5] virtio-net: MAC filtering

[Anthony Liguori]

Alex Williamson wrote:
> Here's an update to the patches I sent last week.  The goal of this
> series is to add MAC setting and filtering support to the virtio-net
> backend in qemu/kvm.
>
> This version now makes use of a virtqueue for outbound commands from the
> guest driver.  This allows us to support numerous features without
> trying to pack them into the virtio-net I/O port config space.  A
> separate patch series shows the guest driver changes to enable this.
> Please comment.  Thanks,
>   

The backend bits look good to me.

Regards,

Anthony Liguori

> Alex
>
>