search for: enslaving

What is the maximum number of devices that can be enslaved in a bridge interface? I have tried enslaving 512 devices. Although the brctl tool did not complain while adding them, when I use brctl show command it only shows 255. Thanks

I have a bridge br0, it enslaves two NICs: eth0 and eth1. By using "cat /proc/net/dev ", i can see the Rx/Tx packets and bytes through each interface. just like this: [* time tick 1 *] Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed

...nd fits that functionality. And, as I hear in this thread, it is hard to make it work out of the box. So I think the right thing would be to write a new dedicated module for this purpose. Re policy - Indeed the HV can request a policy from the guest but that's not a claim for the virtio device enslaving the pass-through device. Any policy can be queried by the upper enslaving device. Bottom line - I do not see a single reason to have the virtio netdev (nor netvsc or any other PV netdev) enslave another netdev by itself. If we'd do it right with netvsc from the beginning we wouldn't need t...

...nd fits that functionality. And, as I hear in this thread, it is hard to make it work out of the box. So I think the right thing would be to write a new dedicated module for this purpose. Re policy - Indeed the HV can request a policy from the guest but that's not a claim for the virtio device enslaving the pass-through device. Any policy can be queried by the upper enslaving device. Bottom line - I do not see a single reason to have the virtio netdev (nor netvsc or any other PV netdev) enslave another netdev by itself. If we'd do it right with netvsc from the beginning we wouldn't need t...

Ahoy, I've encountered some confusing semantics with using PACKET(7) sockets on bridge-enslaved interfaces. Specifically, if my socket accepts all types of frame (bind() to ETH_P_ALL) then it gets all packets; but if it accepts any specific type (e.g. ETH_P_IP), then it receives no packets at all. That is how it's coded in net/core/dev.c's netif_receive_skb(). First ETH_P_ALL

Setting up bonding in active-backup mode 1 (using ARP monitoring) on a server, it looked OK, but pulling the active link cable didn't actually work, it didn't fail over. Eventually with manual playing around with modprobe, ifconfig, ifenslave, etc., a solution was stumbled upon: enslave the eth1 device before eth0, and all is good. Why this should matter is a puzzle - I could not find

Hi all Assume that you have a linux bridge with two interfaces eth0 and eth1 enslaved to this bridge What is the difference between sniffing the bridge and sniffing its interfaces? tcpdump -i br0 vs tcpdump -i eth0 Thanks MiniME -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Tue, Dec 19, 2017 at 10:41 AM, Stephen Hemminger <stephen at networkplumber.org> wrote: > On Tue, 19 Dec 2017 13:21:17 -0500 (EST) > David Miller <davem at davemloft.net> wrote: > >> From: Stephen Hemminger <stephen at networkplumber.org> >> Date: Tue, 19 Dec 2017 09:55:48 -0800 >> >> > could be 10ms, just enough to let udev do its renaming

On Tue, Dec 19, 2017 at 10:41 AM, Stephen Hemminger <stephen at networkplumber.org> wrote: > On Tue, 19 Dec 2017 13:21:17 -0500 (EST) > David Miller <davem at davemloft.net> wrote: > >> From: Stephen Hemminger <stephen at networkplumber.org> >> Date: Tue, 19 Dec 2017 09:55:48 -0800 >> >> > could be 10ms, just enough to let udev do its renaming

I can think of several potential differences. ?You may miss any bridge specific traffic (STP, LLDP) using the interfaces generated by the bridge itself. If you have vlan tagged sub interfaces you might also miss that traffic if you were snooping a particular interface. Obviously you will miss any on-wire broadcast traffic specific to the layer1 connection a particular interface was connected to

On Tue, 26 Mar 2019 19:48:13 -0400 Si-Wei Liu <si-wei.liu at oracle.com> wrote: > When a netdev appears through hot plug then gets enslaved by a failover > master that is already up and running, the slave will be opened > right away after getting enslaved. Today there's a race that userspace > (udev) may fail to rename the slave if the kernel (net_failover) > opens the

