From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 952424C9D for ; Mon, 13 May 2019 12:49:03 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2019 03:49:02 -0700 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga007.fm.intel.com with ESMTP; 13 May 2019 03:49:01 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.155]) by IRSMSX104.ger.corp.intel.com ([169.254.5.93]) with mapi id 14.03.0415.000; Mon, 13 May 2019 11:49:00 +0100 From: "Ananyev, Konstantin" To: Adrien Mazarguil , "Smoczynski, MarcinX" CC: Thomas Monjalon , "dev@dpdk.org" , "Richardson, Bruce" , "shahafs@mellanox.com" , "gaetan.rivet@6wind.com" , "matan@mellanox.com" Thread-Topic: [dpdk-dev] Using _XOPEN_SOURCE macros may break builds on FreeBSD Thread-Index: AdUHUhFuf1vcUQd1TgeecdbKRnBo9QAAiWkAAAA7TgAAhPm0AAABLeYAAAJB0QA= Date: Mon, 13 May 2019 10:49:00 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580161631159@irsmsx105.ger.corp.intel.com> References: <2F25558C1648FA498380EAC12A8612624FD953@HASMSX110.ger.corp.intel.com> <9076832.UKkv39EgZr@xps> <2604468.nBFxeWxGDx@xps> <2F25558C1648FA498380EAC12A86126251F3B2@HASMSX110.ger.corp.intel.com> <20190513102510.GJ4284@6wind.com> In-Reply-To: <20190513102510.GJ4284@6wind.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmE0ZTgzN2QtYjFiNy00ZTQ0LTliZDItZGYzMDgyZDJkOTFlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiSWdRYmx3OUZFSW1oa3BlRzdIVmVCQUVTSnhYV1wvSFcyWFFtRzVlNU5BXC8zMnZrVmFocmRaZ2ZlSGtYWllPTTJlIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] Using _XOPEN_SOURCE macros may break builds on FreeBSD X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2019 10:49:04 -0000 Hi Adrien, >=20 > On Mon, May 13, 2019 at 09:51:24AM +0000, Smoczynski, MarcinX wrote: > > 10/05/2019 20:17, Thomas Monjalon: > > > 10/05/2019 19:14, Smoczynski, MarcinX: > > > > To summarize we have different visibility sets for Linux and BSD > > > > when using XOPEN_SOURCE or POSIX_C_SOURCE explicitly. To overcome > > > > this situation we can either remove problematic XOPEN macros from > > > > mk/meson rules (drivers/net/failsafe, drivers/net/mlx4, > > > > drivers/net/mlx5) > > > > > > What is the consequence of removing these macros in mlx and failsafe = PMDs? > > > > The purpose of these *_SOURCE constants is to enable particular feature= sets > > visibility. As long as we have GNU_SOURCE on Linux removing it won't ha= ve any > > consequences. On BSD it will unify feature sets visibility with the res= t of > > sources. Can't think of any downsides here. > > > > I believe XOPEN_SOURCE was introduced to extend features not to restric= t them. >=20 > I confirm that under Linux, all IPPROTO_* (POSIX/XOPEN/RFC1700) are defin= ed > regardless (_GNU_SOURCE not even needed), while under FreeBSD, the non-PO= SIX > versions are only defined when __BSD_VISIBLE is set. >=20 > The FreeBSD behavior is more correct in this respect since the purpose of > _XOPEN_SOURCE and friends is also to let applications limit the risk of > redefinitions in case they were written for an earlier standard > (e.g. -D_XOPEN_SOURCE=3D500 vs. -D_XOPEN_SOURCE=3D600). Still not sure why do you need it for failsafe and mlx PMDs? Would something in these PMDs be broken without '-D_XOPEN_SOURCE=3D600'? >=20 > DPDK applications may also define _XOPEN_SOURCE for their own needs. They > should still be able to use rte_ip.h afterward. I suppose they can, they would just have (on FreeBSD) to add '-D __BSD_VISI= BLE' themselves.=20 > I think this reason is > enough to go with -D__BSD_VISIBLE under FreeBSD without removing > _XOPEN_SOURCE, as it should work regardless. So do you suggest to add '-D __BSD_VISIBLE' into mlx/failsafe PMDs Makefiles/meson.build, or ... ? =20 > Looking at the patch [1], I also think there's another, simpler approach: > unless really performance critical, defining rte_ipv6_get_next_ext() in > rte_net.c instead of a static inline in rte_ip.h should address this issu= e. It is performance critical, and I think that=20 function call for each ext header is a way too expensive approach. Will prefer to keep that function inline. Konstantin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id A06B1A00E6 for ; Mon, 13 May 2019 12:49:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3108E4C9F; Mon, 13 May 2019 12:49:06 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 952424C9D for ; Mon, 13 May 2019 12:49:03 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2019 03:49:02 -0700 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga007.fm.intel.com with ESMTP; 13 May 2019 03:49:01 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.155]) by IRSMSX104.ger.corp.intel.com ([169.254.5.93]) with mapi id 14.03.0415.000; Mon, 13 May 2019 11:49:00 +0100 From: "Ananyev, Konstantin" To: Adrien Mazarguil , "Smoczynski, MarcinX" CC: Thomas Monjalon , "dev@dpdk.org" , "Richardson, Bruce" , "shahafs@mellanox.com" , "gaetan.rivet@6wind.com" , "matan@mellanox.com" Thread-Topic: [dpdk-dev] Using _XOPEN_SOURCE macros may break builds on FreeBSD Thread-Index: AdUHUhFuf1vcUQd1TgeecdbKRnBo9QAAiWkAAAA7TgAAhPm0AAABLeYAAAJB0QA= Date: Mon, 13 May 2019 10:49:00 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580161631159@irsmsx105.ger.corp.intel.com> References: <2F25558C1648FA498380EAC12A8612624FD953@HASMSX110.ger.corp.intel.com> <9076832.UKkv39EgZr@xps> <2604468.nBFxeWxGDx@xps> <2F25558C1648FA498380EAC12A86126251F3B2@HASMSX110.ger.corp.intel.com> <20190513102510.GJ4284@6wind.com> In-Reply-To: <20190513102510.GJ4284@6wind.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmE0ZTgzN2QtYjFiNy00ZTQ0LTliZDItZGYzMDgyZDJkOTFlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiSWdRYmx3OUZFSW1oa3BlRzdIVmVCQUVTSnhYV1wvSFcyWFFtRzVlNU5BXC8zMnZrVmFocmRaZ2ZlSGtYWllPTTJlIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] Using _XOPEN_SOURCE macros may break builds on FreeBSD X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190513104900.KrqoyIFh6Ao9jFljI_ApEszHB7lLmfEf1RsCQqLm6fs@z> Hi Adrien, >=20 > On Mon, May 13, 2019 at 09:51:24AM +0000, Smoczynski, MarcinX wrote: > > 10/05/2019 20:17, Thomas Monjalon: > > > 10/05/2019 19:14, Smoczynski, MarcinX: > > > > To summarize we have different visibility sets for Linux and BSD > > > > when using XOPEN_SOURCE or POSIX_C_SOURCE explicitly. To overcome > > > > this situation we can either remove problematic XOPEN macros from > > > > mk/meson rules (drivers/net/failsafe, drivers/net/mlx4, > > > > drivers/net/mlx5) > > > > > > What is the consequence of removing these macros in mlx and failsafe = PMDs? > > > > The purpose of these *_SOURCE constants is to enable particular feature= sets > > visibility. As long as we have GNU_SOURCE on Linux removing it won't ha= ve any > > consequences. On BSD it will unify feature sets visibility with the res= t of > > sources. Can't think of any downsides here. > > > > I believe XOPEN_SOURCE was introduced to extend features not to restric= t them. >=20 > I confirm that under Linux, all IPPROTO_* (POSIX/XOPEN/RFC1700) are defin= ed > regardless (_GNU_SOURCE not even needed), while under FreeBSD, the non-PO= SIX > versions are only defined when __BSD_VISIBLE is set. >=20 > The FreeBSD behavior is more correct in this respect since the purpose of > _XOPEN_SOURCE and friends is also to let applications limit the risk of > redefinitions in case they were written for an earlier standard > (e.g. -D_XOPEN_SOURCE=3D500 vs. -D_XOPEN_SOURCE=3D600). Still not sure why do you need it for failsafe and mlx PMDs? Would something in these PMDs be broken without '-D_XOPEN_SOURCE=3D600'? >=20 > DPDK applications may also define _XOPEN_SOURCE for their own needs. They > should still be able to use rte_ip.h afterward. I suppose they can, they would just have (on FreeBSD) to add '-D __BSD_VISI= BLE' themselves.=20 > I think this reason is > enough to go with -D__BSD_VISIBLE under FreeBSD without removing > _XOPEN_SOURCE, as it should work regardless. So do you suggest to add '-D __BSD_VISIBLE' into mlx/failsafe PMDs Makefiles/meson.build, or ... ? =20 > Looking at the patch [1], I also think there's another, simpler approach: > unless really performance critical, defining rte_ipv6_get_next_ext() in > rte_net.c instead of a static inline in rte_ip.h should address this issu= e. It is performance critical, and I think that=20 function call for each ext header is a way too expensive approach. Will prefer to keep that function inline. Konstantin