search for: vnets

From f244bcad756c4f761627557bb7f315b1d8f22fb2 Mon Sep 17 00:00:00 2001 From: Dor Laor <dor.laor@qumranet.com> Date: Thu, 20 Dec 2007 13:26:30 +0200 Subject: [PATCH] [VIRTIO-NET] Rx performance improvement The current performance are not good enough, the problem lies in qemu tap handling code that caused to pass packets one at a time and also to copy them to a temporal buffer. This patch

From f244bcad756c4f761627557bb7f315b1d8f22fb2 Mon Sep 17 00:00:00 2001 From: Dor Laor <dor.laor@qumranet.com> Date: Thu, 20 Dec 2007 13:26:30 +0200 Subject: [PATCH] [VIRTIO-NET] Rx performance improvement The current performance are not good enough, the problem lies in qemu tap handling code that caused to pass packets one at a time and also to copy them to a temporal buffer. This patch

On 2020/5/6 ??4:21, Jesper Dangaard Brouer wrote: > On Wed, 6 May 2020 14:16:32 +0800 > Jason Wang <jasowang at redhat.com> wrote: > >> We tried to reserve space for vnet header before >> xdp.data_hard_start. But this is useless since the packet could be >> modified by XDP which may invalidate the information stored in the >> header and > IMHO above

On 2020/5/6 ??4:21, Jesper Dangaard Brouer wrote: > On Wed, 6 May 2020 14:16:32 +0800 > Jason Wang <jasowang at redhat.com> wrote: > >> We tried to reserve space for vnet header before >> xdp.data_hard_start. But this is useless since the packet could be >> modified by XDP which may invalidate the information stored in the >> header and > IMHO above

This patch fixes the tools/vnet makefiles so that vnets will compile and includes updates to the vnet implementation. Vnet ids are increased to 128 bits. The vnet module will insmod whether xen-br0 exists or not. Signed-off-by: Mike Wray <mike.wray@hp.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xe...

Can i assign static vnet* device for some guests?

On 2020/5/6 ??3:53, Michael S. Tsirkin wrote: > On Wed, May 06, 2020 at 02:16:32PM +0800, Jason Wang wrote: >> We tried to reserve space for vnet header before >> xdp.data_hard_start. But this is useless since the packet could be >> modified by XDP which may invalidate the information stored in the >> header and there's no way for XDP to know the existence of the

On 2020/5/6 ??3:53, Michael S. Tsirkin wrote: > On Wed, May 06, 2020 at 02:16:32PM +0800, Jason Wang wrote: >> We tried to reserve space for vnet header before >> xdp.data_hard_start. But this is useless since the packet could be >> modified by XDP which may invalidate the information stored in the >> header and there's no way for XDP to know the existence of the

On 10/28/2016 05:30 PM, Michal Privoznik wrote: > On 28.10.2016 14:17, Anton Gorlov wrote: >> 28.10.2016 23:32, Michal Privoznik пишет: >> >> >> On my host node i using system created bridge. example >> >> brctl show br1 >> bridge name bridge id STP enabled interfaces >> br1 8000.0025907925d3 no

We copy vnet header unconditionally in page_to_skb() this is wrong since XDP may modify the packet data. So let's keep a zeroed vnet header for not confusing the conversion between vnet header and skb metadata. In the future, we should able to detect whether or not the packet was modified and keep using the vnet header when packet was not touched. Fixes: f600b6905015 ("virtio_net: Add

On Wed, May 06, 2020 at 04:34:36PM +0800, Jason Wang wrote: > > On 2020/5/6 ??4:21, Jesper Dangaard Brouer wrote: > > On Wed, 6 May 2020 14:16:32 +0800 > > Jason Wang <jasowang at redhat.com> wrote: > > > > > We tried to reserve space for vnet header before > > > xdp.data_hard_start. But this is useless since the packet could be > > >

We tried to reserve space for vnet header before xdp.data_hard_start. But this is useless since the packet could be modified by XDP which may invalidate the information stored in the header and there's no way for XDP to know the existence of the vnet header currently. So let's just not reserve space for vnet header in this case. Cc: Jesper Dangaard Brouer <brouer at redhat.com>

We tried to reserve space for vnet header before xdp.data_hard_start. But this is useless since the packet could be modified by XDP which may invalidate the information stored in the header and there's no way for XDP to know the existence of the vnet header currently. So let's just not reserve space for vnet header in this case. Cc: Jesper Dangaard Brouer <brouer at redhat.com>

28.10.2016 23:32, Michal Privoznik пишет: On my host node i using system created bridge. example brctl show br1 bridge name bridge id STP enabled interfaces br1 8000.0025907925d3 no eth1 vnet0 vnet2

It seems the crash of llvm/clang build on aarch64 Debian has been fixed by r220941. Thanks, -Jiangning 2014-11-05 8:45 GMT+08:00 Jiangning Liu <liujiangning1 at gmail.com>: > The versions I'm using right now are > > * gcc: (Debian/Linaro 4.9.1-14) 4.9.1 > * libstdc++: libstdc++.so.6.0.20 > > Thanks, > -Jiangning > > 2014-11-05 4:46 GMT+08:00 Chris Bieneman

Ok, I'll put a patch together to fix this later today. I'll probably do what Reid was suggesting and use what is already in there for Windows. Thanks, Samuel Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote on 11/04/2014 12:11:08 PM: > From: Bill Schmidt <wschmidt at linux.vnet.ibm.com> > To: Samuel F Antao/Watson/IBM at IBMUS > Cc: azanella at

Adding Jiangning Liu to the thread. Jiangning reported a similar issue on the llvm-commits list on Debian aarch64. In general it sounds like std::call_once may not really be bug free. Jiangning, can you please provide your gcc/libstdc++ version? Thanks, -Chris > On Nov 4, 2014, at 9:38 AM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > > On Tue, 2014-11-04 at 12:17

❦ 3 novembre 2016 20:43 +0300, Anton Gorlov <stalker@altlinux.ru> : >> ... but *is* in the status xml (i.e. the output of "visrh dumpxml >> $domain" while the domain is running, and also the xml provided on stdin >> to the qemu and network hooks when they are called). >> >> (also, what Vincent said in his email - names with the prefix

Deep in the discussion of this bug, unfortunately mostly in private comments: https://bugzilla.redhat.com/show_bug.cgi?id=1594515 we decided it'd be more flexible for RHV if we had a way to map individual NICs to target networks and bridges. This can be done by adding a new --mac option so you can specify the exact mapping you need: $ virt-v2v [...] \ --mac

On 04/17/2017 11:01 PM, Jason Wang wrote: > > > On 2017?04?16? 00:38, Vladislav Yasevich wrote: >> Curreclty virtion net header is fixed size and adding things to it is rather >> difficult to do. This series attempt to add the infrastructure as well as some >> extensions that try to resolve some deficiencies we currently have. >> >> First, vnet header only