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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 12919ECAAD4 for ; Tue, 30 Aug 2022 22:36:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232009AbiH3WgK (ORCPT ); Tue, 30 Aug 2022 18:36:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229647AbiH3WgI (ORCPT ); Tue, 30 Aug 2022 18:36:08 -0400 Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4AEE765646; Tue, 30 Aug 2022 15:36:07 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id e7so5312600ilc.5; Tue, 30 Aug 2022 15:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=isZjHDiHzy0/kCoZ8oyrkIrlQ2Sb2B/u+7KxfGkOIrg=; b=M2ytLh9nqpOk5aNDGrusWccSRNqzBtVzaKOkBdyrmC2dClHQsq+zjyo+JWrkCjtvXo 0szu/HbqqKiJe5RB7DvwtRbLoWDytCDL1rYOTqRDGaUDel1hka0Alzbh4HOItM5Fvrbc S87EDc5cZSd2D8vyoWz7OIPW/8+/VX1OxhtuaCd7DNJ9aUTIzJUwWizcc5zAQ1Czbvey 4FkqqN9iswFGY1jOZOupQcuv9DAA3bplvHniFmn+QAU3CHPQ23+06VsPvGqeWGjP+aG9 sGiJwoRTYu27Xk9FcC5eo7whRBkXxPuFEQs4+SZ4BUaLJAPvoC86A2KZu6ONf/8+Pkon pT8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=isZjHDiHzy0/kCoZ8oyrkIrlQ2Sb2B/u+7KxfGkOIrg=; b=niSt4XmYAFrStWY2DztzkNZW0mPH06deUB8nkYqh/b33jGjbotVnUB6TugpyMsMxhZ Ml/z02fE7PMG3z3t0eClBUQRSIisetpp9I2eDwJrk30j3fpIaC4BlKnKSkhLS2eGYHqz OSPs2v1xsDBFdnAuDUuo+G7WFVFwRsD1kbccHUDUFdoRiOitCmMsrgRAeo9jlY2Qwngc tyIKGUUqy+bU979V/amcGOwIhDF2wJLVtuSBbEfoiJ2nCZ9VCkvekPDhO8Gb9odheC34 SzockB/ng/lIhJVCjkjsdcMIXTDJiMmMSj56uf+bXYL9CiASUimxAklhoGCrHaO5XETt hVjA== X-Gm-Message-State: ACgBeo0vDn4sb+p0TA9dBVG3+bDvoomXaklK6wycXViBryrBLnxwPKLb duoW2W4TiNpTvUQQ3yGkzScjqxtNPPZ2M0czX3bwcOwbyFOE4g== X-Google-Smtp-Source: AA6agR7rSdwBgLwZzpdhwEuTG0ACljTRvp1d8M57LIvYdThqXcm7X6ETfUSUyUPkXQLvRMv0ugB9pIlNxqIipnW8Pbg= X-Received: by 2002:a05:6e02:1a0b:b0:2df:5c44:9796 with SMTP id s11-20020a056e021a0b00b002df5c449796mr13760096ild.145.1661898966626; Tue, 30 Aug 2022 15:36:06 -0700 (PDT) MIME-Version: 1.0 References: <20220719014704.21346-2-antonio@openvpn.net> <20220803153152.11189-1-antonio@openvpn.net> <20220812114427.05f7393a@hermes.local> In-Reply-To: <20220812114427.05f7393a@hermes.local> From: Sergey Ryazanov Date: Wed, 31 Aug 2022 01:35:54 +0300 Message-ID: Subject: Re: [RFC v2] net: introduce OpenVPN Data Channel Offload (ovpn-dco) To: Stephen Hemminger Cc: Antonio Quartulli , netdev@vger.kernel.org, David Miller , Jakub Kicinski , open list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Stephen, On Fri, Aug 12, 2022 at 9:44 PM Stephen Hemminger wrote: > On Fri, 12 Aug 2022 21:34:33 +0300 > Sergey Ryazanov wrote: >> What is the purpose of creating and destroying interfaces via RTNL, >> but performing all other operations using the dedicated netlink >> protocol? >> >> RTNL interface usually implemented for some standalone interface >> types, e.g. VLAN, GRE, etc. Here we need a userspace application >> anyway to be able to use the network device to forward traffic, and >> the module implements the dedicated GENL protocol. So why not just >> introduce OVPN_CMD_NEW_IFACE and OVPN_CMD_DEL_IFACE commands to the >> GENL interface? It looks like this will simplify the userspace part by >> using the single GENL interface for any management operations. > > RTNL is netlink. The standard way to create network devices should > be available with newlink message as in: > > # ip link add dev myvpn type ovpn If you do not mind, then I would like to say that RTNL is not a standard way, but a common way to create a virtual network interface. The RTNL ability to create network devices is very useful for standalone interface types (VLANs, GRE, etc.). But there are other types that require much more care to be brought into a usable state. E.g., WLAN devices can only be managed by GENL. Even L2TP that can be created with ip(8) actually utilizes the GENL based interface and completely ignores RTNL. An OpenVPN network device created with ip-link(8) will remain useless until the control daemon establishes a connection, negotiates params, adds a peer, etc. And all these actions should be performed using a separate GENL interface. I mean that the RTNL support in the OpenVPN module is a dead-end. That is why I suggested Antonio to save his time by ignoring the network interface creation with RTNL and focus on the GENL interface. Using only the GENL-based interface will also simplify development of the control daemon. Does this strategy sound reasonable in this particular context? -- Sergey