All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rocco Yue <rocco.yue@mediatek.com>
To: David Ahern <dsahern@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>, <rocco.yue@gmail.com>,
	<chao.song@mediatek.com>, <zhuoliang.zhang@mediatek.com>,
	Rocco Yue <rocco.yue@mediatek.com>
Subject: Re: [PATCH net-next v3] ipv6: add IFLA_INET6_RA_MTU to expose mtu value in the RA message
Date: Fri, 13 Aug 2021 16:07:40 +0800	[thread overview]
Message-ID: <20210813080740.31571-1-rocco.yue@mediatek.com> (raw)
In-Reply-To: <4624cc10-1fc8-12cd-e9e1-9585f5b496a0@gmail.com>

On Wed, 2021-08-11 at 12:05 -0600, David Ahern wrote:
> On 8/11/21 7:56 AM, David Ahern wrote:
>> On 8/10/21 6:33 AM, Rocco Yue wrote:
>>> On Mon, 2021-08-09 at 16:43 -0600, David Ahern wrote:
>>>>
>>>> Since this MTU is getting reported via af_info infrastructure,
>>>> rtmsg_ifinfo should be sufficient.
>>>>
>>>> From there use 'ip monitor' to make sure you are not generating multiple
>>>> notifications; you may only need this on the error path.
>>>
>>> Hi David,
>>>
>>> To avoid generating multiple notifications, I added a separate ramtu notify
>>> function in this patch, and I added RTNLGRP_IPV6_IFINFO nl_mgrp to the ipmonitor.c
>>> to verify this patch was as expected.
>>>
>>> I look at the rtmsg_ifinfo code, it should be appropriate and I will use it and
>>> verify it.
>>>
>>> But there's one thing, I'm sorry I didn't fully understand the meaning of this
>>> sentence "you may only need this on the error path". Honestly, I'm not sure what
>>> the error patch refers to, do you mean "if (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu)" ?
>>>
>> 
>> looks like nothing under:
>>     if (ndopts.nd_opts_mtu && in6_dev->cnf.accept_ra_mtu) {
>> 
>>     }
>> 
>> is going to send a link notification so you can just replace
>> inet6_iframtu_notify with rtmsg_ifinfo in your proposed change.
>> 
> 
> Taking a deeper dive on the code, you do not need to call rtmsg_ifinfo.
> Instead, the existing:
> 
>         /*
>          *      Send a notify if RA changed managed/otherconf flags or
> timer settings
>          */
>         if (send_ifinfo_notify)
>                 inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
> 
> is called too early. For one the RA can change the MTU and that is done
> after this notify.
> 
> I think if you moved this down to the out:
> 
> out:
>         /*
>          *      Send a notify if RA changed managed/otherconf flags or
> timer settings
>          */
>         if (send_ifinfo_notify)
>                 inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
> 
> and then set send_ifinfo_notify when the mtu is *changed* by the RA you
> should be good.

Hi David,

Thanks for your suggestion,
this looks like a better choice without adding a separate notification function,
I will modify it and push the next iteration .

Best Regards,
Rocco

WARNING: multiple messages have this Message-ID (diff)
From: Rocco Yue <rocco.yue@mediatek.com>
To: David Ahern <dsahern@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,  <rocco.yue@gmail.com>,
	<chao.song@mediatek.com>, <zhuoliang.zhang@mediatek.com>,
	Rocco Yue <rocco.yue@mediatek.com>
Subject: Re: [PATCH net-next v3] ipv6: add IFLA_INET6_RA_MTU to expose mtu value in the RA message
Date: Fri, 13 Aug 2021 16:07:40 +0800	[thread overview]
Message-ID: <20210813080740.31571-1-rocco.yue@mediatek.com> (raw)
In-Reply-To: <4624cc10-1fc8-12cd-e9e1-9585f5b496a0@gmail.com>

On Wed, 2021-08-11 at 12:05 -0600, David Ahern wrote:
> On 8/11/21 7:56 AM, David Ahern wrote:
>> On 8/10/21 6:33 AM, Rocco Yue wrote:
>>> On Mon, 2021-08-09 at 16:43 -0600, David Ahern wrote:
>>>>
>>>> Since this MTU is getting reported via af_info infrastructure,
>>>> rtmsg_ifinfo should be sufficient.
>>>>
>>>> From there use 'ip monitor' to make sure you are not generating multiple
>>>> notifications; you may only need this on the error path.
>>>
>>> Hi David,
>>>
>>> To avoid generating multiple notifications, I added a separate ramtu notify
>>> function in this patch, and I added RTNLGRP_IPV6_IFINFO nl_mgrp to the ipmonitor.c
>>> to verify this patch was as expected.
>>>
>>> I look at the rtmsg_ifinfo code, it should be appropriate and I will use it and
>>> verify it.
>>>
>>> But there's one thing, I'm sorry I didn't fully understand the meaning of this
>>> sentence "you may only need this on the error path". Honestly, I'm not sure what
>>> the error patch refers to, do you mean "if (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu)" ?
>>>
>> 
>> looks like nothing under:
>>     if (ndopts.nd_opts_mtu && in6_dev->cnf.accept_ra_mtu) {
>> 
>>     }
>> 
>> is going to send a link notification so you can just replace
>> inet6_iframtu_notify with rtmsg_ifinfo in your proposed change.
>> 
> 
> Taking a deeper dive on the code, you do not need to call rtmsg_ifinfo.
> Instead, the existing:
> 
>         /*
>          *      Send a notify if RA changed managed/otherconf flags or
> timer settings
>          */
>         if (send_ifinfo_notify)
>                 inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
> 
> is called too early. For one the RA can change the MTU and that is done
> after this notify.
> 
> I think if you moved this down to the out:
> 
> out:
>         /*
>          *      Send a notify if RA changed managed/otherconf flags or
> timer settings
>          */
>         if (send_ifinfo_notify)
>                 inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
> 
> and then set send_ifinfo_notify when the mtu is *changed* by the RA you
> should be good.

