[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALzJLG8ieHkdGf9xhYOzKA3dRgR6ROFUd6=t4McHJM+XmX+WwQ@mail.gmail.com>
Date: Sat, 30 Apr 2016 00:14:00 +0300
From: Saeed Mahameed <saeedm@....mellanox.co.il>
To: David Miller <davem@...emloft.net>
Cc: Saeed Mahameed <saeedm@...lanox.com>,
Linux Netdev List <netdev@...r.kernel.org>,
Or Gerlitz <ogerlitz@...lanox.com>,
Tal Alon <talal@...lanox.com>,
Eran Ben Elisha <eranbe@...lanox.com>
Subject: Re: [PATCH net-next V1 00/11] Mellanox 100G extending mlx5 ethtool support
On Fri, Apr 29, 2016 at 11:34 PM, David Miller <davem@...emloft.net> wrote:
> From: Saeed Mahameed <saeedm@....mellanox.co.il>
> Date: Fri, 29 Apr 2016 23:27:06 +0300
>
>> but my concerns is when features A and B requires firmware commands A then B
>> and firmware command B fails, there is no gurantee that roll back for
>> firmware command A will work.
>>
>> this is why in case of B fails we keep the state (new A and prev B)
>> rather than try to go back to (prev A and prev B).
>
> That's a limitation of your firmware I would say.
>
> Users do not expect the semantics you will be providing, if "change A and B"
> fails both states must not be changed.
>
> This is an unwavering requirement, you must do everything you can to
> meet that expection.
>
> You cannot say "our firmware does this so, you might get partial
> updates." That simply is not acceptable.
Got it, we'll revisit this area of code and make meet the requirement.
Thank you Dave.
Powered by blists - more mailing lists