On Tue, 26 Mar 2019 19:48:13 -0400 Si-Wei Liu <si-wei.liu at oracle.com> wrote: > When a netdev appears through hot plug then gets enslaved by a failover > master that is already up and running, the slave will be opened > right away after getting enslaved. Today there's a race that userspace > (udev) may fail to rename the slave if the kernel (net_failover) > opens the

Hello, I am working on Network-Simulation (VNUML). Our simulator uses linux bridgi= ng to connect the UMLs. So there is one problem: The example is the following: There are two hosts simulating one big net. The two hosts have connection over the external nets Net3 and Net6 (see htt= p://www.uni-koblenz.de/~timbub/verteilteSim3.GIF), but in fact there is onl= y one physical connection between the

...serspace might rename the device after > + * the interface had been brought up and running since > + * the point kernel initiated auto-enslavement. Allow > + * live name change even when these slave devices are > + * up and running. > + * > + * Typically, users of these auto-enslaving devices > + * don't actually care about slave name change, as > + * they are supposed to operate on master interface > + * directly. > + */ > + if (dev->flags & IFF_UP && > + likely(!(dev->priv_flags & IFF_LIVE_NAME_CHANGE))) > return -EBUSY...

...serspace might rename the device after > + * the interface had been brought up and running since > + * the point kernel initiated auto-enslavement. Allow > + * live name change even when these slave devices are > + * up and running. > + * > + * Typically, users of these auto-enslaving devices > + * don't actually care about slave name change, as > + * they are supposed to operate on master interface > + * directly. > + */ > + if (dev->flags & IFF_UP && > + likely(!(dev->priv_flags & IFF_LIVE_NAME_CHANGE))) > return -EBUSY...

...read, it is hard to make it work out of the box. >> So I think the right thing would be to write a new dedicated module >> for this purpose. >> >> Re policy - >> Indeed the HV can request a policy from the guest but that's not a >> claim for the virtio device enslaving the pass-through device. >> Any policy can be queried by the upper enslaving device. >> >> Bottom line - I do not see a single reason to have the virtio netdev >> (nor netvsc or any other PV netdev) enslave another netdev by itself. >> If we'd do it right with netv...

...read, it is hard to make it work out of the box. >> So I think the right thing would be to write a new dedicated module >> for this purpose. >> >> Re policy - >> Indeed the HV can request a policy from the guest but that's not a >> claim for the virtio device enslaving the pass-through device. >> Any policy can be queried by the upper enslaving device. >> >> Bottom line - I do not see a single reason to have the virtio netdev >> (nor netvsc or any other PV netdev) enslave another netdev by itself. >> If we'd do it right with netv...

On 11/30/2017 6:11 AM, Michael S. Tsirkin wrote: > On Thu, Nov 30, 2017 at 10:08:45AM +0200, achiad shochat wrote: >> Re. problem #2: >> Indeed the best way to address it seems to be to enslave the VF driver >> netdev under a persistent anchor netdev. >> And it's indeed desired to allow (but not enforce) PV netdev and VF >> netdev to work in conjunction.

On 11/30/2017 6:11 AM, Michael S. Tsirkin wrote: > On Thu, Nov 30, 2017 at 10:08:45AM +0200, achiad shochat wrote: >> Re. problem #2: >> Indeed the best way to address it seems to be to enslave the VF driver >> netdev under a persistent anchor netdev. >> And it's indeed desired to allow (but not enforce) PV netdev and VF >> netdev to work in conjunction.

On 30 November 2017 at 05:29, Jason Wang <jasowang at redhat.com> wrote: > > > On 2017?11?29? 03:27, Jesse Brandeburg wrote: >> >> Hi, I'd like to get some feedback on a proposal to enhance virtio-net >> to ease configuration of a VM and that would enable live migration of >> passthrough network SR-IOV devices. >> >> Today we have SR-IOV