Hi David,

Thanks for your suggestion,
this looks like a better choice without adding a separate notification function,
I will modify it and push the next iteration .

Best Regards,
Rocco
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Rocco Yue <rocco.yue@mediatek.com>
To: David Ahern <dsahern@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,  <rocco.yue@gmail.com>,
	<chao.song@mediatek.com>, <zhuoliang.zhang@mediatek.com>,
	Rocco Yue <rocco.yue@mediatek.com>
Subject: Re: [PATCH net-next v3] ipv6: add IFLA_INET6_RA_MTU to expose mtu value in the RA message
Date: Fri, 13 Aug 2021 16:07:40 +0800	[thread overview]
Message-ID: <20210813080740.31571-1-rocco.yue@mediatek.com> (raw)
In-Reply-To: <4624cc10-1fc8-12cd-e9e1-9585f5b496a0@gmail.com>

On Wed, 2021-08-11 at 12:05 -0600, David Ahern wrote:
> On 8/11/21 7:56 AM, David Ahern wrote:
>> On 8/10/21 6:33 AM, Rocco Yue wrote:
>>> On Mon, 2021-08-09 at 16:43 -0600, David Ahern wrote:
>>>>
>>>> Since this MTU is getting reported via af_info infrastructure,
>>>> rtmsg_ifinfo should be sufficient.
>>>>
>>>> From there use 'ip monitor' to make sure you are not generating multiple
>>>> notifications; you may only need this on the error path.
>>>
>>> Hi David,
>>>
>>> To avoid generating multiple notifications, I added a separate ramtu notify
>>> function in this patch, and I added RTNLGRP_IPV6_IFINFO nl_mgrp to the ipmonitor.c
>>> to verify this patch was as expected.
>>>
>>> I look at the rtmsg_ifinfo code, it should be appropriate and I will use it and
>>> verify it.
>>>
>>> But there's one thing, I'm sorry I didn't fully understand the meaning of this
>>> sentence "you may only need this on the error path". Honestly, I'm not sure what
>>> the error patch refers to, do you mean "if (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu)" ?
>>>
>> 
>> looks like nothing under:
>>     if (ndopts.nd_opts_mtu && in6_dev->cnf.accept_ra_mtu) {
>> 
>>     }
>> 
>> is going to send a link notification so you can just replace
>> inet6_iframtu_notify with rtmsg_ifinfo in your proposed change.
>> 
> 
> Taking a deeper dive on the code, you do not need to call rtmsg_ifinfo.
> Instead, the existing:
> 
>         /*
>          *      Send a notify if RA changed managed/otherconf flags or
> timer settings
>          */
>         if (send_ifinfo_notify)
>                 inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
> 
> is called too early. For one the RA can change the MTU and that is done
> after this notify.
> 
> I think if you moved this down to the out:
> 
> out:
>         /*
>          *      Send a notify if RA changed managed/otherconf flags or
> timer settings
>          */
>         if (send_ifinfo_notify)
>                 inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
> 
> and then set send_ifinfo_notify when the mtu is *changed* by the RA you
> should be good.

Hi David,

Thanks for your suggestion,
this looks like a better choice without adding a separate notification function,
I will modify it and push the next iteration .

Best Regards,
Rocco
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-08-13  8:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-09 14:01 [PATCH net-next v3] ipv6: add IFLA_INET6_RA_MTU to expose mtu value in the RA message Rocco Yue
2021-08-09 14:01 ` Rocco Yue
2021-08-09 14:01 ` Rocco Yue
2021-08-09 20:53 ` Jakub Kicinski
2021-08-09 20:53   ` Jakub Kicinski
2021-08-09 20:53   ` Jakub Kicinski
2021-08-09 22:43 ` David Ahern
2021-08-09 22:43   ` David Ahern
2021-08-09 22:43   ` David Ahern
2021-08-10 12:33   ` Rocco Yue
2021-08-10 12:33     ` Rocco Yue
2021-08-10 12:33     ` Rocco Yue
2021-08-11 13:56     ` David Ahern
2021-08-11 13:56       ` David Ahern
2021-08-11 13:56       ` David Ahern
2021-08-11 18:05       ` David Ahern
2021-08-11 18:05         ` David Ahern
2021-08-11 18:05         ` David Ahern
2021-08-13  8:07         ` Rocco Yue [this message]
2021-08-13  8:07           ` Rocco Yue
2021-08-13  8:07           ` Rocco Yue

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=20210813080740.31571-1-rocco.yue@mediatek.com \
    --to=rocco.yue@mediatek.com \
    --cc=chao.song@mediatek.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=dsahern@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=rocco.yue@gmail.com \
    --cc=yoshfuji@linux-ipv6.org \
    --cc=zhuoliang.zhang@mediatek.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.