Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752717AbdDDCTW (ORCPT <rfc822;w@1wt.eu>);
        Mon, 3 Apr 2017 22:19:22 -0400
Received: from shards.monkeyblade.net ([184.105.139.130]:53356 "EHLO
        shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752556AbdDDCTV (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 3 Apr 2017 22:19:21 -0400
Date: Mon, 03 Apr 2017 19:19:19 -0700 (PDT)
Message-Id: <20170403.191919.732158650374501762.davem@davemloft.net>
To: parameswaran.r7@gmail.com
Cc: jchapman@katalix.com, kleptog@svana.org, nprachan@brocade.com,
        rshearma@brocade.com, stephen@networkplumber.org, sdietric@brocade.com,
        ciwillia@brocade.com, lboccass@brocade.com, dfawcus@brocade.com,
        bhong@brocade.com, jblunck@brocade.com, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org
Subject: Re: [PATCH net-next v4 1/2] New kernel function to get IP overhead
 on a socket.
From: David Miller <davem@davemloft.net>
In-Reply-To: <alpine.DEB.2.11.1704031906060.6985@vera100.eng.brocade.com>
References: <alpine.DEB.2.11.1704031316390.24947@vera100.eng.brocade.com>
        <20170403.133040.2079781719239791612.davem@davemloft.net>
        <alpine.DEB.2.11.1704031906060.6985@vera100.eng.brocade.com>
X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Mon, 03 Apr 2017 18:38:04 -0700 (PDT)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1053
Lines: 31

From: "R. Parameswaran" <parameswaran.r7@gmail.com>
Date: Mon, 3 Apr 2017 19:12:20 -0700 (PDT)

> 
> 
> Hi Dave,
> 
> Please see inline:
> 
> On Mon, 3 Apr 2017, David Miller wrote:
> 
>> From: "R. Parameswaran" <parameswaran.r7@gmail.com>
>> Date: Mon, 3 Apr 2017 13:28:11 -0700 (PDT)
>> 
>> > Can I take this to mean that we do need to factor in IP options in 
>> > the L2TP device MTU setup (i.e approach in the posted patch is okay)? 
>> > 
>> > If yes, please let me know if I can keep the socket IP option overhead 
>> > calculations in a generic function, or it would be better to move it back into 
>> > L2TP code? 
>> 
>> If the user creates and maintains this UDP socket, then yes we have to
>> account for potential IP options.
>> 
> 
> Can I take this to mean that the patch in its present form is 
> acceptable (patch currently accounts for IP options on the socket)? 
> Please let me know if any further change is needed (I'll clean up the 
> krobot reported errors after this).

Yes, please respin the patch with the krobot errors fixed.