[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160224071527.GA2151@nanopsycho.orion>
Date: Wed, 24 Feb 2016 08:15:27 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: Hannes Frederic Sowa <hannes@...essinduktion.org>,
netdev@...r.kernel.org, davem@...emloft.net, idosch@...lanox.com,
eladr@...lanox.com, yotamg@...lanox.com, ogerlitz@...lanox.com,
yishaih@...lanox.com, dledford@...hat.com, sean.hefty@...el.com,
hal.rosenstock@...il.com, eugenia@...lanox.com,
roopa@...ulusnetworks.com, nikolay@...ulusnetworks.com,
hadarh@...lanox.com, jhs@...atatu.com, john.fastabend@...il.com,
jeffrey.t.kirsher@...el.com, brouer@...hat.com, ivecera@...hat.com,
rami.rosen@...el.com
Subject: Re: [patch net-next 3/9] mlx4: Implement port type setting via
devlink interface
Tue, Feb 23, 2016 at 06:31:39PM CET, stephen@...workplumber.org wrote:
>On Tue, 23 Feb 2016 12:26:00 +0100
>Hannes Frederic Sowa <hannes@...essinduktion.org> wrote:
>
>> Hi Jiri,
>>
>> On 22.02.2016 19:31, Jiri Pirko wrote:
>> > From: Jiri Pirko <jiri@...lanox.com>
>> >
>> > So far, there has been an mlx4-specific sysfs file allowing user to
>> > change port type to either Ethernet of InfiniBand. This is very
>> > inconvenient.
>>
>> Again, I want to express my concerns regarding all of this until this
>> will be integrated into udev/systemd for stable device names. While one
>> can build wrapper code around devlink to have stable devlink ports, I
>> don't see a reason to include kernel code which actually has more
>> problems than the sysfs approach. This harms admins to use those devices
>> and will additionally require user space to write boiler plate code.
>>
>> Thanks,
>> Hannes
>>
>
>I appreciate that you need to have a lighterweight model for
>network devices. But have to agree with Hannes.
No, I don't need to have lighterweight model for network device. This
patch does nothing like that.
>
>This code breaks the model expected by applications like Quagga, SNMP
>and lots of other legacy code. Is this really going to work with the
>legacy Linux model.
No, this patch does not break anything. The original netdev still stay.
Powered by blists - more mailing lists