Thread (10 messages) flat view 10 messages, 2 authors, 2016-01-07

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

From: Jakub Kicinski <hidden>
Date: 2016-01-07 21:50:16

On Thu, 07 Jan 2016 16:33:14 -0500 (EST), David Miller wrote:
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.
quoted
All drivers I've seen ...
Bad practice in other drivers should be ignored, not copied.
I'll take that to heart.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help