search for: lowerdevs

Displaying 20 results from an estimated 35 matches for "lowerdevs".

Did you mean: lowerdev
2018 May 22
2
[PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework
...I don't see no reason to break this pattern here. Other masters are setup from userspace, this one is set up automatically by kernel. So the bar is higher, we need an interface that existing userspace knows about. We can't just say "oh if userspace set this up it should know to skip lowerdevs". Otherwise multiple interfaces with same mac tend to confuse userspace. -- MST
2018 May 22
2
[PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework
...I don't see no reason to break this pattern here. Other masters are setup from userspace, this one is set up automatically by kernel. So the bar is higher, we need an interface that existing userspace knows about. We can't just say "oh if userspace set this up it should know to skip lowerdevs". Otherwise multiple interfaces with same mac tend to confuse userspace. -- MST
2018 May 22
2
[PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework
...ern here. > > > >Other masters are setup from userspace, this one is set up automatically > >by kernel. So the bar is higher, we need an interface that existing > >userspace knows about. We can't just say "oh if userspace set this up > >it should know to skip lowerdevs". > > > >Otherwise multiple interfaces with same mac tend to confuse userspace. > > No difference, really. > Regardless who does the setup, and independent userspace deamon should > react accordingly. If the deamon does the setup itself, it's reasonable to require...
2018 May 22
2
[PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework
...ern here. > > > >Other masters are setup from userspace, this one is set up automatically > >by kernel. So the bar is higher, we need an interface that existing > >userspace knows about. We can't just say "oh if userspace set this up > >it should know to skip lowerdevs". > > > >Otherwise multiple interfaces with same mac tend to confuse userspace. > > No difference, really. > Regardless who does the setup, and independent userspace deamon should > react accordingly. If the deamon does the setup itself, it's reasonable to require...
2018 May 22
2
[PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework
On Tue, May 22, 2018 at 03:26:26PM +0200, Jiri Pirko wrote: > Tue, May 22, 2018 at 03:17:37PM CEST, mst at redhat.com wrote: > >On Tue, May 22, 2018 at 03:14:22PM +0200, Jiri Pirko wrote: > >> Tue, May 22, 2018 at 03:12:40PM CEST, mst at redhat.com wrote: > >> >On Tue, May 22, 2018 at 11:08:53AM +0200, Jiri Pirko wrote: > >> >> Tue, May 22, 2018 at
2018 May 22
2
[PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework
On Tue, May 22, 2018 at 03:26:26PM +0200, Jiri Pirko wrote: > Tue, May 22, 2018 at 03:17:37PM CEST, mst at redhat.com wrote: > >On Tue, May 22, 2018 at 03:14:22PM +0200, Jiri Pirko wrote: > >> Tue, May 22, 2018 at 03:12:40PM CEST, mst at redhat.com wrote: > >> >On Tue, May 22, 2018 at 11:08:53AM +0200, Jiri Pirko wrote: > >> >> Tue, May 22, 2018 at
2018 May 22
0
[PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework
...reason to break this pattern here. > >Other masters are setup from userspace, this one is set up automatically >by kernel. So the bar is higher, we need an interface that existing >userspace knows about. We can't just say "oh if userspace set this up >it should know to skip lowerdevs". > >Otherwise multiple interfaces with same mac tend to confuse userspace. No difference, really. Regardless who does the setup, and independent userspace deamon should react accordingly.
2010 Jan 27
13
[Bridge] [PATCH 0/3 v3] macvtap driver
This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don''t use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work *
2010 Jan 27
13
[Bridge] [PATCH 0/3 v3] macvtap driver
This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don''t use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work *
2010 Jan 27
13
[Bridge] [PATCH 0/3 v3] macvtap driver
This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don''t use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work *
2018 May 22
0
[PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework
...gt; >> >Other masters are setup from userspace, this one is set up automatically >> >by kernel. So the bar is higher, we need an interface that existing >> >userspace knows about. We can't just say "oh if userspace set this up >> >it should know to skip lowerdevs". >> > >> >Otherwise multiple interfaces with same mac tend to confuse userspace. >> >> No difference, really. >> Regardless who does the setup, and independent userspace deamon should >> react accordingly. > >If the deamon does the setup itself...
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
[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
[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
[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
[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
[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
[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