Displaying 20 results from an estimated 1000 matches similar to: "[Bridge] [PATCH 0/3 v3] macvtap driver"
2009 Dec 03
3
[RFC 0/2] macvtap, second try
I did not get this ready for the merge window, but people asked what
the status of this is so I'm posting it now to solicit feedback.
The first patch just adds some hooks into macvlan.c and is less
invasive than the previous version. That part should be fine
and I'd like this to get merged into macvlan for 2.6.33 if people
agree that the approach is right.
The second patch adds the
2009 Dec 03
3
[RFC 0/2] macvtap, second try
I did not get this ready for the merge window, but people asked what
the status of this is so I'm posting it now to solicit feedback.
The first patch just adds some hooks into macvlan.c and is less
invasive than the previous version. That part should be fine
and I'd like this to get merged into macvlan for 2.6.33 if people
agree that the approach is right.
The second patch adds the
2009 Dec 03
3
[RFC 0/2] macvtap, second try
I did not get this ready for the merge window, but people asked what
the status of this is so I'm posting it now to solicit feedback.
The first patch just adds some hooks into macvlan.c and is less
invasive than the previous version. That part should be fine
and I'd like this to get merged into macvlan for 2.6.33 if people
agree that the approach is right.
The second patch adds the
2009 Nov 24
4
[Bridge] [PATCHv2 0/4] macvlan: add vepa and bridge mode
Second version, all feedback so far addressed, thanks for the
help and interest!
The patch to iproute2 has not changed, so I'm not including
it this time. Patch 4/4 (the netlink interface) is basically
unchanged as well but included for completeness.
The other changes have moved forward a bit, to the point where
I find them a lot cleaner and am more confident in the code
being ready for
2009 Nov 24
4
[Bridge] [PATCHv2 0/4] macvlan: add vepa and bridge mode
Second version, all feedback so far addressed, thanks for the
help and interest!
The patch to iproute2 has not changed, so I'm not including
it this time. Patch 4/4 (the netlink interface) is basically
unchanged as well but included for completeness.
The other changes have moved forward a bit, to the point where
I find them a lot cleaner and am more confident in the code
being ready for
2009 Nov 24
4
[Bridge] [PATCHv2 0/4] macvlan: add vepa and bridge mode
Second version, all feedback so far addressed, thanks for the
help and interest!
The patch to iproute2 has not changed, so I'm not including
it this time. Patch 4/4 (the netlink interface) is basically
unchanged as well but included for completeness.
The other changes have moved forward a bit, to the point where
I find them a lot cleaner and am more confident in the code
being ready for
2009 Nov 26
5
[Bridge] [PATCHv3 0/4] macvlan: add vepa and bridge mode
Not many changes this time, just integrated a bug fix
and all the coding style feedback from Eric Dumazet
and Patrick McHardy.
I'll keep the patch for network namespaces on the tx
path out of this series for now, because the discussion
is still ongoing and it addresses an unrelated issue.
---
Version 2 description:
The patch to iproute2 has not changed, so I'm not including
it this
2009 Nov 26
5
[Bridge] [PATCHv3 0/4] macvlan: add vepa and bridge mode
Not many changes this time, just integrated a bug fix
and all the coding style feedback from Eric Dumazet
and Patrick McHardy.
I'll keep the patch for network namespaces on the tx
path out of this series for now, because the discussion
is still ongoing and it addresses an unrelated issue.
---
Version 2 description:
The patch to iproute2 has not changed, so I'm not including
it this
2009 Nov 26
5
[Bridge] [PATCHv3 0/4] macvlan: add vepa and bridge mode
Not many changes this time, just integrated a bug fix
and all the coding style feedback from Eric Dumazet
and Patrick McHardy.
I'll keep the patch for network namespaces on the tx
path out of this series for now, because the discussion
is still ongoing and it addresses an unrelated issue.
---
Version 2 description:
The patch to iproute2 has not changed, so I'm not including
it this
2011 Dec 05
8
[net-next RFC PATCH 0/5] Series short description
multiple queue virtio-net: flow steering through host/guest cooperation
Hello all:
This is a rough series adds the guest/host cooperation of flow
steering support based on Krish Kumar's multiple queue virtio-net
driver patch 3/3 (http://lwn.net/Articles/467283/).
This idea is simple, the backend pass the rxhash to the guest and
guest would tell the backend the hash to queue mapping when
2011 Dec 05
8
[net-next RFC PATCH 0/5] Series short description
multiple queue virtio-net: flow steering through host/guest cooperation
Hello all:
This is a rough series adds the guest/host cooperation of flow
steering support based on Krish Kumar's multiple queue virtio-net
driver patch 3/3 (http://lwn.net/Articles/467283/).
This idea is simple, the backend pass the rxhash to the guest and
guest would tell the backend the hash to queue mapping when
2009 Nov 17
11
[Bridge] [PATCH 0/3] macvlan: add vepa and bridge mode
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 have found out
2009 Nov 17
11
[Bridge] [PATCH 0/3] macvlan: add vepa and bridge mode
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 have found out
2009 Nov 17
11
[Bridge] [PATCH 0/3] macvlan: add vepa and bridge mode
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 have found out
2014 Dec 17
20
[PATCH 00/10] Split UFO into v4 and v6 versions.
UFO support in the kernel applies to both IPv4 and IPv6 protocols
with the same device feature. However some devices may not be able
to support one of the offloads. For this we split the UFO offload
feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part and
this series introduces NETIF_F_UFO6.
As a result of this work, we can now re-enable NETIF_F_UFO on
virtio_net devices and restore
2014 Dec 17
20
[PATCH 00/10] Split UFO into v4 and v6 versions.
UFO support in the kernel applies to both IPv4 and IPv6 protocols
with the same device feature. However some devices may not be able
to support one of the offloads. For this we split the UFO offload
feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part and
this series introduces NETIF_F_UFO6.
As a result of this work, we can now re-enable NETIF_F_UFO on
virtio_net devices and restore
2013 Feb 13
14
[Bridge] [PATCH v10 net-next 00/12] VLAN filtering/VLAN aware bridge
Changes since v9:
* series re-ordering so make functionality more distinct. Basic vlan
filtering is patches 1-4. Support for PVID/untagged vlans is patches
5 and 6. VLAN support for FDB/MDB is patches 7-11. Patch 12 is
still additional egress policy.
* Slight simplification to code that extracts the VID from skb. Since we
now depend on the vlan module, at the time of input skb_tci is
2015 Apr 21
2
[PATCH v4 8/8] macvtap/tun: add VNET_BE flag
On Fri, Apr 10, 2015 at 12:20:21PM +0200, Greg Kurz wrote:
> The VNET_LE flag was introduced to fix accesses to virtio 1.0 headers
> that are always little-endian. It can also be used to handle the special
> case of a legacy little-endian device implemented by a big-endian host.
>
> Let's add a flag and ioctls for big-endian devices as well. If both flags
> are set,
2015 Apr 21
2
[PATCH v4 8/8] macvtap/tun: add VNET_BE flag
On Fri, Apr 10, 2015 at 12:20:21PM +0200, Greg Kurz wrote:
> The VNET_LE flag was introduced to fix accesses to virtio 1.0 headers
> that are always little-endian. It can also be used to handle the special
> case of a legacy little-endian device implemented by a big-endian host.
>
> Let's add a flag and ioctls for big-endian devices as well. If both flags
> are set,
2015 Apr 10
16
[PATCH v4 0/8] vhost: support for cross endian guests
Hi,
This patchset allows vhost to be used with legacy virtio when guest and host
have a different endianness.
Patch 7 got rewritten according to Cornelia's and Michael's comments. I have
also introduced patch 8 that brings BE vnet headers support to tun/macvtap.
This series is enough to have vhost_net working flawlessly. I could
succesfully reboot guests from ppc64 to ppc64le and