From: David Miller <davem@davemloft.net>
To: jakub.kicinski@netronome.com
Cc: netdev@vger.kernel.org, simon.horman@netronome.com,
rolf.neugebauer@netronome.com
Subject: Re: [PATCHv2 net-next 0/4] MTU changes and other fixes
Date: Thu, 07 Jan 2016 16:33:14 -0500 (EST) [thread overview]
Message-ID: <20160107.163314.666536912327323086.davem@davemloft.net> (raw)
In-Reply-To: <20160107204928.0cd91c16@jkicinski-Precision-T1700>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Thu, 7 Jan 2016 20:49:28 +0000
> 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.
> All drivers I've seen ...
Bad practice in other drivers should be ignored, not copied.
next prev parent reply other threads:[~2016-01-07 21:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-05 11:57 [PATCHv2 net-next 0/4] MTU changes and other fixes Jakub Kicinski
2016-01-05 11:57 ` [PATCHv2 net-next 1/4] nfp: return error if MTU change fails Jakub Kicinski
2016-01-05 11:57 ` [PATCHv2 net-next 2/4] nfp: free buffers before changing MTU Jakub Kicinski
2016-01-05 11:57 ` [PATCHv2 net-next 3/4] nfp: correct RX buffer length calculation Jakub Kicinski
2016-01-05 11:57 ` [PATCHv2 net-next 4/4] nfp: fix RX buffer length validation Jakub Kicinski
2016-01-07 19:57 ` [PATCHv2 net-next 0/4] MTU changes and other fixes David Miller
2016-01-07 20:49 ` Jakub Kicinski
2016-01-07 21:33 ` David Miller [this message]
2016-01-07 21:50 ` Jakub Kicinski
2016-01-07 21:55 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160107.163314.666536912327323086.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=jakub.kicinski@netronome.com \
--cc=netdev@vger.kernel.org \
--cc=rolf.neugebauer@netronome.com \
--cc=simon.horman@netronome.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).