From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 045A6459CB; Thu, 19 Sep 2024 03:40:46 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BE56142F7A; Thu, 19 Sep 2024 03:40:45 +0200 (CEST) Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by mails.dpdk.org (Postfix) with ESMTP id 223BC42E5B for ; Thu, 19 Sep 2024 03:40:42 +0200 (CEST) Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4X8HkZ5gT5z2QTv1; Thu, 19 Sep 2024 09:20:06 +0800 (CST) Received: from dggpeml500024.china.huawei.com (unknown [7.185.36.10]) by mail.maildlp.com (Postfix) with ESMTPS id B70FC1400D4; Thu, 19 Sep 2024 09:20:45 +0800 (CST) Received: from [10.67.121.161] (10.67.121.161) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 19 Sep 2024 09:20:45 +0800 Message-ID: <58a9b4aa-fd18-4903-a239-69d41d65d1d3@huawei.com> Date: Thu, 19 Sep 2024 09:20:45 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v23 11/15] log: add timestamp option To: Stephen Hemminger CC: , =?UTF-8?Q?Morten_Br=C3=B8rup?= References: <20200814173441.23086-1-stephen@networkplumber.org> <20240918045830.3798-1-stephen@networkplumber.org> <20240918045830.3798-12-stephen@networkplumber.org> <9522e9c9-f696-48d0-a080-bf5e6c54f9e6@huawei.com> <20240918080500.3739c0ab@hermes.local> Content-Language: en-US From: fengchengwen In-Reply-To: <20240918080500.3739c0ab@hermes.local> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.161] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpeml500024.china.huawei.com (7.185.36.10) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2024/9/18 23:05, Stephen Hemminger wrote: > On Wed, 18 Sep 2024 15:37:49 +0800 > fengchengwen wrote: > >> ... >> >>> + >>> +static enum { >>> + LOG_TIMESTAMP_NONE = 0, >>> + LOG_TIMESTAMP_TIME, /* time since start */ >>> + LOG_TIMESTAMP_DELTA, /* time since last message */ >>> + LOG_TIMESTAMP_RELTIME, /* relative time since last message */ >>> + LOG_TIMESTAMP_CTIME, /* Unix standard time format */ >>> + LOG_TIMESTAMP_ISO, /* ISO8601 time format */ >> >> Some of the impl should consider multiple-thread safety. >> >> And for multiple-process, how about the secondary-processes align the main-process. > > > As much as possible, they are thread safe, that is why locatime_r is used. > Of course if multiple threads are printing it is possible that time stamps > could be out of order. I.e CPU A got timestamp and is formatting message, > and CPU B got timestamp is formatting message. The formatting might take longer for A. Yes, the localtime_r is thread safe, but like delta, multi thread will both read and update global variable log_time.previous with any sync, this may lead problem. static struct { struct timespec started; /* when log was initialized */ struct timespec previous; /* when last msg was printed */ } log_time; e.g. 1, the previous tv_sec = 1000, tv_nsec = 90000; 2, thread A invoke log, and current tv_sec = 2000, tv_nsec = 10000; it will update the previous 3, thread B also invoke log, and current tv_sec = 2000, tv_nsec = 10001, but it read previous is tv_sec = 2000, tv_nsec = 90000 and the delta will invalid.