Re: [PATCH 0/4] virtio support for container

From: Amit Tomer <amittomer25@gmail.com>
To: Pavel Fedin <p.fedin@samsung.com>
Cc: nakajima.yoshihiro@lab.ntt.co.jp,
	"Michael S. Tsirkin" <mst@redhat.com>,
	dev@dpdk.org, ann.zhuangyanying@huawei.com
Subject: Re: [PATCH 0/4] virtio support for container
Date: Tue, 12 Jan 2016 20:15:13 +0530	[thread overview]
Message-ID: <CABHD4K8CTYu6C3oXLaxLupUO17e3-d1gSTSzOxOPBZ9k3-i4Ww@mail.gmail.com> (raw)
In-Reply-To: <00d901d14d26$d04fc600$70ef5200$@samsung.com>

Hello,

I run l2fwd from inside docker with following logs:

But, don't see Port statistics gets updated ?

#/home/ubuntu/dpdk# sudo docker run -i -t -v
/home/ubuntu/dpdk/usvhost:/usr/src/dpdk/usvhost l4
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 6 on socket 0
EAL: Detected lcore 7 as core 7 on socket 0
EAL: Detected lcore 8 as core 8 on socket 0
EAL: Setting up physically contiguous memory...
EAL: TSC frequency is ~99999 KHz
EAL: Master lcore 1 is ready (tid=b5968000;cpuset=[1])
Notice: odd number of ports in portmask.
Lcore 1: RX port 0
Initializing port 0... done:
Port 0, MAC address: F6:9F:7A:47:A4:99

Checking link statusdone
Port 0 Link Up - speed 10000 Mbps - full-duplex
L2FWD: entering main loop on lcore 1
L2FWD:  -- lcoreid=1 portid=0

Port statistics ====================================
Statistics for port 0 ------------------------------
Packets sent:                        0
Packets received:                    0
Packets dropped:                     0
Aggregate statistics ===============================
Total packets sent:                  0
Total packets received:              0
Total packets dropped:               0
====================================================

Host side logs after running

# ./vhost-switch -c 0x3 f -n 4 --socket-mem 2048 --huge-dir
/dev/hugepages -- -p 0x1  --dev-basename usvhost

PMD: eth_ixgbe_dev_init(): MAC: 4, PHY: 3
PMD: eth_ixgbe_dev_init(): port 1 vendorID=0x8086 deviceID=0x1528
pf queue num: 0, configured vmdq pool num: 64, each vmdq pool has 2 queues
VHOST_PORT: Max virtio devices supported: 64
VHOST_PORT: Port 0 MAC: d8 9d 67 ee 55 f0
VHOST_PORT: Skipping disabled port 1
VHOST_DATA: Procesing on Core 1 started
VHOST_CONFIG: socket created, fd:20
VHOST_CONFIG: bind to usvhost
VHOST_CONFIG: new virtio connection is 21
VHOST_CONFIG: new device, handle is 0
VHOST_CONFIG: read message VHOST_USER_GET_FEATURES
VHOST_CONFIG: read message VHOST_USER_SET_FEATURES
VHOST_CONFIG: read message VHOST_USER_SET_MEM_TABLE
VHOST_CONFIG: mapped region 0 fd:22 to 0x7f34000000 sz:0x4000000 off:0x0
VHOST_CONFIG: read message VHOST_USER_SET_VRING_CALL
VHOST_CONFIG: vring call idx:0 file:23
VHOST_CONFIG: read message VHOST_USER_SET_VRING_NUM
VHOST_CONFIG: read message VHOST_USER_SET_VRING_BASE
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ADDR
VHOST_CONFIG: read message VHOST_USER_SET_VRING_KICK
VHOST_CONFIG: vring kick idx:0 file:24
VHOST_CONFIG: virtio isn't ready for processing.
VHOST_CONFIG: read message VHOST_USER_SET_VRING_CALL
VHOST_CONFIG: vring call idx:1 file:25
VHOST_CONFIG: read message VHOST_USER_SET_VRING_NUM
VHOST_CONFIG: read message VHOST_USER_SET_VRING_BASE
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ADDR
VHOST_CONFIG: read message VHOST_USER_SET_VRING_KICK
VHOST_CONFIG: vring kick idx:1 file:26
VHOST_CONFIG: virtio is now ready for processing.
VHOST_DATA: (0) Device has been added to data core 1

Could anyone please point out, how it can be tested further(how can
traffic be sent across host and container)  ?

Thanks,
Amit.

On Tue, Jan 12, 2016 at 4:18 PM, Pavel Fedin <p.fedin@samsung.com> wrote:
>  Hello!
>
>> Your guess makes sense because current implementation does not support
>> multi-queues.
>>
>>  From you log, only 0 and 1 are "ready for processing"; others are "not
>> ready for processing".
>
>  Yes, and if study it even more carefully, we see that we initialize all tx queues but only a single rx queue (#0).
>  After some more code browsing and comparing the two patchsets i figured out that the problem is caused by inappropriate VIRTIO_NET_F_CTRL_VQ flag. In your RFC you used different capability set, while in v1 you seem to have forgotten about this.
>  I suggest to temporarily move hw->guest_features assignment out of virtio_negotiate_features() into the caller, where we have eth_dev->dev_type, and can choose the right set depending on it.
>
>  With all mentioned fixes i've got the ping running.
>  Tested-by: Pavel Fedin <p.fedin@samsung.com>
>
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
>
>