Tue, Nov 29, 2022 at 12:39:22AM CET, k...@kernel.org wrote:
>On Tue, 29 Nov 2022 00:29:42 +0100 Andrew Lunn wrote:
>> > How about:
>> >DEVLINK_PARAM_GENERIC_ID_ENABLE_LIVE_MIGRATION
>>
>> Much better.
>
>+1, although I care much less about the define name which is stupidly
>long anyway and m
gistered, no rx
>packet processing is ongoing.
>
>Fixes: 754b8a21a96d ("virtio_net: setup xdp_rxq_info")
>Signed-off-by: Parav Pandit
Reviewed-by: Jiri Pirko
___
Virtualization mailing list
Virtualization@lists.linux-foundation.
Thu, Feb 02, 2023 at 06:00:38AM CET, pa...@nvidia.com wrote:
>To easily audit the code, better to keep the device stop()
>sequence to be mirror of the device open() sequence.
>
>Signed-off-by: Parav Pandit
Reviewed-by: Jiri Pirko
If this is not fixing bug (which I believe is th
Thu, Feb 02, 2023 at 04:10:56PM CET, pa...@nvidia.com wrote:
>
>> From: Jiri Pirko
>> Sent: Thursday, February 2, 2023 7:26 AM
>>
>> Thu, Feb 02, 2023 at 06:00:38AM CET, pa...@nvidia.com wrote:
>> >To easily audit the code, better to keep the device stop() seq
From: Jiri Pirko
virtio_net_hdr_from_skb() fills up hdr_len to skb_headlen(skb).
Virtio spec introduced a feature VIRTIO_NET_F_GUEST_HDRLEN which when
set implicates that the driver provides the exact size of the header.
The driver already complies to fill the correct value. Introduce the
Fri, Feb 17, 2023 at 01:22:01PM CET, m...@redhat.com wrote:
>On Fri, Feb 17, 2023 at 01:15:47PM +0100, Jiri Pirko wrote:
>> From: Jiri Pirko
>>
>> virtio_net_hdr_from_skb() fills up hdr_len to skb_headlen(skb).
>>
>> Virtio spec introduced a feature VIRTIO_NET
Fri, Feb 17, 2023 at 02:47:36PM CET, m...@redhat.com wrote:
>On Fri, Feb 17, 2023 at 01:53:55PM +0100, Jiri Pirko wrote:
>> Fri, Feb 17, 2023 at 01:22:01PM CET, m...@redhat.com wrote:
>> >On Fri, Feb 17, 2023 at 01:15:47PM +0100, Jiri Pirko wrote:
>
Mon, Feb 20, 2023 at 01:55:33PM CET, m...@redhat.com wrote:
>On Mon, Feb 20, 2023 at 09:35:00AM +0100, Jiri Pirko wrote:
>> Fri, Feb 17, 2023 at 02:47:36PM CET, m...@redhat.com wrote:
>> >On Fri, Feb 17, 2023 at 01:53:55PM +0100, Jiri Pirko wrote:
>> >> Fri, Feb
Tue, Feb 21, 2023 at 03:38:10AM CET, jasow...@redhat.com wrote:
>
>在 2023/2/20 21:56, Jiri Pirko 写道:
>> Mon, Feb 20, 2023 at 01:55:33PM CET, m...@redhat.com wrote:
>> > On Mon, Feb 20, 2023 at 09:35:00AM +0100, Jiri Pirko wrote:
>> > > Fri, Feb 17, 2023 at 02:4
Mon, Feb 20, 2023 at 11:43:52PM CET, m...@redhat.com wrote:
>On Mon, Feb 20, 2023 at 02:56:08PM +0100, Jiri Pirko wrote:
>> Mon, Feb 20, 2023 at 01:55:33PM CET, m...@redhat.com wrote:
>> >On Mon, Feb 20, 2023 at 09:35:00AM +0100, Jiri Pirko wrote:
>> >> Fri, Feb
Tue, Feb 21, 2023 at 02:39:31PM CET, alvaro.ka...@solid-run.com wrote:
>Hi,
>
>Our device offers this feature bit as well.
>I don't have concrete numbers, but this feature will save our device a
>few cycles for every GSO packet.
Cool. I will try to include this into the patch description. Thanks!
From: Jiri Pirko
Virtio spec introduced a feature VIRTIO_NET_F_GUEST_HDRLEN which when
set implicates that the driver provides the exact size of the header.
Quoting the original virtio spec:
"hdr_len is a hint to the device as to how much of the header needs to
be kept to copy into each p
Tue, Feb 21, 2023 at 04:11:53PM CET, willemdebruijn.ker...@gmail.com wrote:
>Jiri Pirko wrote:
>> From: Jiri Pirko
>>
>> Virtio spec introduced a feature VIRTIO_NET_F_GUEST_HDRLEN which when
>> set implicates that the driver provides the exact size of the header.
Tue, Feb 21, 2023 at 05:12:33PM CET, willemdebruijn.ker...@gmail.com wrote:
>Jiri Pirko wrote:
>> Tue, Feb 21, 2023 at 04:11:53PM CET, willemdebruijn.ker...@gmail.com wrote:
>> >Jiri Pirko wrote:
>> >> From: Jiri Pirko
>> >>
>> >> Virtio spe
Tue, Feb 21, 2023 at 06:21:16PM CET, m...@redhat.com wrote:
>On Tue, Feb 21, 2023 at 03:47:41PM +0100, Jiri Pirko wrote:
>> From: Jiri Pirko
>>
>> Virtio spec introduced a feature VIRTIO_NET_F_GUEST_HDRLEN which when
>> set implicates that the driver provides the exac
From: Jiri Pirko
Virtio spec introduced a feature VIRTIO_NET_F_GUEST_HDRLEN which when
which when set implicates that device benefits from knowing the exact
size of the header. For compatibility, to signal to the device that
the header is reliable driver also needs to set this feature.
Without
Wed, Feb 22, 2023 at 12:24:18PM CET, m...@redhat.com wrote:
>On Wed, Feb 22, 2023 at 09:06:38AM +0100, Jiri Pirko wrote:
>> From: Jiri Pirko
>>
>> Virtio spec introduced a feature VIRTIO_NET_F_GUEST_HDRLEN which when
>> which when
>
>which when which when is
From: Jiri Pirko
Virtio spec introduced a feature VIRTIO_NET_F_GUEST_HDRLEN which when
set implicates that device benefits from knowing the exact size
of the header. For compatibility, to signal to the device that
the header is reliable driver also needs to set this feature.
Without this feature
Tue, Mar 05, 2019 at 01:50:59AM CET, si-wei@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 ren
Wed, Mar 27, 2019 at 12:48:13AM CET, si-wei@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 ren
Fri, Mar 29, 2019 at 04:15:12PM CET, step...@networkplumber.org wrote:
>On Thu, 28 Mar 2019 19:47:27 -0400
>Si-Wei Liu wrote:
>
>> +if (unlikely(dev->flags & IFF_UP)) {
>> +struct netdev_notifier_change_info change_info;
>> +
>> +change_info.flags_changed = 0;
>
>Simple
Fri, Feb 16, 2018 at 07:11:19PM CET, sridhar.samudr...@intel.com wrote:
>Patch 1 introduces a new feature bit VIRTIO_NET_F_BACKUP that can be
>used by hypervisor to indicate that virtio_net interface should act as
>a backup for another device with the same MAC address.
>
>Ppatch 2 is in response to
Tue, Feb 20, 2018 at 05:04:29PM CET, alexander.du...@gmail.com wrote:
>On Tue, Feb 20, 2018 at 2:42 AM, Jiri Pirko wrote:
>> Fri, Feb 16, 2018 at 07:11:19PM CET, sridhar.samudr...@intel.com wrote:
>>>Patch 1 introduces a new feature bit VIRTIO_NET_F_BACKUP that can be
>&g
Tue, Feb 20, 2018 at 06:23:49PM CET, alexander.du...@gmail.com wrote:
>On Tue, Feb 20, 2018 at 8:29 AM, Jiri Pirko wrote:
>> Tue, Feb 20, 2018 at 05:04:29PM CET, alexander.du...@gmail.com wrote:
>>>On Tue, Feb 20, 2018 at 2:42 AM, Jiri Pirko wrote:
>>>> Fri,
Tue, Feb 20, 2018 at 06:14:32PM CET, sridhar.samudr...@intel.com wrote:
>On 2/20/2018 8:29 AM, Jiri Pirko wrote:
>> Tue, Feb 20, 2018 at 05:04:29PM CET, alexander.du...@gmail.com wrote:
>> > On Tue, Feb 20, 2018 at 2:42 AM, Jiri Pirko wrote:
>> > > Fri,
Tue, Feb 20, 2018 at 11:33:56PM CET, kubak...@wp.pl wrote:
>On Tue, 20 Feb 2018 21:14:10 +0100, Jiri Pirko wrote:
>> Yeah, I can see it now :( I guess that the ship has sailed and we are
>> stuck with this ugly thing forever...
>>
>> Could you at least make some co
Wed, Feb 21, 2018 at 04:56:48PM CET, alexander.du...@gmail.com wrote:
>On Wed, Feb 21, 2018 at 1:51 AM, Jiri Pirko wrote:
>> Tue, Feb 20, 2018 at 11:33:56PM CET, kubak...@wp.pl wrote:
>>>On Tue, 20 Feb 2018 21:14:10 +0100, Jiri Pirko wrote:
>>>> Yeah, I can see it no
Wed, Feb 21, 2018 at 05:49:49PM CET, alexander.du...@gmail.com wrote:
>On Wed, Feb 21, 2018 at 8:11 AM, Jiri Pirko wrote:
>> Wed, Feb 21, 2018 at 04:56:48PM CET, alexander.du...@gmail.com wrote:
>>>On Wed, Feb 21, 2018 at 1:51 AM, Jiri Pirko wrote:
>>>> Tue, Feb 20,
Wed, Feb 21, 2018 at 06:56:35PM CET, alexander.du...@gmail.com wrote:
>On Wed, Feb 21, 2018 at 8:58 AM, Jiri Pirko wrote:
>> Wed, Feb 21, 2018 at 05:49:49PM CET, alexander.du...@gmail.com wrote:
>>>On Wed, Feb 21, 2018 at 8:11 AM, Jiri Pirko wrote:
>>>> Wed,
Wed, Feb 21, 2018 at 09:57:09PM CET, alexander.du...@gmail.com wrote:
>On Wed, Feb 21, 2018 at 11:38 AM, Jiri Pirko wrote:
>> Wed, Feb 21, 2018 at 06:56:35PM CET, alexander.du...@gmail.com wrote:
>>>On Wed, Feb 21, 2018 at 8:58 AM, Jiri Pirko wrote:
>>>> Wed,
Thu, Feb 22, 2018 at 12:54:45PM CET, gerlitz...@gmail.com wrote:
>On Thu, Feb 22, 2018 at 10:11 AM, Jiri Pirko wrote:
>> Wed, Feb 21, 2018 at 09:57:09PM CET, alexander.du...@gmail.com wrote:
>
>>>The signaling isn't too much of an issue since we can just tweak the
Fri, Feb 23, 2018 at 11:22:36PM CET, losewe...@gmail.com wrote:
[...]
>>>
>>> No, that's not what I was talking about of course. I thought you
>>> mentioned the upgrade scenario this patch would like to address is to
>>> use the bypass interface "to take the place of the original virtio,
>>> and
Sat, Feb 24, 2018 at 12:59:04AM CET, step...@networkplumber.org wrote:
>On Thu, 22 Feb 2018 13:30:12 -0800
>Alexander Duyck wrote:
>
>> > Again, I undertand your motivation. Yet I don't like your solution.
>> > But if the decision is made to do this in-driver bonding. I would like
>> > to see it b
Tue, Feb 27, 2018 at 02:18:12AM CET, m...@redhat.com wrote:
>On Mon, Feb 26, 2018 at 05:02:18PM -0800, Stephen Hemminger wrote:
>> On Mon, 26 Feb 2018 08:19:24 +0100
>> Jiri Pirko wrote:
>>
>> > Sat, Feb 24, 2018 at 12:59:04AM CET, step...@networkplumber.org wrote
Tue, Feb 20, 2018 at 05:04:29PM CET, alexander.du...@gmail.com wrote:
>On Tue, Feb 20, 2018 at 2:42 AM, Jiri Pirko wrote:
>> Fri, Feb 16, 2018 at 07:11:19PM CET, sridhar.samudr...@intel.com wrote:
>>>Patch 1 introduces a new feature bit VIRTIO_NET_F_BACKUP that can be
>&g
Tue, Feb 27, 2018 at 10:41:49PM CET, kubak...@wp.pl wrote:
>On Tue, 27 Feb 2018 13:16:21 -0800, Alexander Duyck wrote:
>> Basically we need some sort of PCI or PCIe topology mapping for the
>> devices that can be translated into something we can communicate over
>> the communication channel.
>
>Hm
Wed, Feb 28, 2018 at 03:32:44PM CET, m...@redhat.com wrote:
>On Wed, Feb 28, 2018 at 08:08:39AM +0100, Jiri Pirko wrote:
>> Tue, Feb 27, 2018 at 10:41:49PM CET, kubak...@wp.pl wrote:
>> >On Tue, 27 Feb 2018 13:16:21 -0800, Alexander Duyck wrote:
>> >> Basically we
Wed, Feb 28, 2018 at 04:45:39PM CET, m...@redhat.com wrote:
>On Wed, Feb 28, 2018 at 04:11:31PM +0100, Jiri Pirko wrote:
>> Wed, Feb 28, 2018 at 03:32:44PM CET, m...@redhat.com wrote:
>> >On Wed, Feb 28, 2018 at 08:08:39AM +0100, Jiri Pirko wrote:
>> >> Tue, Feb 27,
Sun, Apr 01, 2018 at 06:11:29PM CEST, dsah...@gmail.com wrote:
>On 4/1/18 3:13 AM, Si-Wei Liu wrote:
>> Hidden netdevice is not visible to userspace such that
>> typical network utilites e.g. ip, ifconfig and et al,
>> cannot sense its existence or configure it. Internally
>> hidden netdev may asso
Wed, Apr 04, 2018 at 03:04:26AM CEST, dsah...@gmail.com wrote:
>On 4/3/18 9:42 AM, Jiri Pirko wrote:
>>>
>>> There are other use cases that want to hide a device from userspace. I
>>
>> What usecases do you have in mind?
>
>As mentioned in a previous resp
Wed, Apr 04, 2018 at 07:37:49PM CEST, da...@davemloft.net wrote:
>From: David Ahern
>Date: Wed, 4 Apr 2018 11:21:54 -0600
>
>> It is a netdev so there is no reason to have a separate ip command to
>> inspect it. 'ip link' is the right place.
>
>I agree on this.
>
>What I really don't understand st
Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@intel.com wrote:
>This patch enables virtio_net to switch over to a VF datapath when a VF
>netdev is present with the same MAC address. It allows live migration
>of a VM with a direct attached VF without the need to setup a bond/team
>between
Thu, Apr 05, 2018 at 11:08:21PM CEST, sridhar.samudr...@intel.com wrote:
>This provides a generic interface for paravirtual drivers to listen
>for netdev register/unregister/link change events from pci ethernet
>devices with the same MAC and takeover their datapath. The notifier and
>event handling
Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudr...@intel.com wrote:
>On 4/6/2018 5:48 AM, Jiri Pirko wrote:
>> Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@intel.com wrote:
[...]
>> > +static int virtnet_bypass_join_child(struct net_dev
Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudr...@intel.com wrote:
>On 4/9/2018 1:07 AM, Jiri Pirko wrote:
>> Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudr...@intel.com wrote:
>> > On 4/6/2018 5:48 AM, Jiri Pirko wrote:
>> > > Thu, Apr 05, 2018 at 1
Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudr...@intel.com wrote:
>On 4/10/2018 3:55 AM, Jiri Pirko wrote:
>> Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudr...@intel.com wrote:
>> > On 4/9/2018 1:07 AM, Jiri Pirko wrote:
>> > > Sat, Apr 07, 2018 at 1
Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudr...@intel.com wrote:
>On 4/10/2018 8:22 AM, Jiri Pirko wrote:
>> Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudr...@intel.com wrote:
>> > On 4/10/2018 3:55 AM, Jiri Pirko wrote:
>> > > Mon, Apr 09, 2018 at 0
Tue, Apr 10, 2018 at 05:59:02PM CEST, sridhar.samudr...@intel.com wrote:
>On 4/10/2018 8:43 AM, Jiri Pirko wrote:
>> Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudr...@intel.com wrote:
>> > On 4/10/2018 8:22 AM, Jiri Pirko wrote:
>> > > Tue, Apr 10, 2018 at 0
Wed, Apr 11, 2018 at 01:28:51AM CEST, m...@redhat.com wrote:
>On Tue, Apr 10, 2018 at 02:26:08PM -0700, Stephen Hemminger wrote:
>> On Tue, 10 Apr 2018 11:59:50 -0700
>> Sridhar Samudrala wrote:
>>
>> > Use the registration/notification framework supported by the generic
>> > bypass infrastructur
Tue, Apr 10, 2018 at 11:26:08PM CEST, step...@networkplumber.org wrote:
>On Tue, 10 Apr 2018 11:59:50 -0700
>Sridhar Samudrala wrote:
>
>> Use the registration/notification framework supported by the generic
>> bypass infrastructure.
>>
>> Signed-off-by: Sridhar Samudrala
>> ---
>
>Thanks for do
Wed, Apr 11, 2018 at 08:24:43AM CEST, sridhar.samudr...@intel.com wrote:
>On 4/10/2018 11:03 PM, Jiri Pirko wrote:
>> Tue, Apr 10, 2018 at 05:59:02PM CEST, sridhar.samudr...@intel.com wrote:
>> > On 4/10/2018 8:43 AM, Jiri Pirko wrote:
>> > > Tue, Apr 10, 2018 at 0
Wed, Apr 11, 2018 at 04:45:07PM CEST, m...@redhat.com wrote:
>On Wed, Apr 11, 2018 at 10:03:32AM +0200, Jiri Pirko wrote:
>> Wed, Apr 11, 2018 at 08:24:43AM CEST, sridhar.samudr...@intel.com wrote:
>> >On 4/10/2018 11:03 PM, Jiri Pirko wrote:
>> >> Tue, A
Tue, Apr 10, 2018 at 08:59:48PM CEST, sridhar.samudr...@intel.com wrote:
>This provides a generic interface for paravirtual drivers to listen
>for netdev register/unregister/link change events from pci ethernet
>devices with the same MAC and takeover their datapath. The notifier and
>event handling
Wed, Apr 11, 2018 at 09:13:52PM CEST, sridhar.samudr...@intel.com wrote:
>On 4/11/2018 8:51 AM, Jiri Pirko wrote:
>> Tue, Apr 10, 2018 at 08:59:48PM CEST, sridhar.samudr...@intel.com wrote:
>> > This provides a generic interface for paravirtual drivers to listen
>> > for
Wed, Apr 18, 2018 at 08:43:15PM CEST, sridhar.samudr...@intel.com wrote:
>On 4/18/2018 2:25 AM, Jiri Pirko wrote:
>> Wed, Apr 11, 2018 at 09:13:52PM CEST, sridhar.samudr...@intel.com wrote:
>> > On 4/11/2018 8:51 AM, Jiri Pirko wrote:
>> > > Tue, Apr 10, 2018 at 0
Wed, Apr 18, 2018 at 09:46:04PM CEST, m...@redhat.com wrote:
>On Wed, Apr 18, 2018 at 09:13:15PM +0200, Jiri Pirko wrote:
>> Wed, Apr 18, 2018 at 08:43:15PM CEST, sridhar.samudr...@intel.com wrote:
>> >On 4/18/2018 2:25 AM, Jiri Pirko wrote:
>> >> Wed, A
Thu, Apr 19, 2018 at 12:46:11AM CEST, sridhar.samudr...@intel.com wrote:
>On 4/18/2018 1:32 PM, Jiri Pirko wrote:
>> > > > > > > You still use "active"/"backup" names which is highly misleading
>> > > > > > > as
>
Thu, Apr 19, 2018 at 06:08:58AM CEST, m...@redhat.com wrote:
>On Wed, Apr 18, 2018 at 10:32:06PM +0200, Jiri Pirko wrote:
>> >> >> > With regards to alternate names for 'active', you suggested
>> >> >> > 'stolen', but i
>>
Fri, Apr 20, 2018 at 05:28:02PM CEST, step...@networkplumber.org wrote:
>On Thu, 19 Apr 2018 18:42:04 -0700
>Sridhar Samudrala wrote:
>
>> Use the registration/notification framework supported by the generic
>> failover infrastructure.
>>
>> Signed-off-by: Sridhar Samudrala
>
>Do what you want t
Mon, Apr 23, 2018 at 07:04:06PM CEST, step...@networkplumber.org wrote:
>On Fri, 20 Apr 2018 18:00:58 +0200
>Jiri Pirko wrote:
>
>> Fri, Apr 20, 2018 at 05:28:02PM CEST, step...@networkplumber.org wrote:
>> >On Thu, 19 Apr 2018 18:42:04 -0700
>> >Sridhar Samud
Fri, Apr 27, 2018 at 07:06:56PM CEST, sridhar.samudr...@intel.com wrote:
>v9:
>Select NET_FAILOVER automatically when VIRTIO_NET/HYPERV_NET
>are enabled. (stephen)
>
>Tested live migration with virtio-net/AVF(i40evf) configured in
>failover mode while running iperf in background.
>Build tested ne
Fri, Apr 27, 2018 at 07:06:58PM CEST, sridhar.samudr...@intel.com wrote:
>This provides a generic interface for paravirtual drivers to listen
>for netdev register/unregister/link change events from pci ethernet
>devices with the same MAC and takeover their datapath. The notifier and
>event handling
Fri, Apr 27, 2018 at 07:53:01PM CEST, sridhar.samudr...@intel.com wrote:
>On 4/27/2018 10:45 AM, Jiri Pirko wrote:
>> Fri, Apr 27, 2018 at 07:06:56PM CEST, sridhar.samudr...@intel.com wrote:
[...]
>>
>> No changes in v9?
>
>I listed v9 updates at the start of the mes
Fri, Apr 27, 2018 at 07:06:57PM CEST, sridhar.samudr...@intel.com wrote:
>This feature bit can be used by hypervisor to indicate virtio_net device to
>act as a standby for another device with the same MAC address.
>
>VIRTIO_NET_F_STANDBY is defined as bit 62 as it is a device feature bit.
>
>Signed
Fri, Apr 27, 2018 at 07:06:58PM CEST, sridhar.samudr...@intel.com wrote:
>This provides a generic interface for paravirtual drivers to listen
>for netdev register/unregister/link change events from pci ethernet
>devices with the same MAC and takeover their datapath. The notifier and
>event handling
Fri, Apr 27, 2018 at 07:06:59PM CEST, sridhar.samudr...@intel.com wrote:
>This patch enables virtio_net to switch over to a VF datapath when a VF
>netdev is present with the same MAC address. It allows live migration
>of a VM with a direct attached VF without the need to setup a bond/team
>between
Fri, Apr 27, 2018 at 07:06:58PM CEST, sridhar.samudr...@intel.com wrote:
>This provides a generic interface for paravirtual drivers to listen
>for netdev register/unregister/link change events from pci ethernet
>devices with the same MAC and takeover their datapath. The notifier and
>event handling
Fri, Apr 27, 2018 at 07:06:59PM CEST, sridhar.samudr...@intel.com wrote:
>This patch enables virtio_net to switch over to a VF datapath when a VF
>netdev is present with the same MAC address. It allows live migration
>of a VM with a direct attached VF without the need to setup a bond/team
>between
Sun, Apr 29, 2018 at 10:56:30AM CEST, losewe...@gmail.com wrote:
>On Sat, Apr 28, 2018 at 2:42 AM, Jiri Pirko wrote:
>> Fri, Apr 27, 2018 at 07:06:59PM CEST, sridhar.samudr...@intel.com wrote:
>>>This patch enables virtio_net to switch over to a VF datapath when a VF
>>>
Mon, Apr 30, 2018 at 04:47:03AM CEST, sridhar.samudr...@intel.com wrote:
>On 4/28/2018 12:50 AM, Jiri Pirko wrote:
>> Fri, Apr 27, 2018 at 07:06:57PM CEST,sridhar.samudr...@intel.com wrote:
>> > This feature bit can be used by hypervisor to indicate virtio_net device to
>>
Mon, Apr 30, 2018 at 05:00:33AM CEST, sridhar.samudr...@intel.com wrote:
>
>On 4/28/2018 1:24 AM, Jiri Pirko wrote:
>> Fri, Apr 27, 2018 at 07:06:59PM CEST, sridhar.samudr...@intel.com wrote:
>> > This patch enables virtio_net to switch over to a VF datapath when a VF
>&g
Mon, Apr 30, 2018 at 06:16:58AM CEST, sridhar.samudr...@intel.com wrote:
>On 4/28/2018 2:42 AM, Jiri Pirko wrote:
>> Fri, Apr 27, 2018 at 07:06:59PM CEST,sridhar.samudr...@intel.com wrote:
>> > This patch enables virtio_net to switch over to a VF datapath when a VF
>> >
Mon, Apr 30, 2018 at 09:26:34PM CEST, sridhar.samudr...@intel.com wrote:
>On 4/30/2018 12:12 AM, Jiri Pirko wrote:
>> Mon, Apr 30, 2018 at 05:00:33AM CEST, sridhar.samudr...@intel.com wrote:
>> > On 4/28/2018 1:24 AM, Jiri Pirko wrote:
>> > > Fri, Apr 27, 2018 at 0
Wed, May 02, 2018 at 02:20:26AM CEST, sridhar.samudr...@intel.com wrote:
>On 4/30/2018 12:20 AM, Jiri Pirko wrote:
>>
>> > > Now I try to change mac of the failover master:
>> > > [root@test1 ~]# ip link set ens3 addr 52:54:00:b2:a7:f3
>> > &g
Wed, May 02, 2018 at 05:47:27PM CEST, m...@redhat.com wrote:
>On Wed, May 02, 2018 at 09:50:21AM +0200, Jiri Pirko wrote:
>> Wed, May 02, 2018 at 02:20:26AM CEST, sridhar.samudr...@intel.com wrote:
>> >On 4/30/2018 12:20 AM, Jiri Pirko wrote:
>> >>
>> &
Wed, May 02, 2018 at 05:34:44PM CEST, sridhar.samudr...@intel.com wrote:
>On 5/2/2018 12:50 AM, Jiri Pirko wrote:
>> Wed, May 02, 2018 at 02:20:26AM CEST, sridhar.samudr...@intel.com wrote:
>> > On 4/30/2018 12:20 AM, Jiri Pirko wrote:
>> > > > > Now I try
Sat, Apr 28, 2018 at 11:06:01AM CEST, j...@resnulli.us wrote:
>Fri, Apr 27, 2018 at 07:06:58PM CEST, sridhar.samudr...@intel.com wrote:
[...]
>>+
>>+ err = netdev_rx_handler_register(slave_dev, net_failover_handle_frame,
>>+ failover_dev);
>>+ if (err
Wed, May 02, 2018 at 07:51:12PM CEST, sridhar.samudr...@intel.com wrote:
>
>
>On 5/2/2018 9:15 AM, Jiri Pirko wrote:
>> Sat, Apr 28, 2018 at 11:06:01AM CEST, j...@resnulli.us wrote:
>> > Fri, Apr 27, 2018 at 07:06:58PM CEST, sridhar.s
Wed, May 02, 2018 at 07:51:12PM CEST, sridhar.samudr...@intel.com wrote:
>
>
>On 5/2/2018 9:15 AM, Jiri Pirko wrote:
>> Sat, Apr 28, 2018 at 11:06:01AM CEST, j...@resnulli.us wrote:
>> > Fri, Apr 27, 2018 at 07:06:58PM CEST, sridhar.s
Tue, May 22, 2018 at 04:06:19AM CEST, sridhar.samudr...@intel.com wrote:
>The net_failover driver provides an automated failover mechanism via APIs
>to create and destroy a failover master netdev and mananges a primary and
>standby slave netdevs that get registered via the generic failover
>infrast
Tue, May 22, 2018 at 04:06:18AM CEST, sridhar.samudr...@intel.com wrote:
>Use the registration/notification framework supported by the generic
>failover infrastructure.
>
>Signed-off-by: Sridhar Samudrala
In previous patchset versions, the common code did
netdev_rx_handler_register() and netdev_u
Tue, May 22, 2018 at 11:06:37AM CEST, j...@resnulli.us wrote:
>Tue, May 22, 2018 at 04:06:18AM CEST, sridhar.samudr...@intel.com wrote:
>>Use the registration/notification framework supported by the generic
>>failover infrastructure.
>>
>>Signed-off-by: Sridhar Samudrala
>
>In previous patchset ve
Tue, May 22, 2018 at 03:12:40PM CEST, m...@redhat.com wrote:
>On Tue, May 22, 2018 at 11:08:53AM +0200, Jiri Pirko wrote:
>> Tue, May 22, 2018 at 11:06:37AM CEST, j...@resnulli.us wrote:
>> >Tue, May 22, 2018 at 04:06:18AM CEST, sridhar.samudr...@intel.com wrote:
>>
Tue, May 22, 2018 at 03:17:37PM CEST, m...@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, m...@redhat.com wrote:
>> >On Tue, May 22, 2018 at 11:08:53AM +0200, Jiri Pirko wrote:
>> >> Tue, May
Tue, May 22, 2018 at 03:39:33PM CEST, m...@redhat.com wrote:
>On Tue, May 22, 2018 at 03:26:26PM +0200, Jiri Pirko wrote:
>> Tue, May 22, 2018 at 03:17:37PM CEST, m...@redhat.com wrote:
>> >On Tue, May 22, 2018 at 03:14:22PM +0200, Jiri Pirko wrote:
>> >> Tue, May
Tue, May 22, 2018 at 05:28:42PM CEST, sridhar.samudr...@intel.com wrote:
>
>On 5/22/2018 2:08 AM, Jiri Pirko wrote:
>> Tue, May 22, 2018 at 11:06:37AM CEST, j...@resnulli.us wrote:
>> > Tue, May 22, 2018 at 04:06:18AM CEST, sridhar.samudr...@intel.com wrote:
>&g
Tue, May 22, 2018 at 05:32:30PM CEST, m...@redhat.com wrote:
>On Tue, May 22, 2018 at 05:13:43PM +0200, Jiri Pirko wrote:
>> Tue, May 22, 2018 at 03:39:33PM CEST, m...@redhat.com wrote:
>> >On Tue, May 22, 2018 at 03:26:26PM +0200, Jiri Pirko wrote:
>> >> Tue, May
Fixing the subj, sorry about that.
Tue, May 22, 2018 at 05:46:21PM CEST, m...@redhat.com wrote:
>On Tue, May 22, 2018 at 05:36:14PM +0200, Jiri Pirko wrote:
>> Tue, May 22, 2018 at 05:28:42PM CEST, sridhar.samudr...@intel.com wrote:
>> >
>> >On 5/22/2018 2:08 AM, Jiri
Tue, May 22, 2018 at 06:52:21PM CEST, m...@redhat.com wrote:
>On Tue, May 22, 2018 at 05:45:01PM +0200, Jiri Pirko wrote:
>> Tue, May 22, 2018 at 05:32:30PM CEST, m...@redhat.com wrote:
>> >On Tue, May 22, 2018 at 05:13:43PM +0200, Jiri Pirko wrote:
>> >> Tue, May
Tue, May 22, 2018 at 10:54:29PM CEST, sridhar.samudr...@intel.com wrote:
>
>
>On 5/22/2018 9:12 AM, Jiri Pirko wrote:
>> Fixing the subj, sorry about that.
>>
>> Tue, May 22, 2018 at 05:46:21PM CEST, m...@redhat.com wrote:
>> > On Tue, May 22, 2018 a
Sat, May 26, 2018 at 12:37:44AM CEST, step...@networkplumber.org wrote:
>On Thu, 24 May 2018 09:55:13 -0700
>Sridhar Samudrala wrote:
>
>
>> +spin_lock(&failover_lock);
>
>Since register is not in fast path, this should be a mutex?
I don't get it. Why would you prefer mutex over spinlock here
Sat, May 26, 2018 at 09:22:18AM CEST, sridhar.samudr...@intel.com wrote:
>On 5/25/2018 4:28 PM, Stephen Hemminger wrote:
>> On Fri, 25 May 2018 16:11:47 -0700
>> "Samudrala, Sridhar" wrote:
>>
>> > On 5/25/2018 3:34 PM, Stephen Hemminger wrote:
>> > > On Thu, 24 May 2018 09:55:14 -0700
>> > > Sri
Sat, Jan 30, 2016 at 07:59:24AM CET, da...@davemloft.net wrote:
>From: Nikolay Aleksandrov
>Date: Fri, 29 Jan 2016 22:48:26 +0100
>
>> On 01/29/2016 10:45 PM, Jay Vosburgh wrote:
>>> Nikolay Aleksandrov wrote:
>>>
On 01/25/2016 05:24 PM, Bjørnar Ness wrote:
> As subject says, 802.3ad bo
Signed-off-by: Jiri Pirko
---
drivers/net/virtio_net.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index f18149a..36a16d5 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -679,11
Thu, Jun 28, 2012 at 06:30:46AM CEST, da...@davemloft.net wrote:
>From: Jiri Pirko
>Date: Wed, 27 Jun 2012 17:27:46 +0200
>
>> Signed-off-by: Jiri Pirko
>
>Applied, but this seriously makes eth_mac_addr() completely useless.
>
>Technically, every eth_mac_addr() user i
Introduce IFF_LIFE_ADDR_CHANGE priv_flag and use it to disable
netif_running() check in eth_mac_addr()
Signed-off-by: Jiri Pirko
---
include/linux/if.h |2 ++
net/ethernet/eth.c |2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/if.h b/include/linux/if.h
three drivers updated, but this can be used in many others.
Jiri Pirko (4):
net: introduce new priv_flag indicating iface capable of change mac
when running
virtio_net: use IFF_LIFE_ADDR_CHANGE priv_flag
team: use IFF_LIFE_ADDR_CHANGE priv_flag
dummy: use IFF_LIFE_ADDR_CHANGE
Signed-off-by: Jiri Pirko
---
drivers/net/virtio_net.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 36a16d5..6a0f526 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -679,12
Signed-off-by: Jiri Pirko
---
drivers/net/team/team.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 5350eea..019d658 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1188,10 +1188,11
Signed-off-by: Jiri Pirko
---
drivers/net/dummy.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
index bab0158..0352246 100644
--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c
@@ -40,18 +40,6 @@
static int
1 - 100 of 107 matches
Mail list logo
