search for: macvlan

This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others h...

This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others h...

This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others h...

...for inclusion. The implementation hardly resembles Erics original patch now, so I've dropped his signed-off-by. Please take a look and ack if you are happy so we can get it into 2.6.33. --- Version 1 description: This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others h...

...for inclusion. The implementation hardly resembles Erics original patch now, so I've dropped his signed-off-by. Please take a look and ack if you are happy so we can get it into 2.6.33. --- Version 1 description: This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others h...

...for inclusion. The implementation hardly resembles Erics original patch now, so I've dropped his signed-off-by. Please take a look and ack if you are happy so we can get it into 2.6.33. --- Version 1 description: This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others h...

...for inclusion. The implementation hardly resembles Erics original patch now, so I've dropped his signed-off-by. Please take a look and ack if you are happy so we can get it into 2.6.33. --- Version 1 description: This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others h...

...for inclusion. The implementation hardly resembles Erics original patch now, so I've dropped his signed-off-by. Please take a look and ack if you are happy so we can get it into 2.6.33. --- Version 1 description: This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others h...

...for inclusion. The implementation hardly resembles Erics original patch now, so I've dropped his signed-off-by. Please take a look and ack if you are happy so we can get it into 2.6.33. --- Version 1 description: This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others h...

..., but it will have > to do equivalent work of copying an skb most likely, so either way > you'll probably get a big performance hit. Using the same pktgen script (i.e with clone=0) I see that a veth-->bridge-->veth configuration gives about 400K PPS forwarding performance where macvlan-->veth-->macvlan gives 680K PPS (again, I made sure that the bridge has applied learning before I start the test). Basically, both the bridge and macvlan use hash on the destination mac in order to know to which device forward the packet, is there anything in the bridge logic that can exp...

..., but it will have > to do equivalent work of copying an skb most likely, so either way > you'll probably get a big performance hit. Using the same pktgen script (i.e with clone=0) I see that a veth-->bridge-->veth configuration gives about 400K PPS forwarding performance where macvlan-->veth-->macvlan gives 680K PPS (again, I made sure that the bridge has applied learning before I start the test). Basically, both the bridge and macvlan use hash on the destination mac in order to know to which device forward the packet, is there anything in the bridge logic that can exp...

On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > Since we now have support for software CRC32c offload, turn it on > for macvlan and macvtap devices so that guests can take advantage > of offload SCTP checksums to the host or host hardware. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > drivers/net/macvlan.c | 5 +++-- > drivers/net/tap.c | 8 +++++--- > 2 files change...

On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > Since we now have support for software CRC32c offload, turn it on > for macvlan and macvtap devices so that guests can take advantage > of offload SCTP checksums to the host or host hardware. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > drivers/net/macvlan.c | 5 +++-- > drivers/net/tap.c | 8 +++++--- > 2 files change...

Hi, libvirt (0.9.11) refuses to start KVM based virtual machines on my system when changing the network connection from "host bridge" to "direct" (macvtap/macvlan), neither in "bridge" nor in "vepa" mode: "Cannot create macvlan devices on this platform" That's astonishing because I can easily setup working macvlan devices using the "ip" command: "ip link add link eth0 type macvlan". Would someone help...

On Wed, May 02, 2018 at 09:27:00AM -0400, Vlad Yasevich wrote: > On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: > > On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > >> Since we now have support for software CRC32c offload, turn it on > >> for macvlan and macvtap devices so that guests can take advantage > >> of offload SCTP checksums to the host or host hardware. > >> > >> Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > >> --- > >> drivers/net/macvlan.c | 5 +++-- > >> dr...

On Wed, May 02, 2018 at 09:27:00AM -0400, Vlad Yasevich wrote: > On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: > > On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > >> Since we now have support for software CRC32c offload, turn it on > >> for macvlan and macvtap devices so that guests can take advantage > >> of offload SCTP checksums to the host or host hardware. > >> > >> Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > >> --- > >> drivers/net/macvlan.c | 5 +++-- > >> dr...

Since we now have support for software CRC32c offload, turn it on for macvlan and macvtap devices so that guests can take advantage of offload SCTP checksums to the host or host hardware. Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> --- drivers/net/macvlan.c | 5 +++-- drivers/net/tap.c | 8 +++++--- 2 files changed, 8 insertions(+), 5 deletions(-)...

Since we now have support for software CRC32c offload, turn it on for macvlan and macvtap devices so that guests can take advantage of offload SCTP checksums to the host or host hardware. Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> --- drivers/net/macvlan.c | 5 +++-- drivers/net/tap.c | 8 +++++--- include/uapi/linux/if_tun.h | 1 + 3...

On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: > On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: >> Since we now have support for software CRC32c offload, turn it on >> for macvlan and macvtap devices so that guests can take advantage >> of offload SCTP checksums to the host or host hardware. >> >> Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> >> --- >> drivers/net/macvlan.c | 5 +++-- >> drivers/net/tap.c | 8 +++++-...

...May 02, 2018 at 09:27:00AM -0400, Vlad Yasevich wrote: >> On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: >>> On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: >>>> Since we now have support for software CRC32c offload, turn it on >>>> for macvlan and macvtap devices so that guests can take advantage >>>> of offload SCTP checksums to the host or host hardware. >>>> >>>> Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> >>>> --- >>>> drivers/net/macvlan.c | 5 +++-- &g...