From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2CA501E9060 for ; Tue, 8 Oct 2024 08:01:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728374507; cv=none; b=WYvzpiDPChV2T4h7AzRTyRARQN1KhhKrmd3j8mf07pAgNk5a3lj7LjsBZA+3tOL04E3iYjNuIZGLS5XVTNzS5GJh3O9J0GmRpGJMiTxDO1KqWmiUAyolw0/gxA9G+RxlkmZkIXUaBC+4QyrsMOCvcIeZydga5o06tihc2KScPB4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728374507; c=relaxed/simple; bh=LZmDz6iNhvMt90dfMzQq3WFtioFDN/yJfqXcR37OWuM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=avvz97MDd2SZXgQ37CM2qURksBtbQP8/hPcPeCm+2WlciQkVtjuahAkaTkDYeQzA86iPcCqXw1dwmqZM7Eoil4FKLrNQnTVssGj86BWEJXdq/MJwLjl4i4+VpdgomqX9plSpB6USKYFDAUSpMk3kYbDMkbwG9wXtD4YepvNjeDk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=openvpn.net; spf=pass smtp.mailfrom=openvpn.com; dkim=pass (2048-bit key) header.d=openvpn.net header.i=@openvpn.net header.b=MFcmo2Rb; arc=none smtp.client-ip=209.85.221.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=openvpn.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=openvpn.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=openvpn.net header.i=@openvpn.net header.b="MFcmo2Rb" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-37ccd81de57so3523188f8f.0 for ; Tue, 08 Oct 2024 01:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openvpn.net; s=google; t=1728374503; x=1728979303; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=TehQzGqlQ7/A72VhokMvGGbcSaxUL90Hefcysi5X+2c=; b=MFcmo2Rba4eNnyClR6GWKCNjp/SNCtzlbe9rJjWztDhbLuBepSQ1YKrJRf2P09lnPM XxJ9Tl/C4MdB3T2DR02jXkRV5930AuHQmKovGLfJUpwx8Qifi5+BSSoJyotZbJG4zliZ FqWAWtgKt0xXTdKMOL1dZXmWu26EWcvpw8YnpOwPajIxTOo7GmEFJUIkvz7aRETgkxDq 22ZoHo7NHcp0lqfvfWRn4db74u6W67pkFdA7GIxfTLENyiN3mWyl3xFyK+pmFHaCppE0 rwicJgfzOwBweuNNj6evDFL4ps4lbjZWYEziRbB1GIzZJxf6el6h5rqHs7jK3uaGoVyy Hbfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728374503; x=1728979303; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TehQzGqlQ7/A72VhokMvGGbcSaxUL90Hefcysi5X+2c=; b=s7lTagJ4Djq8XIj3eN/Yq8jcrEbcXUcYDfkZKF22Dw+qdlTtVvuwStDpOgvQJG5eJf 5qcH9eGXy3k/rYavCvGrI1RPnvrtQ6MWW9JDJEfNdkU+sXzUOlGFvxjzibBH1NGcBFKk 1R7CwTS/bSKaw10I4v9UoUq7Xx3VTEg4t6uWEDpg152xtP0wbc12ZVBOCoMxwk3SkRaw FG9sVMYJAp4HGinq9WTQ+DhShHhbbEa9AXs74sirjzOsXldLgSGe/9Ib+BWLebxAZgoQ 2uYXjGXo9gX1H8JyQxkEMRHz0O2Fy5S+FdqjchsP8B0zJ4VzZ+Ba0BG8wQBfAwj0xVZI e3Qg== X-Forwarded-Encrypted: i=1; AJvYcCWznRr4Zp51AzpDqSIVUwocvPa8AArYFTJpHxxV7ik/FnxZjwtzTr6xWKy61Q2AW/9/5Cr7rkLS5IADyBY=@vger.kernel.org X-Gm-Message-State: AOJu0YyTEEadpnU+nL3YpEnYHGz2dg9vQR8NloZiFGbAA/BVH9T9Av4Y cXFqEAKvB8e1wX0k2/JtOraW2zoVlXdaAfwZmo0/ujY5ceCfQHRViaQH336qixM= X-Google-Smtp-Source: AGHT+IH9ziQgmbKEumziF2/Xxptvs0roO67voR7Em/ui/HeZGyfcmtQFejktMLrTRIjO41lNztSXcQ== X-Received: by 2002:a05:6000:2a0c:b0:37d:3161:12de with SMTP id ffacd0b85a97d-37d316113c0mr748358f8f.23.1728374503502; Tue, 08 Oct 2024 01:01:43 -0700 (PDT) Received: from ?IPV6:2001:67c:2fbc:1:2089:55b1:87be:76d4? ([2001:67c:2fbc:1:2089:55b1:87be:76d4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37d2ce265fdsm943122f8f.83.2024.10.08.01.01.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Oct 2024 01:01:42 -0700 (PDT) Message-ID: Date: Tue, 8 Oct 2024 10:01:40 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v8 03/24] ovpn: add basic netlink support To: Jiri Pirko Cc: Eric Dumazet , Jakub Kicinski , Paolo Abeni , Donald Hunter , Shuah Khan , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, sd@queasysnail.net, ryazanov.s.a@gmail.com References: <20241002-b4-ovpn-v8-0-37ceffcffbde@openvpn.net> <20241002-b4-ovpn-v8-3-37ceffcffbde@openvpn.net> Content-Language: en-US From: Antonio Quartulli In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 07/10/24 17:32, Jiri Pirko wrote: > Wed, Oct 02, 2024 at 11:02:17AM CEST, antonio@openvpn.net wrote: > > [...] > > >> +operations: >> + list: >> + - >> + name: dev-new >> + attribute-set: ovpn >> + flags: [ admin-perm ] >> + doc: Create a new interface of type ovpn >> + do: >> + request: >> + attributes: >> + - ifname >> + - mode >> + reply: >> + attributes: >> + - ifname >> + - ifindex >> + - >> + name: dev-del > > Why you expose new and del here in ovn specific generic netlink iface? > Why can't you use the exising RTNL api which is used for creation and > destruction of other types of devices? That was my original approach in v1, but it was argued that an ovpn interface needs a userspace program to be configured and used in a meaningful way, therefore it was decided to concentrate all iface mgmt APIs along with the others in the netlink family and to not expose any RTNL ops. However, recently we decided to add a dellink implementation for better integration with network namespaces and to allow the user to wipe a dangling interface. In the future we are planning to also add the possibility to create a "persistent interface", that is an interface created before launching any userspace program and that survives when the latter is stopped. I can guess this functionality may be better suited for RTNL, but I am not sure yet. @Jiri: do you have any particular opinion why we should use RTNL ops and not netlink for creating/destroying interfaces? I feel this is mostly a matter of taste, but maybe there are technical reasons we should consider. Thanks a lot for your contribution. Regards, > > > ip link add [link DEV | parentdev NAME] [ name ] NAME > [ txqueuelen PACKETS ] > [ address LLADDR ] > [ broadcast LLADDR ] > [ mtu MTU ] [index IDX ] > [ numtxqueues QUEUE_COUNT ] > [ numrxqueues QUEUE_COUNT ] > [ netns { PID | NETNSNAME | NETNSFILE } ] > type TYPE [ ARGS ] > > ip link delete { DEVICE | dev DEVICE | group DEVGROUP } type TYPE [ ARGS ] > > Lots of examples of existing types creation is for example here: > https://developers.redhat.com/blog/2018/10/22/introduction-to-linux-interfaces-for-virtual-networking > > > >> + attribute-set: ovpn >> + flags: [ admin-perm ] >> + doc: Delete existing interface of type ovpn >> + do: >> + pre: ovpn-nl-pre-doit >> + post: ovpn-nl-post-doit >> + request: >> + attributes: >> + - ifindex > > [...] -- Antonio Quartulli OpenVPN Inc.