From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,MIME_BASE64_TEXT,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19F94C4338F for ; Mon, 2 Aug 2021 03:36:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E1ACF60E97 for ; Mon, 2 Aug 2021 03:36:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232025AbhHBDgN (ORCPT ); Sun, 1 Aug 2021 23:36:13 -0400 Received: from Mailgw01.mediatek.com ([1.203.163.78]:1842 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S231361AbhHBDgK (ORCPT ); Sun, 1 Aug 2021 23:36:10 -0400 X-UUID: 646c5d5928024c22a2ad7045ea5aa7fb-20210802 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=ZK3e9Sg7ghuyh77VEHKTRyGoBtj/73rumt2QQW4OnHM=; b=I1sTjCKmkm3Pr3FQlnuF3fvH+3ffvbvnfU5jGUKMMyBKeEdvjbffWFmT0UgOc54aN3XB7mcpmbzdf9zdyu+YuZEAVI6qqmyHdgzzoMPKPRmvbbSD5UkRGPBsZDEaGvxPLXYQDRA3yioZUN31DLcaQpYvdULWrdjJh7q5kQuNep0=; X-UUID: 646c5d5928024c22a2ad7045ea5aa7fb-20210802 Received: from mtkcas35.mediatek.inc [(172.27.4.253)] by mailgw01.mediatek.com (envelope-from ) (mailgw01.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1405854002; Mon, 02 Aug 2021 11:35:56 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by MTKMBS32N1.mediatek.inc (172.27.4.71) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 2 Aug 2021 11:35:49 +0800 Received: from localhost.localdomain (10.15.20.246) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 2 Aug 2021 11:35:48 +0800 From: Rocco Yue To: David Ahern CC: "David S . Miller" , Jakub Kicinski , Hideaki YOSHIFUJI , , , , , , , , Rocco Yue Subject: Re: [PATCH net-next v2] ipv6: add IFLA_INET6_RA_MTU to expose mtu value in the RA message Date: Mon, 2 Aug 2021 11:19:24 +0800 Message-ID: <20210802031924.3256-1-rocco.yue@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <5be90cf4-f603-c2f2-fd7e-3886854457ba@gmail.com> References: <5be90cf4-f603-c2f2-fd7e-3886854457ba@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-TM-SNTS-SMTP: 717DC6BBB0EEBCBF51C02B29FAF02E489CDAC93F80059C78A30F86F824E5FC2D2000:8 X-MTK: N Content-Transfer-Encoding: base64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org T24gU2F0LCAyMDIxLTA3LTMxIGF0IDExOjE3IC0wNjAwLCBEYXZpZCBBaGVybiB3cm90ZToNCk9u IDcvMzAvMjEgNzo1MiBQTSwgUm9jY28gWXVlIHdyb3RlOg0KPj4gSW4gdGhpcyB3YXksIGlmIHRo ZSBNVFUgdmFsdWVzIHRoYXQgdGhlIGRldmljZSByZWNlaXZlcyBmcm9tDQo+PiB0aGUgbmV0d29y ayBpbiB0aGUgUENPIElQdjQgYW5kIHRoZSBSQSBJUHY2IHByb2NlZHVyZXMgYXJlDQo+PiBkaWZm ZXJlbnQsIHRoZSB1c2VyIHNwYWNlIHByb2Nlc3MgY2FuIHJlYWQgcmFfbXR1IHRvIGdldA0KPj4g dGhlIG10dSB2YWx1ZSBjYXJyaWVkIGluIHRoZSBSQSBtZXNzYWdlIHdpdGhvdXQgd29ycnlpbmcN Cj4+IGFib3V0IHRoZSBpc3N1ZSBvZiBpcHY0IGJlaW5nIHN0dWNrIGR1ZSB0byB0aGUgbGF0ZSBh cnJpdmFsDQo+PiBvZiBSQSBtZXNzYWdlLiBBZnRlciBjb21wYXJpbmcgdGhlIHZhbHVlIG9mIHJh X210dSBhbmQgaXB2NA0KPj4gbXR1LCB0aGVuIHRoZSBkZXZpY2UgY2FuIHVzZSB0aGUgbG93ZXIg TVRVIHZhbHVlIGZvciBib3RoDQo+PiBJUHY0IGFuZCBJUHY2Lg0KPiANCj4geW91IGFyZSBzdG9y aW5nIHRoZSB2YWx1ZSBhbmQgc2VuZGluZyB0byB1c2Vyc3BhY2UgYnV0IG5ldmVyIHVzaW5nIGl0 DQo+IHdoZW4gc2VuZGluZyBhIG1lc3NhZ2UuIFdoYXQncyB0aGUgcG9pbnRpbmcgb2YgcHJvY2Vz c2luZyB0aGUgTVRVIGluIHRoZQ0KPiBSQSBpZiB5b3UgYXJlIG5vdCBnb2luZyB0byB1c2UgaXQg dG8gY29udHJvbCBtZXNzYWdlIHNpemU/DQoNCkhpIERhdmlkLA0KDQpJbiB0aGUgcmVxdWlyZW1l bnQgb2YgbW9iaWxlIG9wZXJhdG9yIGF0JnQgaW4gMjAyMToNCkFUJlQgPENEUi1DRFMtMTE2PiBQ cmlvcml0aXplIExvd2VyIE1UVSB2YWx1ZToNCklmIHRoZSBNVFUgdmFsdWVzIHRoYXQgdGhlIGRl dmljZSByZWNlaXZlcyBmcm9tIHRoZSBuZXR3b3JrIGluIHRoZSBQQ08NCklQdjQgPENEUi1DRFMt MTEwPiBhbmQgdGhlIFJBIElQdjYgPENEUi1DRFMtMTEyPiBwcm9jZWR1cmVzIGFyZSBkaWZmZXJl bnQsDQp0aGVuIHRoZSBkZXZpY2Ugc2hhbGwgdXNlIHRoZSBsb3dlciBNVFUgdmFsdWUgZm9yIGJv dGggSVB2NCBhbmQgSVB2Ni4NCg0KQW5kIGluIHRoZSAzR1BQIDIzLjA2MDoNClRoZSBQRFAgUERV cyBzaGFsbCBiZSByb3V0ZWQgYW5kIHRyYW5zZmVycmVkIGJldHdlZW4gdGhlIE1TIGFuZCB0aGUg R0dTTg0Kb3IgUC1HVyBhcyBOLVBEVXMuIEluIG9yZGVyIHRvIGF2b2lkIElQIGxheWVyIGZyYWdt ZW50YXRpb24gYmV0d2VlbiB0aGUNCk1TIGFuZCB0aGUgR0dTTiBvciBQLUdXLCB0aGUgbGluayBN VFUgc2l6ZSBpbiB0aGUgTVMgc2hvdWxkIGJlIHNldCB0byB0aGUNCnZhbHVlIHByb3ZpZGVkIGJ5 IHRoZSBuZXR3b3JrIGFzIGEgcGFydCBvZiB0aGUgSVAgY29uZmlndXJhdGlvbi4gVGhpcw0KYXBw bGllcyB0byBib3RoIElQdjYgYW5kIElQdjQuDQoNClRoYXQgbWVhbnMgdXNlciBuZWVkcyB0byBi ZSBhYmxlIHRvIGNvcnJlY3RseSByZWFkIHRoZSBtdHUgdmFsdWUgY2FycmllZA0KaW4gdGhlIFJB IG1lc3NhZ2Ugc28gdGhhdCB1c2VyIGNhbiBjb3JyZWN0bHkgY29tcGFyZSBQQ08gaXB2NCBtdHUg YW5kDQpSQSBpcHY2IG10dS4NCg0KPj4gQEAgLTU3NjEsNiArNTc2NSw3IEBAIHN0YXRpYyBpbnQg aW5ldDZfc2V0X2lmdG9rZW4oc3RydWN0IGluZXQ2X2RldiAqaWRldiwgc3RydWN0IGluNl9hZGRy ICp0b2tlbiwNCj4+ICBzdGF0aWMgY29uc3Qgc3RydWN0IG5sYV9wb2xpY3kgaW5ldDZfYWZfcG9s aWN5W0lGTEFfSU5FVDZfTUFYICsgMV0gPSB7DQo+PiAgCVtJRkxBX0lORVQ2X0FERFJfR0VOX01P REVdCT0geyAudHlwZSA9IE5MQV9VOCB9LA0KPj4gIAlbSUZMQV9JTkVUNl9UT0tFTl0JCT0geyAu bGVuID0gc2l6ZW9mKHN0cnVjdCBpbjZfYWRkcikgfSwNCj4+ICsJW0lGTEFfSU5FVDZfUkFfTVRV XQkJPSB7IC50eXBlID0gTkxBX1UzMiB9LA0KPj4gIH07DQo+PiAgDQo+PiAgc3RhdGljIGludCBj aGVja19hZGRyX2dlbl9tb2RlKGludCBtb2RlKQ0KPiANCj4gSXRzIHZhbHVlIGlzIGRlcml2ZWQg ZnJvbSBhbiBSQSBub3Qgc2V0IGJ5IHVzZXJzcGFjZSwgc28gc2V0IHRoZSB0eXBlIHRvDQo+IE5M QV9SRUpFQ1Qgc28gdGhhdCBpbmV0Nl92YWxpZGF0ZV9saW5rX2FmIHdpbGwgcmVqZWN0IG1lc3Nh Z2VzIHRoYXQgaGF2ZQ0KPiBJRkxBX0lORVQ2X1JBX01UVSBzZXQuIFlvdSBjYW4gc2V0ICJyZWpl Y3RfbWVzc2FnZSIgaW4gdGhlIHBvbGljeSB0bw0KPiByZXR1cm4gYSBtZXNzYWdlIHRoYXQgIklG TEFfSU5FVDZfUkFfTVRVIGNhbiBub3QgYmUgc2V0Ii4NCg0Kd2lsbCBkby4NCg0KVGhhbmtzDQpS b2Njbw== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70FB3C4338F for ; Mon, 2 Aug 2021 03:44:25 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2FD2C6024A for ; Mon, 2 Aug 2021 03:44:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2FD2C6024A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=oDG456J6ErP2QIvR0Z6A1IGRK8BtxBUa+Ch3RbY1ags=; b=xtH5odV6A04ne7 jrbGIR7W4YkasiFbBj9odK5MirEEaGMf7sHhd6FDJDdGYCMcoXtG4hwirPyGgAEpmS+7XR38HP3s4 1tOaBTP4ZuT2aUheP5CUi80UhhNt7j4LPOJIC5e8Iw/MCidg/7z7rvnF8oD7aVnzvvUzV6yd5ehpq 8rFH96tSQBGL5En6yCM70SfPmAHxVk0oZU9gdEBfSimuFhbADpya/Xiy0bl0U7f5Xh7BkHrpcIeyI F54e46mCX+vs/0wpiqPkb5lgYlA0PttUtn/kJcOHzjutbh5qv0X5/apWXvF5gupDTpUeuo854AHL2 FnBNkSDGOUaTHETc/U6A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAOs9-00ErYe-Um; Mon, 02 Aug 2021 03:44:13 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAOrx-00ErWb-EX; Mon, 02 Aug 2021 03:44:02 +0000 X-UUID: fdbdc411b7c64042aac401da6ab0dde5-20210801 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=ZK3e9Sg7ghuyh77VEHKTRyGoBtj/73rumt2QQW4OnHM=; b=I1sTjCKmkm3Pr3FQlnuF3fvH+3ffvbvnfU5jGUKMMyBKeEdvjbffWFmT0UgOc54aN3XB7mcpmbzdf9zdyu+YuZEAVI6qqmyHdgzzoMPKPRmvbbSD5UkRGPBsZDEaGvxPLXYQDRA3yioZUN31DLcaQpYvdULWrdjJh7q5kQuNep0=; X-UUID: fdbdc411b7c64042aac401da6ab0dde5-20210801 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1302458776; Sun, 01 Aug 2021 20:43:58 -0700 Received: from MTKMBS32N1.mediatek.inc (172.27.4.71) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 1 Aug 2021 20:35:56 -0700 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by MTKMBS32N1.mediatek.inc (172.27.4.71) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 2 Aug 2021 11:35:49 +0800 Received: from localhost.localdomain (10.15.20.246) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 2 Aug 2021 11:35:48 +0800 From: Rocco Yue To: David Ahern CC: "David S . Miller" , Jakub Kicinski , Hideaki YOSHIFUJI , , , , , , , , Rocco Yue Subject: Re: [PATCH net-next v2] ipv6: add IFLA_INET6_RA_MTU to expose mtu value in the RA message Date: Mon, 2 Aug 2021 11:19:24 +0800 Message-ID: <20210802031924.3256-1-rocco.yue@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <5be90cf4-f603-c2f2-fd7e-3886854457ba@gmail.com> References: <5be90cf4-f603-c2f2-fd7e-3886854457ba@gmail.com> MIME-Version: 1.0 X-TM-SNTS-SMTP: 717DC6BBB0EEBCBF51C02B29FAF02E489CDAC93F80059C78A30F86F824E5FC2D2000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210801_204401_541119_2E1379FF X-CRM114-Status: GOOD ( 20.64 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Sat, 2021-07-31 at 11:17 -0600, David Ahern wrote: On 7/30/21 7:52 PM, Rocco Yue wrote: >> In this way, if the MTU values that the device receives from >> the network in the PCO IPv4 and the RA IPv6 procedures are >> different, the user space process can read ra_mtu to get >> the mtu value carried in the RA message without worrying >> about the issue of ipv4 being stuck due to the late arrival >> of RA message. After comparing the value of ra_mtu and ipv4 >> mtu, then the device can use the lower MTU value for both >> IPv4 and IPv6. > > you are storing the value and sending to userspace but never using it > when sending a message. What's the pointing of processing the MTU in the > RA if you are not going to use it to control message size? Hi David, In the requirement of mobile operator at&t in 2021: AT&T Prioritize Lower MTU value: If the MTU values that the device receives from the network in the PCO IPv4 and the RA IPv6 procedures are different, then the device shall use the lower MTU value for both IPv4 and IPv6. And in the 3GPP 23.060: The PDP PDUs shall be routed and transferred between the MS and the GGSN or P-GW as N-PDUs. In order to avoid IP layer fragmentation between the MS and the GGSN or P-GW, the link MTU size in the MS should be set to the value provided by the network as a part of the IP configuration. This applies to both IPv6 and IPv4. That means user needs to be able to correctly read the mtu value carried in the RA message so that user can correctly compare PCO ipv4 mtu and RA ipv6 mtu. >> @@ -5761,6 +5765,7 @@ static int inet6_set_iftoken(struct inet6_dev *idev, struct in6_addr *token, >> static const struct nla_policy inet6_af_policy[IFLA_INET6_MAX + 1] = { >> [IFLA_INET6_ADDR_GEN_MODE] = { .type = NLA_U8 }, >> [IFLA_INET6_TOKEN] = { .len = sizeof(struct in6_addr) }, >> + [IFLA_INET6_RA_MTU] = { .type = NLA_U32 }, >> }; >> >> static int check_addr_gen_mode(int mode) > > Its value is derived from an RA not set by userspace, so set the type to > NLA_REJECT so that inet6_validate_link_af will reject messages that have > IFLA_INET6_RA_MTU set. You can set "reject_message" in the policy to > return a message that "IFLA_INET6_RA_MTU can not be set". will do. Thanks Rocco _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 688EBC4338F for ; Mon, 2 Aug 2021 03:46:04 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2FC9161040 for ; Mon, 2 Aug 2021 03:46:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2FC9161040 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+UqWuxpQetvNKUCzCi3xl6rIoPfljj7Cfsmu0GA8ZfQ=; b=s1CaQtTh0C6ErA gnSg5fYRhBiSND9iuDWNzWhye2vBvoAJt2oje/r8JtCJEFe2xXuTzkWnMJzaCJE7oDj+LiMGgqwAj T8XICINzBdkk8mG3YMnn5jNo/wu9sU1BkmsqYUW7yphp9a95ZlGe+iy5RIzIb/EONocKVn/KzbG54 xla0VYULxFlM203k3rZWkVj6CoITTIjNA1Mf+Xgo87aFBOZrF3LBvTftgc8HQv4fQyUjiH8krgdO5 NpH1qx54ZDjK+mGGxxii3RjpDBDNNidtHZNlzi+vvr1hH/Ry2kMe9F5RiggfUBd5zacikFZ+pQzgE qpQcsJZ3o5b6ncxuBFPg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAOs0-00ErXM-MK; Mon, 02 Aug 2021 03:44:04 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAOrx-00ErWb-EX; Mon, 02 Aug 2021 03:44:02 +0000 X-UUID: fdbdc411b7c64042aac401da6ab0dde5-20210801 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=ZK3e9Sg7ghuyh77VEHKTRyGoBtj/73rumt2QQW4OnHM=; b=I1sTjCKmkm3Pr3FQlnuF3fvH+3ffvbvnfU5jGUKMMyBKeEdvjbffWFmT0UgOc54aN3XB7mcpmbzdf9zdyu+YuZEAVI6qqmyHdgzzoMPKPRmvbbSD5UkRGPBsZDEaGvxPLXYQDRA3yioZUN31DLcaQpYvdULWrdjJh7q5kQuNep0=; X-UUID: fdbdc411b7c64042aac401da6ab0dde5-20210801 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1302458776; Sun, 01 Aug 2021 20:43:58 -0700 Received: from MTKMBS32N1.mediatek.inc (172.27.4.71) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 1 Aug 2021 20:35:56 -0700 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by MTKMBS32N1.mediatek.inc (172.27.4.71) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 2 Aug 2021 11:35:49 +0800 Received: from localhost.localdomain (10.15.20.246) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 2 Aug 2021 11:35:48 +0800 From: Rocco Yue To: David Ahern CC: "David S . Miller" , Jakub Kicinski , Hideaki YOSHIFUJI , , , , , , , , Rocco Yue Subject: Re: [PATCH net-next v2] ipv6: add IFLA_INET6_RA_MTU to expose mtu value in the RA message Date: Mon, 2 Aug 2021 11:19:24 +0800 Message-ID: <20210802031924.3256-1-rocco.yue@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <5be90cf4-f603-c2f2-fd7e-3886854457ba@gmail.com> References: <5be90cf4-f603-c2f2-fd7e-3886854457ba@gmail.com> MIME-Version: 1.0 X-TM-SNTS-SMTP: 717DC6BBB0EEBCBF51C02B29FAF02E489CDAC93F80059C78A30F86F824E5FC2D2000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210801_204401_541119_2E1379FF X-CRM114-Status: GOOD ( 20.64 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, 2021-07-31 at 11:17 -0600, David Ahern wrote: On 7/30/21 7:52 PM, Rocco Yue wrote: >> In this way, if the MTU values that the device receives from >> the network in the PCO IPv4 and the RA IPv6 procedures are >> different, the user space process can read ra_mtu to get >> the mtu value carried in the RA message without worrying >> about the issue of ipv4 being stuck due to the late arrival >> of RA message. After comparing the value of ra_mtu and ipv4 >> mtu, then the device can use the lower MTU value for both >> IPv4 and IPv6. > > you are storing the value and sending to userspace but never using it > when sending a message. What's the pointing of processing the MTU in the > RA if you are not going to use it to control message size? Hi David, In the requirement of mobile operator at&t in 2021: AT&T Prioritize Lower MTU value: If the MTU values that the device receives from the network in the PCO IPv4 and the RA IPv6 procedures are different, then the device shall use the lower MTU value for both IPv4 and IPv6. And in the 3GPP 23.060: The PDP PDUs shall be routed and transferred between the MS and the GGSN or P-GW as N-PDUs. In order to avoid IP layer fragmentation between the MS and the GGSN or P-GW, the link MTU size in the MS should be set to the value provided by the network as a part of the IP configuration. This applies to both IPv6 and IPv4. That means user needs to be able to correctly read the mtu value carried in the RA message so that user can correctly compare PCO ipv4 mtu and RA ipv6 mtu. >> @@ -5761,6 +5765,7 @@ static int inet6_set_iftoken(struct inet6_dev *idev, struct in6_addr *token, >> static const struct nla_policy inet6_af_policy[IFLA_INET6_MAX + 1] = { >> [IFLA_INET6_ADDR_GEN_MODE] = { .type = NLA_U8 }, >> [IFLA_INET6_TOKEN] = { .len = sizeof(struct in6_addr) }, >> + [IFLA_INET6_RA_MTU] = { .type = NLA_U32 }, >> }; >> >> static int check_addr_gen_mode(int mode) > > Its value is derived from an RA not set by userspace, so set the type to > NLA_REJECT so that inet6_validate_link_af will reject messages that have > IFLA_INET6_RA_MTU set. You can set "reject_message" in the policy to > return a message that "IFLA_INET6_RA_MTU can not be set". will do. Thanks Rocco _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel