[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/2] [SLIRP] Delayed IP packets
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PATCH 2/2] [SLIRP] Delayed IP packets |
Date: |
Wed, 27 Jul 2011 11:30:35 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2011-07-26 18:21, Fabien Chouteau wrote:
> In the current implementation, if Slirp tries to send an IP packet to a client
> with an unknown hardware address, the packet is simply dropped and an ARP
> request is sent (if_encap in slirp/slirp.c).
>
> This patch adds a list of delayed IP packets to handle such cases. If the
> hardware address is unknown, Slirp inserts the packet in delayed list and
> sends
> an ARP request. Each time the ARP table is updated Slirp retries to send the
> packet.
Haven't looked at details yet, just two general thoughts so far:
We already have queues for outgoing packets, why can't we reuse that
infrastructure? That would also avoid additional memory allocations.
Delayed packets should be requeued at the end and only one attempt to
send them should be performed per queue flush.
I think we need some timeout for the delayed packets. If invalid or
non-reactive clients are addressed, we will otherwise pile them up until
qemu terminates, right?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux