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 66CFA41C40; Wed, 8 Feb 2023 14:17:11 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 86C2442BC9; Wed, 8 Feb 2023 14:16:53 +0100 (CET) Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by mails.dpdk.org (Postfix) with ESMTP id 22F6E4021F for ; Tue, 7 Feb 2023 18:26:45 +0100 (CET) Received: by mail-ed1-f48.google.com with SMTP id i38so5957102eda.1 for ; Tue, 07 Feb 2023 09:26:45 -0800 (PST) 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:message-id:reply-to; bh=XSoMNeqn5idxjKspe2L+ezL4MECXyqFk6FKQSfyTkjs=; b=lfbdxml2lV9lS/uG44nFZpGdn9Z8/x6j3rXeX/fBBa6cOcUan7/zdJGMdzzWpHNvRx +clMN2w6vnoXqJRFLMenh7wkD7RPNdaR8C4FPZIy/4caFxwZLSkz6IbSGa0eEKIcJBgT dtW8bdD5KlxC+Ka/lgTMynYUrhA5Bq48IKKXOYCvHocp8NIVl9TiaD+4B2t1vdZ6IPle hLNzusu6bx6biYFJ8SNN4zbd/ofmxAoUDd6k+dbpEhCDmC6iqTx84lzViZFgOZMLP3Fv gPoTWkvLAMtQ/XmLsU6v3Oz/lg7WPlqcqeTyqdX3iC2Qg1UTFpoCRC++tOrCBoT/DFq2 P/sw== 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:message-id :reply-to; bh=XSoMNeqn5idxjKspe2L+ezL4MECXyqFk6FKQSfyTkjs=; b=H2IYtI9Wzm01a1nF3FWlMsrGAUOSk3FJiRJHdJ5c+IX2ETA5ctOPLmQTssLGrAkOZN OwKwTC8HIZa2f0xkX6uIS2XdZ+aWq7WcySHu/16SGg4yTdzQ/PH1h7zb/1+ui58pYHER q4HfLoZhM4r1kYzOU3tdm/mlYRiw+2brfmi0l0sE1lNONQ5B3AV1isupZHj8WyRqBavd mNpPeZ8YOre/ywdEYhd3hD5+u59uzxx1466+oFKI5YUxbgsXeXTlhJbAcc19lslMLDwB DiHF6fl6x0jidIwfqPtOVyBJNVIkNagXBre4Jm6ZFtynYDELrnLdr8DCSER/En/hZNzp cvzQ== X-Gm-Message-State: AO0yUKXmov8xI9tAgQwKOcF+QEz9fomsIeMzfMKyteJ43MnHxLk6kQej wym9AJNiuuD6vi/fPdEOw/amvgz3ktNS3o5o1LU= X-Google-Smtp-Source: AK7set/qMMtbSkXorjb1rVexMLmtdG9TQJVlmxaPWEEFM2QxTepW5YWh6SaZKPb2+1Jl7626MJciE65ewEycGGtufy4= X-Received: by 2002:a50:9b13:0:b0:499:70a8:f914 with SMTP id o19-20020a509b13000000b0049970a8f914mr1185839edi.23.1675790804786; Tue, 07 Feb 2023 09:26:44 -0800 (PST) MIME-Version: 1.0 References: <20221010104038.15867-1-nathan.skrzypczak@gmail.com> <20221017121246.9721-1-nathan.skrzypczak@gmail.com> <1520db83-9e0f-9973-f2e1-d2a91a3b3104@amd.com> <625cb85c-4d10-6912-48ad-971e809da0b8@amd.com> <20221207130121.5ce3fa18@hermes.local> In-Reply-To: From: Nathan Skrzypczak Date: Tue, 7 Feb 2023 18:26:33 +0100 Message-ID: Subject: Re: [PATCH v2] net/memif: default to physical socket To: Ferruh Yigit Cc: Stephen Hemminger , andrew.rybchenko@oktetlabs.ru, Jakub Grajciar , dev@dpdk.org Content-Type: multipart/alternative; boundary="000000000000a3232205f41f7318" X-Mailman-Approved-At: Wed, 08 Feb 2023 14:16:49 +0100 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 --000000000000a3232205f41f7318 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ferruh, Sorry for the late reply, You can probably drop this patch. Kind regards, -Nathan Le ven. 9 d=C3=A9c. 2022 =C3=A0 16:13, Ferruh Yigit = a =C3=A9crit : > On 12/8/2022 11:24 AM, Nathan Skrzypczak wrote: > > Hi Stephen, Hi Ferruh, > > > > I don't have a strong opinion on usage of regular sockets vs abstract > > sockets. My point is that most existing memif implementations > > either don't yet properly support abstract sockets or require extra > > flags to be passed by users (iirc VPP, gomemif, libmemif, etc...). > > As a matter of fact, abstract socket support in dpdk was broken until > > quite recently. So I expect most users to be somewhat > > constrained by their implementation to use regular sockets. > > > > Also, as a user when you come with a filesystem path, understanding you > > need to pass the following is not really straightforward > > --vdev=3Dnet_memif,socket=3D/tmp/memif.sock,socket-abstract=3Dno > > > > A better solution might be to use the '@' prefix which seems the usual > > representation and remove the socket-abstract=3Dno altogether > > --vdev=3Dnet_memif,socket=3D@memif > > --vdev=3Dnet_memif,socket=3D/tmp/memif.sock > > > > There is a default socket value ('/run/memif.sock'), that is why > additional 'socket-abstract' parameter is required: > > abstract socket: > --vdev=3Dnet_memif0 > > regular socket ('/run/memif.sock'): > --vdev=3Dnet_memif0,socket-abstract=3Dno > > > Using '@memif' syntax an option to *replace* 'socket-abstract=3Dno' > syntax, but this will break existing user interface. > > And if intentions is NOT replace usage, but add '@memif' syntax, it > doesn't add much value since abstract socket is already default option, > although it doesn't hurt. > > > > Instead, by keeping existing user interface, we can say if user > explicitly set a socket value, regular socket is implied, like: > > abstract: > --vdev=3Dnet_memif0 > --vdev=3Dnet_memif0,socket-abstract=3Dyes > --vdev=3Dnet_memif0,socket=3D/tmp/memif.sock,socket-abstract=3Dyes > [socket-abstract overrides] > > regular: > --vdev=3Dnet_memif0,socket=3D/tmp/memif.sock > --vdev=3Dnet_memif0,socket-abstract=3Dno > --vdev=3Dnet_memif0,socket=3D/tmp/memif.sock,socket-abstract=3Dno > > > Does this improve user experience for regular sockets? > > > > > What do you think ? > > > > (Also iirc Jakub is not receiving emails on this address) > > > > Cheers > > -Nathan > > > > Le mer. 7 d=C3=A9c. 2022 =C3=A0 22:01, Stephen Hemminger > > > a > =C3=A9crit : > > > > On Wed, 7 Dec 2022 17:15:06 +0000 > > Ferruh Yigit > > wrote: > > > > > On 12/7/2022 3:56 PM, Nathan Skrzypczak wrote: > > > > Hi Ferruh, > > > > > > > > > > Hi Nathan, > > > > > > > Thank you for your reply, > > > > > > > > On the potential confusion for users of the DPDK memif PMD : wh= en > > > > defaulting to abstract sockets was added in [0] (v20.10 release= ) > > > > it did change the existing behavior, so reverting it would > > restore the > > > > old behavior.> Also abstract sockets are quite a unusual featur= e > > in linux (a 0byte > > > > prefixed string...), so I'm expecting most users of memif to > > just use > > > > regular sockets because they're way easier to handle. > > > > > > > > > > Not sure if regular socket is easier to handle, or users prefer > > regular > > > sockets, we need more input on these. > > > > Regular sockets are actually harder handle, it is more that users > > are less familiar with them! Regular sockets have to go through > > file permission checks which makes dealing with containers and > SELinux > > hard. Regular sockets persist when application crashes which makes > > recovery harder. > > > > --000000000000a3232205f41f7318 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ferruh,

Sorry for the lat= e reply,
You can probably drop this patch.

Kind regards,
-Nathan

Le=C2=A0ven. 9 d=C3=A9c. 2022 = =C3=A0=C2=A016:13, Ferruh Yigit <ferruh.yigit@amd.com> a =C3=A9crit=C2=A0:
On 12/8/2022 11:24 AM, Nathan Skrzypczak = wrote:
> Hi Stephen, Hi Ferruh,
>
> I don't have a strong opinion on usage of regular sockets vs abstr= act
> sockets. My point is that most existing memif implementations
> either don't yet properly support abstract sockets or require extr= a
> flags to be passed by users (iirc VPP, gomemif, libmemif, etc...).
> As a matter of fact, abstract socket support in dpdk was broken until<= br> > quite recently. So I expect most users to be somewhat
> constrained by their implementation to use regular sockets.
>
> Also, as a user when you come with a filesystem path, understanding yo= u
> need to pass the following is not really straightforward
> --vdev=3Dnet_memif,socket=3D/tmp/memif.sock,socket-abstract=3Dno
>
> A better solution might be to use the '@' prefix which seems t= he usual
> representation and remove the socket-abstract=3Dno altogether
> --vdev=3Dnet_memif,socket=3D@memif
> --vdev=3Dnet_memif,socket=3D/tmp/memif.sock
>

There is a default socket value ('/run/memif.sock'), that is why additional 'socket-abstract' parameter is required:

abstract socket:
--vdev=3Dnet_memif0

regular socket ('/run/memif.sock'):
--vdev=3Dnet_memif0,socket-abstract=3Dno


Using '@memif' syntax an option to *replace* 'socket-abstract= =3Dno'
syntax, but this will break existing user interface.

And if intentions is NOT replace usage, but add '@memif' syntax, it=
doesn't add much value since abstract socket is already default option,=
although it doesn't hurt.



Instead, by keeping existing user interface, we can say if user
explicitly set a socket value, regular socket is implied, like:

abstract:
--vdev=3Dnet_memif0
--vdev=3Dnet_memif0,socket-abstract=3Dyes
--vdev=3Dnet_memif0,socket=3D/tmp/memif.sock,socket-abstract=3Dyes
[socket-abstract overrides]

regular:
--vdev=3Dnet_memif0,socket=3D/tmp/memif.sock
--vdev=3Dnet_memif0,socket-abstract=3Dno
--vdev=3Dnet_memif0,socket=3D/tmp/memif.sock,socket-abstract=3Dno


Does this improve user experience for regular sockets?



> What do you think ?
>
> (Also iirc Jakub is not receiving emails on this address)
>
> Cheers
> -Nathan
>
> Le=C2=A0mer. 7 d=C3=A9c. 2022 =C3=A0=C2=A022:01, Stephen Hemminger
> <st= ephen@networkplumber.org <mailto:stephen@networkplumber.org>> a =C3= =A9crit=C2=A0:
>
>=C2=A0 =C2=A0 =C2=A0On Wed, 7 Dec 2022 17:15:06 +0000
>=C2=A0 =C2=A0 =C2=A0Ferruh Yigit <ferruh.yigit@amd.com <mailto:ferruh.yigit@amd.com>>= wrote:
>
>=C2=A0 =C2=A0 =C2=A0> On 12/7/2022 3:56 PM, Nathan Skrzypczak wrote:=
>=C2=A0 =C2=A0 =C2=A0> > Hi Ferruh,
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Hi Nathan,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> > Thank you for your reply,=C2=A0
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> > On the potential confusion for users of t= he DPDK memif PMD : when
>=C2=A0 =C2=A0 =C2=A0> > defaulting to abstract sockets was added = in [0] (v20.10 release)
>=C2=A0 =C2=A0 =C2=A0> > it did change the existing behavior, so r= everting it would
>=C2=A0 =C2=A0 =C2=A0restore the
>=C2=A0 =C2=A0 =C2=A0> > old behavior.> Also abstract sockets a= re quite a unusual feature
>=C2=A0 =C2=A0 =C2=A0in linux (a 0byte
>=C2=A0 =C2=A0 =C2=A0> > prefixed string...), so I'm expecting= most users of memif to
>=C2=A0 =C2=A0 =C2=A0just use
>=C2=A0 =C2=A0 =C2=A0> > regular sockets because they're way e= asier to handle.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Not sure if regular socket is easier to handle= , or users prefer
>=C2=A0 =C2=A0 =C2=A0regular
>=C2=A0 =C2=A0 =C2=A0> sockets, we need more input on these.
>
>=C2=A0 =C2=A0 =C2=A0Regular sockets are actually harder handle, it is m= ore that users
>=C2=A0 =C2=A0 =C2=A0are less familiar with them! Regular sockets have t= o go through
>=C2=A0 =C2=A0 =C2=A0file permission checks which makes dealing with con= tainers and SELinux
>=C2=A0 =C2=A0 =C2=A0hard.=C2=A0 Regular sockets persist when applicatio= n crashes which makes
>=C2=A0 =C2=A0 =C2=A0recovery harder.
>

--000000000000a3232205f41f7318--