From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lu8jP-0005H3-HN for qemu-devel@nongnu.org; Wed, 15 Apr 2009 13:17:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lu8jL-0005E7-4D for qemu-devel@nongnu.org; Wed, 15 Apr 2009 13:17:03 -0400 Received: from [199.232.76.173] (port=34823 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lu8jK-0005Dl-KR for qemu-devel@nongnu.org; Wed, 15 Apr 2009 13:16:58 -0400 Received: from gecko.sbs.de ([194.138.37.40]:16784) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lu8jI-0006Ei-Ol for qemu-devel@nongnu.org; Wed, 15 Apr 2009 13:16:57 -0400 Message-ID: <49E61686.3090105@siemens.com> Date: Wed, 15 Apr 2009 19:16:54 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20090414172954.15035.73053.stgit@mchn012c.ww002.siemens.net> <20090414172955.15035.35614.stgit@mchn012c.ww002.siemens.net> <1239801006.4431.132.camel@blaa> <49E5EA9F.2090206@siemens.com> <1239815596.4431.157.camel@blaa> In-Reply-To: <1239815596.4431.157.camel@blaa> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 6/7] net: Add support for capturing VLANs Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark McLoughlin Cc: qemu-devel@nongnu.org Mark McLoughlin wrote: > On Wed, 2009-04-15 at 16:09 +0200, Jan Kiszka wrote: >>>> Besides rebasing and some minor cleanups, the major differences to the >>>> original version are: >>>> - support for enabling/disabling via the monitor (host_net_add/remove) >>>> - always register dump client at the head of a VLAN queue >>>> (instead of special handling for slirp) >>> Could you explain why you need this? >>> >>> I'd prefer if we didn't have to add qemu_new_vlan_head_client() >> Packet ordering: If you are sniffing from behind a vlan client in the >> queue, you may see its immediate reply to a certain packet before the >> triggering packet. Tristan solved this by pushing slirp (the only source >> for reordering so far) at the end of the queue, but I think it's rather >> the sniffer which has special requirements, so I pushed that one to the top. > > Uggh, nasty ... slirp strikes again :-) > > If we need to make the sniffer a special case, I'd suggest really making > it a special case by doing e.g. > > static void dump_packet(Dumper *d, const uint8_t *buf, int size) > { > /* write packet to pcap file */ > } > > void qemu_send_packet(...) > { > if (vlan->dumper) > dump_packet(d, buf, size); > > /* dispatch packets to vlan clients */ > } > > I think making it explicit is better than munging the vlan abstraction > any further. > > Alternatively, we could fix slirp to push packets to a queue and flush > that queue in a bottom half. That's actually a good idea - in case something else once comes around that gets confused by packet ordering. I'll check if we can do this more or less transparently in the network layer (queue tx requests while delivering). Shouldn't be hard (at least not as hard as changing slirp ;) ). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux