netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 14:57:50 -0500 (EST)	[thread overview]
Message-ID: <20160107.145750.213741381921685070.davem@davemloft.net> (raw)
In-Reply-To: <1451995051-21920-1-git-send-email-jakub.kicinski@netronome.com>

From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Tue,  5 Jan 2016 11:57:27 +0000

> v2:
>  - add first patch (return error on fail).

You didn't read my feedback, so I'm not going to read your patches.

Is that OK with you?  I personally think it's fair.

I said that you need to reorganize how you do the MTU
changes.

You _MUST_ try to allocate the resources (queues, data
structures, whatever) for the new MTU size.

And if that fails, release those new resources and leave
the device exactly in the state it was in prior to the MTU
change call.

This means you can't use the close/open scheme, I'm explicitly
telling you not to use that mechanism to change the MTU because
it can leave the device inoperative if the re-open fails.

That is completely unexpected behavior for the user.

The interface must remain up and functioning at the original
MTU if the MTU change operation fails.  Your code does not
do this.

Yes, this is a lot of more work, but that's the only correct
way to implement this.

If you fail to implement this properly one more time I will start
simply ignoring your patch submissions for a while because you will be
completely wasting my time.

Thanks.

  parent reply	other threads:[~2016-01-07 19:57 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 ` David Miller [this message]
2016-01-07 20:49   ` [PATCHv2 net-next 0/4] MTU changes and other fixes Jakub Kicinski
2016-01-07 21:33     ` David Miller
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.145750.213741381921685070.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).