Hi Michael,
On 1/26/2016 2:02 PM, Qiu, Michael wrote:
> On 1/11/2016 2:43 AM, Tan, Jianfeng wrote:
...
>>
>> f. Used with vhost-net
>> $: modprobe vhost
>> $: modprobe vhost-net
>> $: docker run -i -t --privileged \
>> -v /dev/vhost-net:/dev/vhost-net \
>> -v /dev/net/tun:/dev/net/tun \
On 1/11/2016 2:43 AM, Tan, Jianfeng wrote:
> This patchset is to provide high performance networking interface (virtio)
> for container-based DPDK applications. The way of starting DPDK apps in
> containers with ownership of NIC devices exclusively is beyond the scope.
> The basic idea here is to
Hi Amit,
On 1/20/2016 11:19 PM, Amit Tomer wrote:
> Hello,
>
>> For this case, please use --single-file option because it creates much more
>> than 8 fds, which can be handled by vhost-user sendmsg().
> Thanks, I'm able to verify it by sending ARP packet from container to
> host on arm64. But
Hello,
> For this case, please use --single-file option because it creates much more
> than 8 fds, which can be handled by vhost-user sendmsg().
Thanks, I'm able to verify it by sending ARP packet from container to
host on arm64. But sometimes, I do see following message while running
l2fwd in
On 1/12/2016 1:37 PM, Tetsuya Mukawa wrote:
> Hi Jianfeng and Xie,
>
> I guess my implementation and yours have a lot of common code, so I will
> try to rebase my patch on yours.
>
> BTW, one thing I need to change your memory allocation way is that
> mmaped address should be under 44bit(32 +
Hi Amit,
On 1/14/2016 8:03 PM, Amit Tomer wrote:
> Hello,
>
>> Not necessary. But if you want to use hugepages inside Docker, use -v option
>> to map a hugetlbfs into containers.
> I modified Docker command line in order to make use of Hugetlbfs:
>
> CMD
Hi Amit,
On 1/14/2016 5:34 PM, Amit Tomer wrote:
> Hello,
>
>> Can you send out how you start this l2fwd program?
> This is how, I run l2fwd program.
>
> CMD ["/usr/src/dpdk/examples/l2fwd/build/l2fwd", "-c", "0x3", "-n",
> "4","--no-pci",
>
Hello,
>
> Not necessary. But if you want to use hugepages inside Docker, use -v option
> to map a hugetlbfs into containers.
I modified Docker command line in order to make use of Hugetlbfs:
CMD ["/usr/src/dpdk/examples/l2fwd/build/l2fwd", "-c", "0x3", "-n",
"4","--no-pci",
Hello,
> Can you send out how you start this l2fwd program?
This is how, I run l2fwd program.
CMD ["/usr/src/dpdk/examples/l2fwd/build/l2fwd", "-c", "0x3", "-n",
"4","--no-pci",
,"--no-huge","--vdev=eth_cvio0,queue_num=256,rx=1,tx=1,cq=0,path=/usr/src/dpdk/usvhost",
"--", "-p", "0x1"]
I tried
Hi Amit,
On 1/13/2016 11:00 PM, Amit Tomer wrote:
> Hello,
>
>> You can use below patch for l2fwd to send out an arp packet when it gets
>> started.
> I tried to send out arp packet using this patch but buffer allocation
> for arp packets itself gets failed:
>
> m = rte_pktmbuf_alloc(mp);
>
>
Hello,
>
> You can use below patch for l2fwd to send out an arp packet when it gets
> started.
I tried to send out arp packet using this patch but buffer allocation
for arp packets itself gets failed:
m = rte_pktmbuf_alloc(mp);
Return a NULL Value.
Thanks,
Amit.
Hello,
On 1/12/2016 11:11 PM, Amit Tomer wrote:
> Hello,
>
>> In vhost-switch, it judges if a virtio device is ready for processing after
>> receiving
>> a pkt from virtio device. So you'd better construct a pkt, and send it out
>> firstly
>> in l2fwd.
> I tried to ping the socket interface from
Hello!
On 1/12/2016 10:45 PM, Amit Tomer wrote:
> Hello,
>
> I run l2fwd from inside docker with following logs:
>
> But, don't see Port statistics gets updated ?
>
In vhost-switch, it judges if a virtio device is ready for processing
after receiving
a pkt from virtio device. So you'd better
Hello,
> In vhost-switch, it judges if a virtio device is ready for processing after
> receiving
> a pkt from virtio device. So you'd better construct a pkt, and send it out
> firstly
> in l2fwd.
I tried to ping the socket interface from host for the same purpose
but it didn't work.
Could you
Hello,
> Have you applied all three fixes discussed here?
I am running it with, only RFC patches applied with "--no-huge" in l2fwd.
Thanks
Amit.
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:
Hello!
> Could anyone please point out, how it can be tested further(how can
> traffic be sent across host and container) ?
Have you applied all three fixes discussed here?
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
Hi Fedin,
On 1/12/2016 4:39 PM, Pavel Fedin wrote:
> Hello!
>
>> See my reply to "mem: add API to obstain memory-backed file info" for a
>> workaround. With fixes for that and the TUNSETVNETHDRSZ issue I was able to
>> get traffic running over vhost-user.
> With ovs or test apps? I still
On 2016/01/12 15:14, Yuanhan Liu wrote:
> On Tue, Jan 12, 2016 at 03:01:01PM +0900, Tetsuya Mukawa wrote:
>> On 2016/01/12 14:46, Tan, Jianfeng wrote:
>>> Hi Tetsuya,
>>>
>>>
Hi Jianfeng and Xie,
I guess my implementation and yours have a lot of common code, so I will
try to
On 2016/01/12 14:46, Tan, Jianfeng wrote:
>
> Hi Tetsuya,
>
>
>> Hi Jianfeng and Xie,
>>
>> I guess my implementation and yours have a lot of common code, so I will
>> try to rebase my patch on yours.
>
> We also think so. And before you rebase your code, I think we can rely
> on Yuanhan's
>
On 2016/01/10 20:42, Jianfeng Tan wrote:
> This patchset is to provide high performance networking interface (virtio)
> for container-based DPDK applications. The way of starting DPDK apps in
> containers with ownership of NIC devices exclusively is beyond the scope.
> The basic idea here is to
On Tue, Jan 12, 2016 at 03:26:47PM +0900, Tetsuya Mukawa wrote:
> On 2016/01/12 15:14, Yuanhan Liu wrote:
> > On Tue, Jan 12, 2016 at 03:01:01PM +0900, Tetsuya Mukawa wrote:
> >> On 2016/01/12 14:46, Tan, Jianfeng wrote:
> >>> Hi Tetsuya,
> >>>
> >>>
> Hi Jianfeng and Xie,
>
> I
On Tue, Jan 12, 2016 at 03:01:01PM +0900, Tetsuya Mukawa wrote:
> On 2016/01/12 14:46, Tan, Jianfeng wrote:
> >
> > Hi Tetsuya,
> >
> >
> >> Hi Jianfeng and Xie,
> >>
> >> I guess my implementation and yours have a lot of common code, so I will
> >> try to rebase my patch on yours.
> >
> > We
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
Hi Tetsuya,
> Hi Jianfeng and Xie,
>
> I guess my implementation and yours have a lot of common code, so I will
> try to rebase my patch on yours.
We also think so. And before you rebase your code, I think we can rely
on Yuanhan's
struct virtio_pci_ops to make the code structure brief and
Hello!
> See my reply to "mem: add API to obstain memory-backed file info" for a
> workaround. With fixes for that and the TUNSETVNETHDRSZ issue I was able to
> get traffic running over vhost-user.
With ovs or test apps? I still have problems with ovs after this. Packets go
from host to
Hello!
> > b) With --single-file - ovs runs, but doesn't get any packets at all. When
> > i try to ping
> the container from within host side, it
> > counts drops on vhost-user port.
> Can you check the OVS in host side, if it prints out message of "virtio
> is now ready for processing"?
No,
See my reply to "mem: add API to obstain memory-backed file info" for a
workaround. With fixes for that and the TUNSETVNETHDRSZ issue I was able to
get traffic running over vhost-user.
Hi Fedin,
> With the aforementioned fixes i tried to run it inside libvirt-lxc. I got
> the following:
> a) With hugepages - "abort with 256 hugepage files exceed the maximum of 8
> for vhost-user" - i set -m 512
This is currently a known issue, we have discussed in another thread
with
Hello!
> This patchset is to provide high performance networking interface (virtio)
> for container-based DPDK applications. The way of starting DPDK apps in
> containers with ownership of NIC devices exclusively is beyond the scope.
> The basic idea here is to present a new virtual device
This patchset is to provide high performance networking interface (virtio)
for container-based DPDK applications. The way of starting DPDK apps in
containers with ownership of NIC devices exclusively is beyond the scope.
The basic idea here is to present a new virtual device (named eth_cvio),
31 matches
Mail list logo
