[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [POLL] slirp statistics - enable or drop them?

From: Jan Kiszka
Subject: Re: [Qemu-devel] [POLL] slirp statistics - enable or drop them?
Date: Mon, 22 Jun 2009 16:50:06 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

Alexander Graf wrote:
> On 22.06.2009, at 15:00, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>> On 06/22/2009 03:28 PM, Jan Kiszka wrote:
>>>> I just broke (locally) the slirp statistics. You know: "info slirp".
>>>> Maybe you don't because they are off by default, and there is even no
>>>> hidden configure switch to enable them ("#define LOG_ENABLED" or
>>>> "-DLOG_ENABLED" is required). Before fixing them again, I wonder if
>>>> there are actually use cases out there.
>>>> Basically I have three options now:
>>>>  - drop them completely (would make my nice, 1600-lines dropping slirp
>>>>    cleanup patch even nicer...)
>>>>  - fix them and leave them disabled, maybe adding some
>>>>    --enable-slirpstats to configure
>>>>  - fix them, but turn them on by default again so that Joe User is able
>>>>    to, well, actually look at them
>>>> Feedback appreciated.
>>> I don't see the need for slirp stats.  A production deployment is not
>>> going to use slirp, and a developer deployment won't need slirp stats.
>> OK, drop++.
>> BTW, there is one definitely useful part of "info slirp": the connection
>> listing at its end. It's basically what Alexander Graf recently
>> contributed, but more complete. I already factored this part out and
>> will submit an advanced version, likely under "info usernet" - who knows
>> what "slirp" means...
> The cleanup wouldn't drop the connection listing, would it? :-)
> That's about the only thing I care about when it comes to any info
> regarding slirp.

(qemu) info usernet
Protocol[State]    FD   Source Address  Port    Dest. Address  Port RecvQ SendQ
tcp[ESTABLISHED]   20 12345    22     0     0
tcp[HOST_FORWARD]  17                * 12345    22     0     0
udp[HOST_FORWARD]  19 10000 10000     0     0
udp[230 sec]       18  5353  5353     0     0

Is that OK? :)


Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

reply via email to

[Prev in Thread] Current Thread [Next in Thread]