Re: [PATCHv2 net-next 0/4] MTU changes and other fixes

From: Jakub Kicinski <redacted>
Date: Thu, 7 Jan 2016 21:50:11 +0000

On Thu, 07 Jan 2016 16:33:14 -0500 (EST), David Miller wrote:

quoted

From: Jakub Kicinski <redacted>
Date: Thu, 7 Jan 2016 20:49:28 +0000

quoted

I know this is not what you asked for but, since we are using FW
commands to disable/enable RX, even if we allocate all required
resources before freeing old ones we still cannot guarantee that
the reenabling operation will not fail.  Should we refuse to do
MTU changes while the interface is running altogether?

If you issue the MTU change command and it fails, then you're still
configured at the old MTU.  There should therefore be no problem
rewinding in that case.

No, no...  The FW command is to stop and start the RX path in
the NIC.  Our NIC is NPU-based, it has a ton of programmability
so even though we try to make it work like a run-of-the-mill
NIC there are some gotchas.

Unless there is a way to change MTU without stopping RX which
escapes me.

Then the best you can do is retry the FW configuration using the
original MTU, and if _that_ fails you must return and error as well as
emit a kernel log message because this is a failure that cannot be
recovered from and the user must be able to figure out what happened.