All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@hp.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Rusty Russell <rusty@rustcorp.com.au>, kvm <kvm@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	Mark McLoughlin <markmc@redhat.com>
Subject: Re: [PATCH 2/2][RFC] virtio_net: Add MAC fitler table support
Date: Sat, 10 Jan 2009 11:50:31 -0700	[thread overview]
Message-ID: <1231613431.9095.20.camel@bling> (raw)
In-Reply-To: <4968E669.8040707@codemonkey.ws>

On Sat, 2009-01-10 at 12:18 -0600, Anthony Liguori wrote:
> Ideally, you'd have an area of guest memory sized by the guest (so there 
> was no intrinsic limit on table size) that was given to the host to use 
> as the filter tables.  The only way this works with virtio is if you 
> send this over a virtqueue in the form of messages.  You could write a 
> pfn to the config space but then you lose all the mapping/unmapping 
> abstraction that virtqueue gives you (even though we don't do anything 
> useful with that abstraction today :-)).

Hmm, that's not quite how I was implementing it.  The uc_list and
mc_list are stored up in the netdev level, so there's not much point in
duplicating it in the guest virtio-net driver.  The interface I was
working on has two commands.  The first tells the host to allocate the
MAC filter table for a guest provided number of entries (perhaps a
module parameter, with reasonable default).  The other is a set command
with an sg entry providing a buffer of all the MAC entries for the
table.  If sg entries are no more than a page, this limits us to ~680
MAC table entries, which I think is far more than any piece of real
hardware (and large enough that you'd probably want to turn on
promiscuous already).  The VLAN equivalent is a bit easier since by
definition there are 4k possible VLANs.  There I think a set bit/clear
bit message interface is appropriate (and maybe a clear all for a reset
condition).  Let me know if that sounds reasonable.  Thanks,

Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.


  reply	other threads:[~2009-01-10 18:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-07 18:06 [PATCH 2/2][RFC] virtio_net: Add MAC fitler table support Alex Williamson
2009-01-09 11:34 ` Mark McLoughlin
2009-01-09 15:34   ` Alex Williamson
2009-01-10 11:18 ` Rusty Russell
2009-01-10 15:10   ` Alex Williamson
2009-01-10 18:18   ` Anthony Liguori
2009-01-10 18:50     ` Alex Williamson [this message]
2009-01-10 19:41       ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1231613431.9095.20.camel@bling \
    --to=alex.williamson@hp.com \
    --cc=anthony@codemonkey.ws \
    --cc=kvm@vger.kernel.org \
    --cc=markmc@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.