From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751944AbdDCUap (ORCPT <rfc822;w@1wt.eu>);
        Mon, 3 Apr 2017 16:30:45 -0400
Received: from shards.monkeyblade.net ([184.105.139.130]:49718 "EHLO
        shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751210AbdDCUao (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 3 Apr 2017 16:30:44 -0400
Date: Mon, 03 Apr 2017 13:30:40 -0700 (PDT)
Message-Id: <20170403.133040.2079781719239791612.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.1704031316390.24947@vera100.eng.brocade.com>
References: <alpine.DEB.2.11.1703231809410.19388@vera100.eng.brocade.com>
        <14517769-bf88-a541-4948-1504a6d7acac@katalix.com>
        <alpine.DEB.2.11.1704031316390.24947@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 12:49:27 -0700 (PDT)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.