qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info


From: Zhi Yong Wu
Subject: Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
Date: Thu, 24 May 2012 22:12:40 +0800

On Thu, May 24, 2012 at 9:30 PM, Jan Kiszka <address@hidden> wrote:
> On 2012-05-24 09:27, Zhi Yong Wu wrote:
>> On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka <address@hidden> wrote:
>>> On 2012-05-23 23:42, Zhi Yong Wu wrote:
>>>> On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka <address@hidden> wrote:
>>>>> On 2012-05-23 12:14, address@hidden wrote:
>>>>>> From: Zhi Yong Wu <address@hidden>
>>>>>>
>>>>>> Signed-off-by: Zhi Yong Wu <address@hidden>
>>>>>> ---
>>>>>>  net.c |    1 -
>>>>>>  1 files changed, 0 insertions(+), 1 deletions(-)
>>>>>>
>>>>>> diff --git a/net.c b/net.c
>>>>>> index 61dc28d..8c8e703 100644
>>>>>> --- a/net.c
>>>>>> +++ b/net.c
>>>>>> @@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
>>>>>>      NetClientState *nc, *peer;
>>>>>>      net_client_type type;
>>>>>>
>>>>>> -    monitor_printf(mon, "Devices not on any VLAN:\n");
>>>>>>      QTAILQ_FOREACH(nc, &net_clients, next) {
>>>>>>          peer = nc->peer;
>>>>>>          type = nc->info->type;
>>>>>
>>>>> This looks suspicious - or the patch description is improvable. This is
>>>>> really just about removing that headline? And what about the indention
>>>>> of the lines printed afterward?
>>>> As you have known, vlan concept is replaced with hub. So i think that
>>>> it is more reasonable to remove this in monitor.
>>>
>>> That is true. But the output formatting is still improvable.
>> Please see below.
>>>
>>>>>
>>>>> It also leads me to the question how hub-based networks will be
>>>>> visualized on "info network", specifically when there are multiple hubs.
>>>>> Can you provide some more complex example of an info network output?
>>>>
>>>> (qemu) info network
>>>>   virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
>>>>    \ hub0port0: type=(null),
>>>>   virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
>>>>    \ hub1port0: type=(null),
>>>> hub 1
>>>>     port 1 peer user.1
>>>>     port 0 peer virtio-net-pci.1
>>>> hub 0
>>>>     port 1 peer user.0
>>>>     port 0 peer virtio-net-pci.0
>>>
>>> What about a layout like this:
>>>
>>> hub.0
>>>  \ virtio-net-pci.0: ...
>>>  \ virtio-net-pci.1: ...
>>>  \ user.0: ...
>>> hub.1
>>>  \ e1000.0: ...
>>> e1000.1: ...
>>>  \ user.1: ...
>> It is completely wrong.
>
> (Note: my example is not a different representation of yours, it's a
> different setup).
Sorry, i don't understand what the benefit for your layout is? And we
can not see which hub port peers with which NIC driver or network
backend.

>
>> In one hub, one NIC emulated driver such as
>> virtio-net peers with one hub port; while its network backend such as
>> user peers with another hub port in the same hub. This is hub work
>> logic. Of course, you can add one dump network backend to this hub via
>> one hub port.
>
> The output should reflect the logical connection in an easily
Do you think that my output can not reflect this hub logical
connection? To be honest, i think it can than yours. :)
> understandable way, not just the internal relations of netdev peers. If
> the data structures do not allow direct dumping in the proper form, it
> simply takes a bit more effort to do this.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux



-- 
Regards,

Zhi Yong Wu



reply via email to

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