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 F3C66A034C; Mon, 12 Dec 2022 12:16:57 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CB7A540A89; Mon, 12 Dec 2022 12:16:53 +0100 (CET) Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by mails.dpdk.org (Postfix) with ESMTP id 3877840A7E for ; Thu, 8 Dec 2022 12:25:00 +0100 (CET) Received: by mail-ej1-f45.google.com with SMTP id x22so3062028ejs.11 for ; Thu, 08 Dec 2022 03:25:00 -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=k0dI7tkUAVJAr+4hOdefTvwRFLrzisDbnfcO47yuEeg=; b=iIbt+FXwi8YLAlWtiknu+RG63wd0JuklggEVi47IY7uF3rt2ECISxgYQ3aXf3DVOQy XHZdDWxJPQAMAw4X3tuADjZprm3JdQXyMnDhcCrF92qp+xyn0tLj7I5RxlfKOZhDGnd/ qEGgzszxvgAN71tws7H65fO7dq+FX91MGqp1Z3Pi1ny3gUcHsqOwkcuwc7lWNnOQ55D0 MdHV1VANlS0xxBg1935me6Y5TxtVncw1yye4rbZpAJC5T4qoBNSqRLxU+sNtj9js0S6K sc6wYd+qAWZMW0ameUiFtHYZwuhdazw1xj0qV6Q9ZYmIM9wa8ofrKO0tSb4jwqlPEtl1 Kt5A== 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=k0dI7tkUAVJAr+4hOdefTvwRFLrzisDbnfcO47yuEeg=; b=DPC+Ghewko4LiB3OzxUmLmVNh75egeppoQUkBVFwSi8VSOULDZFyzvnUj59vMbTYmE 2+2V3Aq4TUHHv3DSRrSeullHfALJ6BE/4nAlzwUJ3dBAny/LPTQpbRE2ggq/Aad5vH0N qw9bcbQyXt8RfSI4b+lOjqC+gNvQVr1Y9eJtc2ojZQxYLOYoQD8Syqa+7Juoak8adJ8F okaeSYdincRWsRr+ifFjD9tGa6uUucwtaDS66g4EroFfqft1cdnk6OMuBYgV4wgS+9jH 3EpysaTyOoP40wzhJUMPhnul8Swxm6GZyciDi2xtZtYns+PX3MJAlQMNa6Y+/97VvUh4 ysrQ== X-Gm-Message-State: ANoB5pkfI9Y2moHvBgoXeCWROHwccprxMOvOsGXU9xwJTQBD9O8SDcEx eic6QfWPEhRrAicSiHONZm2XP6wJV4XukUKBBQc= X-Google-Smtp-Source: AA0mqf5ZlwhD7Ny1bjgf67yxFfUu8tlYWmjAwWcVM9V6AAVXGvzoiE8RsdPr5ra1OyRnA8hseorczRp7utXNjKu9WaQ= X-Received: by 2002:a17:906:805:b0:78d:8267:3379 with SMTP id e5-20020a170906080500b0078d82673379mr77625420ejd.415.1670498699764; Thu, 08 Dec 2022 03:24:59 -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: <20221207130121.5ce3fa18@hermes.local> From: Nathan Skrzypczak Date: Thu, 8 Dec 2022 12:24:48 +0100 Message-ID: Subject: Re: [PATCH v2] net/memif: default to physical socket To: Stephen Hemminger Cc: Ferruh Yigit , andrew.rybchenko@oktetlabs.ru, Jakub Grajciar , dev@dpdk.org Content-Type: multipart/alternative; boundary="00000000000098ea6905ef4f491b" X-Mailman-Approved-At: Mon, 12 Dec 2022 12:16:51 +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 --00000000000098ea6905ef4f491b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 : when > > > defaulting to abstract sockets was added in [0] (v20.10 release) > > > it did change the existing behavior, so reverting it would restore th= e > > > old behavior.> Also abstract sockets are quite a unusual feature 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. > --00000000000098ea6905ef4f491b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Stephen, Hi Ferruh,

I don= 't have a strong opinion on usage of regular sockets vs abstract socket= s. My point is that most existing memif implementations
eith= er don't yet properly support abstract sockets or require extra flags t= o be passed by users (iirc VPP, gomemif, libmemif, etc...).
As a = matter of fact, abstract socket support in dpdk was broken until quite rece= ntly. So I expect most users to be somewhat
constrained by t= heir 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_memi= f,socket=3D/tmp/memif.sock

What do you think ?

(Also iirc Jakub is not receiving emails on this addr= ess)

Cheers
-Nathan
<= br>
Le=C2= =A0mer. 7 d=C3=A9c. 2022 =C3=A0=C2=A022:01, Stephen Hemminger <stephen@networkplumber.org> a= =C3=A9crit=C2=A0:
On Wed, 7 Dec 2022 17:15:06 +0000
Ferruh Yigit <= ferruh.yigit@amd.com> wrote:

> On 12/7/2022 3:56 PM, Nathan Skrzypczak wrote:
> > Hi Ferruh,
> >=C2=A0 =C2=A0
>
> Hi Nathan,
>
> > Thank you for your reply,=C2=A0
> >
> > On the potential confusion for users of the DPDK memif PMD : when=
> > defaulting to abstract sockets was added in [0] (v20.10 release)<= br> > > it did change the existing behavior, so reverting it would restor= e the
> > old behavior.> Also abstract sockets are quite a unusual featu= re 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.
> >=C2=A0 =C2=A0
>
> Not sure if regular socket is easier to handle, or users prefer regula= r
> 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.=C2=A0 Regular sockets persist when application crashes which makes recovery harder.
--00000000000098ea6905ef4f491b--