qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alex Williamson <alex.williamson@hp.com>
Cc: qemu-devel@nongnu.org, Andreas Plesner Jacobsen <apj@mutt.dk>
Subject: [Qemu-devel] Re: [PATCH RFC] net: add a flag to disable mac/vlan filtering
Date: Tue, 9 Mar 2010 18:18:25 +0200	[thread overview]
Message-ID: <20100309161825.GA32167@redhat.com> (raw)
In-Reply-To: <1268151093.14039.104.camel@8530w.home>

On Tue, Mar 09, 2010 at 09:11:33AM -0700, Alex Williamson wrote:
> On Tue, 2010-03-09 at 17:30 +0200, Michael S. Tsirkin wrote:
> > On Tue, Mar 09, 2010 at 08:19:12AM -0700, Alex Williamson wrote:
> > > On Tue, 2010-03-09 at 15:15 +0200, Michael S. Tsirkin wrote:
> > > > diff --git a/hw/virtio-net.c b/hw/virtio-net.c
> > > > index 5c0093e..01b45ed 100644
> > > > --- a/hw/virtio-net.c
> > > > +++ b/hw/virtio-net.c
> > > > @@ -47,6 +47,7 @@ typedef struct VirtIONet
> > > >      uint8_t nomulti;
> > > >      uint8_t nouni;
> > > >      uint8_t nobcast;
> > > > +    uint32_t filtering;
> > > >      struct {
> > > >          int in_use;
> > > >          int first_multi;
> > > > @@ -475,12 +476,17 @@ static int receive_filter(VirtIONet *n, const uint8_t *buf, int size)
> > > >          ptr += sizeof(struct virtio_net_hdr);
> > > >      }
> > > >  
> > > > -    if (!memcmp(&ptr[12], vlan, sizeof(vlan))) {
> > > > +    if ((n->filtering & (0x1 << NICCONF_F_VLAN_FILTERING)) &&
> > > > +        !memcmp(&ptr[12], vlan, sizeof(vlan))) {
> > > >          int vid = be16_to_cpup((uint16_t *)(ptr + 14)) & 0xfff;
> > > >          if (!(n->vlans[vid >> 5] & (1U << (vid & 0x1f))))
> > > >              return 0;
> > > >      }
> > > >  
> > > > +    if (!(n->filtering & (0x1 << NICCONF_F_MAC_FILTERING))) {
> > > > +            return 1;
> > > > +    }
> > > > +
> > > 
> > > A filtering flags bitmap is a logical choice here, but I found the
> > > overhead to be non-trivial, which is why we have separate variables for
> > > the other filtering options.
> > 
> > You suggest more flags for multicast etc?
> 
> I'm suggesting we may get slightly better performance if we use separate
> filter_mac and filter_vlan variable flags instead of a single
> "filtering" flags bitmap.

Why? It's a single operation anyway, and we use less cache.

>  However, a couple other ideas... Should we
> call receive_filter() as a function pointer so we can make filter
> specific versions or remove it completely?  Some overhead to calling it
> as a pointer, but could still be a win.  Alternatively we could make
> "effective" filter flags which are used by receive_filter(), but
> maintained separately from the guest requested flags.  For instance:
> 
> virtio_net_handle_rx_mode(...)
> {
> ...
> n->alluni_effective = (n->filtering & (0x1 << NICCONF_F_MAC_FILTERING)) ? n->alluni : 1;
> n->allmulti_effective = (n->filtering & (0x1 << NICCONF_F_MAC_FILTERING)) ? n->allmulti : 1;
> 
> These could be recreated on loadvm, so we still wouldn't need to save
> them.  Question would be whether that creates a sufficiently fast path
> through receive_filter().  We'd still need a new flag for vlan filtering
> or maybe make the vlan header match bytes settable.
> 
> Alex

I agree, merging flags set by guest and by host makes sense, this way we
don't need to test both. E.g. all filtering off is equivalent to promisc
mode, we test that already. More complex ideas would I guess need to be
benchmarked to be shown being worth it.  So I'll do the simple thing and
we can tweak it further later on.

-- 
MST

  reply	other threads:[~2010-03-09 16:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-09 13:15 [Qemu-devel] [PATCH RFC] net: add a flag to disable mac/vlan filtering Michael S. Tsirkin
2010-03-09 14:43 ` Anthony Liguori
2010-03-09 15:09   ` Alex Williamson
2010-03-09 15:54     ` Paul Brook
2010-03-09 15:10   ` Michael S. Tsirkin
2010-03-09 15:19 ` [Qemu-devel] " Alex Williamson
2010-03-09 15:30   ` Michael S. Tsirkin
2010-03-09 15:48     ` Michael S. Tsirkin
2010-03-09 16:11     ` Alex Williamson
2010-03-09 16:18       ` Michael S. Tsirkin [this message]
2010-03-09 16:56         ` Alex Williamson

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=20100309161825.GA32167@redhat.com \
    --to=mst@redhat.com \
    --cc=alex.williamson@hp.com \
    --cc=apj@mutt.dk \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).