All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jim C. Brown" <jma5@umd.edu>
To: Mulyadi Santosa <a_mulyadi@softhome.net>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] vde-inject 0.0.1
Date: Fri, 10 Feb 2006 12:09:32 -0500	[thread overview]
Message-ID: <20060210170932.GA22586@jbrown.mylinuxbox.org> (raw)
In-Reply-To: <200602101234.10853.a_mulyadi@softhome.net>

On Fri, Feb 10, 2006 at 12:34:10PM +0700, Mulyadi Santosa wrote:
> Hi Jim
> 
> It's me again. here I send you another patch for the vde_pcap_inject.c. 
> Nothing fancy here, I only did:

> -  move out "open" and "close" from relay() and put them on main() 
> before entering for() loop. IMHO, this will make file operation a bit 
> faster

This one I've thought about myself.

Your way makes vde_pcap_inject more efficient. My way makes it usable if
vde_pcap_inject is run before the kernel module is loaded.

The idea is that vde_pcap_inject can be used everywhere vde_pcap can be, but
in addition if you have vde-inject then it can and will make use of that as
well.

> 
> - I use __builtin_expect magic to optimize the "if" condition before 
> writing to /proc/vdeinject. here, inside relay() we assume that 
> vdeinject is likely exist.
> 

What is __buiultin_expect() ? I've never seen it before.

Your tests to make sure the fd is valid are unnecessary. perror() causes
vde_pcap_inject to abort with an error, so any code called later on is
guarranteed that fd is valid.

Of course this means that vde_pcap_inject can only be used in combo with
vde-inject, which I'm not sure is a good thing. E.g. a freeBSD host lacks
vde-inject, so this would make vde_pcap_inject linux-specific.

> PS: I can't check it thoroughly since my libpcap version (0.7.2, default 
> on Redhat 9. Yes I know it is old) doesn't have 
> pcap_get_selectable_fd(), so I can't compile it.
> 

Change it to pcap_fileno(), and it should compile and work identically.
(The difference is that pcap_get_selectable_fd() adds some basic sanity checks
to make sure the fd is selectable before returning it. See
http://www.tcpdump.org/lists/workers/2004/06/msg00093.html for more information.)

I'll probably add an #ifdef for this.

> regards
> 
> Mulyadi

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

      reply	other threads:[~2006-02-10 17:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-08 23:13 [Qemu-devel] vde-inject 0.0.0 Jim C. Brown
2006-02-09  5:39 ` [Qemu-devel] vde-inject 0.0.1 Jim C. Brown
2006-02-09 18:23   ` Mulyadi Santosa
2006-02-10  5:34   ` Mulyadi Santosa
2006-02-10 17:09     ` Jim C. Brown [this message]

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=20060210170932.GA22586@jbrown.mylinuxbox.org \
    --to=jma5@umd.edu \
    --cc=a_mulyadi@softhome.net \
    --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 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.