search for: side_channel

...nly used if the VF is not present, and there are multiple instances such as dealing with east/west or broadcast/multicast traffic where it may be desirable to use the para-virtual interface rather then deal with PCI overhead/bottleneck to send the packet. What if instead of BACKUP we used the name SIDE_CHANNEL? Basically it is a bit of double entendre as we are using the physical MAC address to provide configuration information, and then in addition this interface acts as a secondary channel for passing frames to and from the guest rather than just using the VF. Just a thought. Thanks. - Alex

...nly used if the VF is not present, and there are multiple instances such as dealing with east/west or broadcast/multicast traffic where it may be desirable to use the para-virtual interface rather then deal with PCI overhead/bottleneck to send the packet. What if instead of BACKUP we used the name SIDE_CHANNEL? Basically it is a bit of double entendre as we are using the physical MAC address to provide configuration information, and then in addition this interface acts as a secondary channel for passing frames to and from the guest rather than just using the VF. Just a thought. Thanks. - Alex

...sibly that's when you will want something more powerful > such as a full bridge. east-west optimization of unicasts would be a harder problem to solve as somehow the hypervisor needs to indicate the VM about the local dest. macs > > >> What if instead of BACKUP we used the name SIDE_CHANNEL? Basically it >> is a bit of double entendre as we are using the physical MAC address >> to provide configuration information, and then in addition this >> interface acts as a secondary channel for passing frames to and from >> the guest rather than just using the VF. >&g...

...sibly that's when you will want something more powerful > such as a full bridge. east-west optimization of unicasts would be a harder problem to solve as somehow the hypervisor needs to indicate the VM about the local dest. macs > > >> What if instead of BACKUP we used the name SIDE_CHANNEL? Basically it >> is a bit of double entendre as we are using the physical MAC address >> to provide configuration information, and then in addition this >> interface acts as a secondary channel for passing frames to and from >> the guest rather than just using the VF. >&g...

...ue based on the NUMA affinity and fall back to the > virtio/netvsc when those fail. The way I see it, we'd need to pass a bunch of extra information host to guest, and we'd have to use a PV interface for it. When we do this, we'll need to have another feature bit, and we can call it SIDE_CHANNEL or whatever. > >> In the receive path, the broadcasts should only go the PF and reach the VM > >> via vitio so that the VM doesn't see duplicate broadcasts. > >> > >> > >> > > >> > To me the east/west scenario looks like you want so...

...robably even handle the Tx queue selection via a simple eBPF program and map since the input for whatever is used to select Tx should be pretty simple, destination MAC, source NUMA node, etc, and the data-set shouldn't be too large. >> > > What if instead of BACKUP we used the name SIDE_CHANNEL? Basically it >> > > is a bit of double entendre as we are using the physical MAC address >> > > to provide configuration information, and then in addition this >> > > interface acts as a secondary channel for passing frames to and from >> > > the gue...

...robably even handle the Tx queue selection via a simple eBPF program and map since the input for whatever is used to select Tx should be pretty simple, destination MAC, source NUMA node, etc, and the data-set shouldn't be too large. >> > > What if instead of BACKUP we used the name SIDE_CHANNEL? Basically it >> > > is a bit of double entendre as we are using the physical MAC address >> > > to provide configuration information, and then in addition this >> > > interface acts as a secondary channel for passing frames to and from >> > > the gue...

...enario looks like you want something more similar to a bridge on top of the virtio/PT pair. So I suspect that use-case will need a separate configuration bit, and possibly that's when you will want something more powerful such as a full bridge. > What if instead of BACKUP we used the name SIDE_CHANNEL? Basically it > is a bit of double entendre as we are using the physical MAC address > to provide configuration information, and then in addition this > interface acts as a secondary channel for passing frames to and from > the guest rather than just using the VF. > > Just a thou...

...lem to solve as > somehow the hypervisor needs to indicate the VM about the local dest. macs Using a bridge with a dedicated device for east/west would let bridge use standard learning techniques for that perhaps? > > > > > > > What if instead of BACKUP we used the name SIDE_CHANNEL? Basically it > > > is a bit of double entendre as we are using the physical MAC address > > > to provide configuration information, and then in addition this > > > interface acts as a secondary channel for passing frames to and from > > > the guest rather than j...

...> >> virtio/netvsc when those fail. > > The way I see it, we'd need to pass a bunch of extra information > > host to guest, and we'd have to use a PV interface for it. > > When we do this, we'll need to have another > > feature bit, and we can call it SIDE_CHANNEL or whatever. > > > > > >>>> In the receive path, the broadcasts should only go the PF and reach the VM > >>>> via vitio so that the VM doesn't see duplicate broadcasts. > >>>> > >>>> > >>>>> To me the...

...finity and fall back to the >> virtio/netvsc when those fail. > The way I see it, we'd need to pass a bunch of extra information > host to guest, and we'd have to use a PV interface for it. > When we do this, we'll need to have another > feature bit, and we can call it SIDE_CHANNEL or whatever. > > >>>> In the receive path, the broadcasts should only go the PF and reach the VM >>>> via vitio so that the VM doesn't see duplicate broadcasts. >>>> >>>> >>>>> To me the east/west scenario looks like you want...

...finity and fall back to the >> virtio/netvsc when those fail. > The way I see it, we'd need to pass a bunch of extra information > host to guest, and we'd have to use a PV interface for it. > When we do this, we'll need to have another > feature bit, and we can call it SIDE_CHANNEL or whatever. > > >>>> In the receive path, the broadcasts should only go the PF and reach the VM >>>> via vitio so that the VM doesn't see duplicate broadcasts. >>>> >>>> >>>>> To me the east/west scenario looks like you want...

This patch series extends virtio_net to take over VF datapath by simulating a transparent bond without creating any additional netdev. I understand that there are some comments suggesting an alternate model that is based on 3 driver model(virtio_net, VF driver, a new driver virt_bond that acts as a master to virtio_net and VF). Would like to get some feedback on the right way to solve the live