search for: achiad

On Tue, Dec 05, 2017 at 11:59:17AM +0200, achiad shochat wrote: > Then we'll have a single solution for both netvsc and virtio (and any > other PV device). > And we could handle the VF DMA dirt issue agnostically. For the record, I won't block patches adding this kist to virtio on the basis that they must be generic. It's no...

On Tue, Dec 05, 2017 at 11:59:17AM +0200, achiad shochat wrote: > Then we'll have a single solution for both netvsc and virtio (and any > other PV device). > And we could handle the VF DMA dirt issue agnostically. For the record, I won't block patches adding this kist to virtio on the basis that they must be generic. It's no...

On 3 December 2017 at 19:35, Stephen Hemminger <stephen at networkplumber.org> wrote: > On Sun, 3 Dec 2017 11:14:37 +0200 > achiad shochat <achiad.mellanox at gmail.com> wrote: > >> On 3 December 2017 at 07:05, Michael S. Tsirkin <mst at redhat.com> wrote: >> > On Fri, Dec 01, 2017 at 12:08:59PM -0800, Shannon Nelson wrote: >> >> On 11/30/2017 6:11 AM, Michael S. Tsirkin wrote: >&gt...

On 3 December 2017 at 19:35, Stephen Hemminger <stephen at networkplumber.org> wrote: > On Sun, 3 Dec 2017 11:14:37 +0200 > achiad shochat <achiad.mellanox at gmail.com> wrote: > >> On 3 December 2017 at 07:05, Michael S. Tsirkin <mst at redhat.com> wrote: >> > On Fri, Dec 01, 2017 at 12:08:59PM -0800, Shannon Nelson wrote: >> >> On 11/30/2017 6:11 AM, Michael S. Tsirkin wrote: >&gt...

On Mon, Dec 4, 2017 at 1:51 AM, achiad shochat <achiad.mellanox at gmail.com> wrote: > On 3 December 2017 at 19:35, Stephen Hemminger > <stephen at networkplumber.org> wrote: >> On Sun, 3 Dec 2017 11:14:37 +0200 >> achiad shochat <achiad.mellanox at gmail.com> wrote: >> >>> On 3 Decembe...

On 3 December 2017 at 07:05, Michael S. Tsirkin <mst at redhat.com> wrote: > On Fri, Dec 01, 2017 at 12:08:59PM -0800, Shannon Nelson wrote: >> 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 >>...

On 3 December 2017 at 07:05, Michael S. Tsirkin <mst at redhat.com> wrote: > On Fri, Dec 01, 2017 at 12:08:59PM -0800, Shannon Nelson wrote: >> 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 >>...

On 4 December 2017 at 18:30, Alexander Duyck <alexander.duyck at gmail.com> wrote: > On Mon, Dec 4, 2017 at 1:51 AM, achiad shochat > <achiad.mellanox at gmail.com> wrote: >> On 3 December 2017 at 19:35, Stephen Hemminger >> <stephen at networkplumber.org> wrote: >>> On Sun, 3 Dec 2017 11:14:37 +0200 >>> achiad shochat <achiad.mellanox at gmail.com> wrote: >>>...

On Tue, 5 Dec 2017 21:20:07 +0200 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Tue, Dec 05, 2017 at 11:59:17AM +0200, achiad shochat wrote: > > Then we'll have a single solution for both netvsc and virtio (and any > > other PV device). > > And we could handle the VF DMA dirt issue agnostically. > > For the record, I won't block patches adding this kist to virtio > on the basis that t...

On Wed, Dec 6, 2017 at 11:28 PM, achiad shochat <achiad.mellanox at gmail.com> wrote: > On 5 December 2017 at 21:20, Michael S. Tsirkin <mst at redhat.com> wrote: >> On Tue, Dec 05, 2017 at 11:59:17AM +0200, achiad shochat wrote: >>> Then we'll have a single solution for both netvsc and virtio (and any &...

On Wed, Dec 6, 2017 at 11:28 PM, achiad shochat <achiad.mellanox at gmail.com> wrote: > On 5 December 2017 at 21:20, Michael S. Tsirkin <mst at redhat.com> wrote: >> On Tue, Dec 05, 2017 at 11:59:17AM +0200, achiad shochat wrote: >>> Then we'll have a single solution for both netvsc and virtio (and any &...

On Sun, 3 Dec 2017 11:14:37 +0200 achiad shochat <achiad.mellanox at gmail.com> wrote: > On 3 December 2017 at 07:05, Michael S. Tsirkin <mst at redhat.com> wrote: > > On Fri, Dec 01, 2017 at 12:08:59PM -0800, Shannon Nelson wrote: > >> On 11/30/2017 6:11 AM, Michael S. Tsirkin wrote: > >> >...

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 Tue, 5 Dec 2017 11:59:17 +0200, achiad shochat wrote: > >>>> I second Jacob - having a netdev of one device driver enslave a netdev > >>>> of another device driver is an awkward a-symmetric model. > >>>> Regardless of whether they share the same backend device. > >>>> Only I am...

On Tue, 5 Dec 2017 11:59:17 +0200, achiad shochat wrote: > >>>> I second Jacob - having a netdev of one device driver enslave a netdev > >>>> of another device driver is an awkward a-symmetric model. > >>>> Regardless of whether they share the same backend device. > >>>> Only I am...

...(from MST) > > > > independent driver: > > 7. code reuse. > > With netvsc? That precludes a separate device though because of > compatibility. Hopefully with one of the established bonding drivers (fingers crossed). We may see proliferation of special bonds (see Achiad's presentation from last netdev about NIC-NUMA-node-bonds). > > separate device: > > I'm not sure I understand how "separate device" is different from > "separate netdev". Do you advocate for a special device who's job is > just to tell the gues...

...(from MST) > > > > independent driver: > > 7. code reuse. > > With netvsc? That precludes a separate device though because of > compatibility. Hopefully with one of the established bonding drivers (fingers crossed). We may see proliferation of special bonds (see Achiad's presentation from last netdev about NIC-NUMA-node-bonds). > > separate device: > > I'm not sure I understand how "separate device" is different from > "separate netdev". Do you advocate for a special device who's job is > just to tell the gues...

On Fri, Dec 01, 2017 at 12:08:59PM -0800, Shannon Nelson wrote: > 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...

On Tue, 5 Dec 2017 14:29:28 -0800 Jakub Kicinski <kubakici at wp.pl> wrote: > On Tue, 5 Dec 2017 11:59:17 +0200, achiad shochat wrote: > > >>>> I second Jacob - having a netdev of one device driver enslave a netdev > > >>>> of another device driver is an awkward a-symmetric model. > > >>>> Regardless of whether they share the same backend device. > > >&g...