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 A4CF4A050B; Wed, 6 Apr 2022 23:50:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4135640689; Wed, 6 Apr 2022 23:50:34 +0200 (CEST) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by mails.dpdk.org (Postfix) with ESMTP id D26914014F for ; Wed, 6 Apr 2022 23:50:33 +0200 (CEST) Received: by mail-lf1-f44.google.com with SMTP id p10so6340899lfa.12 for ; Wed, 06 Apr 2022 14:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=EKBR/etSZWRvvsouWKkGDEKKoImBfNxagvoRpRCC5Fg=; b=II6DF2aRwsMN+5CFwEA40h7WvPMDbY88dletZIQp4RNbcTsW5d5UA2mKs4HjGZMa8m EHWV3MmNmrJ9IYyb8B+2zZo23Qf6wkFKGOB6KrcxRZxDVfRJdKYTboKPQKKiIlW9LSDV ILvx5XS7VRaNau3J8UjXx2PIQeSavLj7+oLQMOMGuwoSVVPI4Qy0ME/yHQGmyITmmUCo RtBp+7/9AyovutWMvHA4K1ZD5eGFKOm+jg7SEVWMEitpIzIWvEo+WSNDgG4f1hjK6mWf abQav/jTwWxk+zh34hvFHdabeH7mTvpc2fUmziZYLZlVYcPH1T9EzURG9I3oY/bGL9WV /cpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=EKBR/etSZWRvvsouWKkGDEKKoImBfNxagvoRpRCC5Fg=; b=iHQ1JRmwH5urxCxeJtH65n0z0k0TBJ6IrU0gAJFwMn/xwtQ3KB9hLDJIr/wpizx0/S 3foHq6ubUWRaD5SpTmoUYsrEHuBMCT1ZMM6mDItqnLX3anpK6we6MecYcKLEN+WGjk9s OhsXGIuuIzOdBrSq8JV2AxKnaH66tDN3L4FkYm2B6poyB32C2xio8k7TvKU/FFblL+Zg 68j5eeuchaBxrRAFR3Ixvbmjtaq2z5BPWilzc7nNzL75t2LFIqH0DCd8S72rT3021GiG HGAtChEl9pmN7vJ3DjpE8x6SQsouNCYNsESZRcvyUAVHegVBbKC8qO9rYilaKMrqr6yk NfHQ== X-Gm-Message-State: AOAM530fxVvKmU4RhIsPsocW5AlidVOwoygw+pvBjwrHkV9+lCRnU3FB q84HhUHtg9vWPYa2TxIYpXY= X-Google-Smtp-Source: ABdhPJwMc2TpAN/iX50OHxXeCOVRiuKR70TQdhTarSi4LpILvEIe7U9BUBBUm7NO7yVNksQmfMCkeg== X-Received: by 2002:a05:6512:3ca1:b0:44a:93f1:45cf with SMTP id h33-20020a0565123ca100b0044a93f145cfmr7505164lfv.542.1649281833041; Wed, 06 Apr 2022 14:50:33 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id b5-20020a056512060500b0044ac20061easm1954943lfe.125.2022.04.06.14.50.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 14:50:31 -0700 (PDT) Date: Thu, 7 Apr 2022 00:50:29 +0300 From: Dmitry Kozlyuk To: Bruce Richardson Cc: dev@dpdk.org, Vipin Varghese , Ciara Power , Sivaprasad Tummala , Tyler Retzlaff , Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam Subject: Re: [RFC] Telemetry enhancements and Windows support Message-ID: <20220407005029.29e34a11@sovereign> In-Reply-To: References: <20220402015901.72798593@sovereign> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 2022-04-04 11:03 (UTC+0100), Bruce Richardson: [...] > Having EAL be the only one to create threads seems reasonable. However, I'm > a little uncertain about the scope of change and tying telemetry and EAL > together a lot more. Scope is a strong valid argument. What do you think if telemetry would create threads using Win32 API just like on Unices it creates threads using pthread (external component that is always present)? > Another alternative might be to change telemetry to > use only one thread for all connections and using "select" or "poll" to > wait on input from all sockets simultaneously. Would that work on Windows? Yes, there are select() and "poll()" with slightly different naming. > > * The logging issue can be solved differently: > > > > a) by factoring logging into a library, either as Bruce suggested; > > b) by replacing logging with simple print in Windows shim; > > c) by integrating and using the new threading API [1, 2]. > > > > What is the issue with the current logging in telemetry on windows? pthread.h shim contains calls to rte_log(). > The > current implementation has EAL pass in the logging function to telemetry on > init, allowing use of EAL logging without requiring a link-time dependency. > Theoretically, the same solution could also be used for the threading, > though I'm wary about doing so as using the same solution multiple times > could lead to very awkward APIs. Thinking out of scope of this RFC, telemetry *library* API should be: - register handler - JSON helpers - create session - process command in a session - destroy session All IO should be outside. Otherwise it's not a library but a framework. rte_telemetry_init() and all IO it starts is a higher-level helper for the very common case that doesn't need to be in lib/telemetry itself and even doesn't need to be a public API (but can be). > Overall, I tend to think the proper solution for all this is to split EAL - > something that was discussed previously but never done because it's > difficult and the result may be uncertain. Theoretically, most low-level > services in EAL, such as logging, should be in one library, while the EAL > init code remains in a later, higher-level one. I'd even say: utilities (log, trace, UUID, ...), environment abstraction, and runtime (init, tasks, multiprocess). It would be interesting to have a topic on that. [...] > > * It is technically possible to accept remote connections. > > However, it's a new attack surface and a security risk. > > OTOH, there's no need to allow remote connections: > > anyone who needs this can setup a tunnel or something. > > Local socket must be used by default. > > > > Completely agree on not accepting non-local connections. However, I'd also > point out that another reason why a unix socket was chosen over other > TCP/UDP/etc socket options was that it also gave local-user protection. > Right now, if a DPDK process is run as root, no non-root user can connect > to the telemetry socket, unless root explicitly gives permissions. For TCP > or similar sockets, that would not be the case. Not sure how big a deal > that would be. Windows also provides named pipes: 1. Pipes are subject to access control. 2. Pipes can work in message mode, like SOCK_SEQPACKET. 3. Pipes are addressed by path of form \\.\pipe\NAME that is not visible in the file system, like abstract Unix sockets, but this namespace is shared, so collision issue remains. 4. Pipes can be accessed as files from Python. Message mode can be activated with a Win32 API call that can be done using ctypes and msvcrt bundled modules. 5. Pipes can be configured to reject remote connections and to automatically limit the number of clients if needed. Another advantage is that message framing will not be needed this time, which limits the scope. Drawbacks: 1. There will be less shared code between Windows and Unix. Unix domain sockets and named pipes provide the same "accept client, send message, receive message, disconnect" API, so it's easy to share all non-transport logic. dpdk-telemetry.py will need a few Windows-specific lines. 2. On Windows, select() and WSAPoll() are only applicable to sockets. If we decide to multiplex IO in lib/telemetry and use named pipes, multiplexers will be different.