DPDK patches and discussions
 help / color / mirror / Atom feed
From: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	andrew.rybchenko@oktetlabs.ru,
	 Jakub Grajciar <jgrajcia@cisco.com>,
	dev@dpdk.org
Subject: Re: [PATCH v2] net/memif: default to physical socket
Date: Tue, 7 Feb 2023 18:26:33 +0100	[thread overview]
Message-ID: <CABsT2sPo+fAkdTi_rf=2zUB2xJJpyWw-X5JNUujimoL0Zc4wNw@mail.gmail.com> (raw)
In-Reply-To: <c04224c8-2e58-a553-0266-6bf2650abef7@amd.com>

[-- Attachment #1: Type: text/plain, Size: 3931 bytes --]

Hi Ferruh,

Sorry for the late reply,
You can probably drop this patch.

Kind regards,
-Nathan

Le ven. 9 déc. 2022 à 16:13, Ferruh Yigit <ferruh.yigit@amd.com> a écrit :

> 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=net_memif,socket=/tmp/memif.sock,socket-abstract=no
> >
> > A better solution might be to use the '@' prefix which seems the usual
> > representation and remove the socket-abstract=no altogether
> > --vdev=net_memif,socket=@memif
> > --vdev=net_memif,socket=/tmp/memif.sock
> >
>
> There is a default socket value ('/run/memif.sock'), that is why
> additional 'socket-abstract' parameter is required:
>
> abstract socket:
> --vdev=net_memif0
>
> regular socket ('/run/memif.sock'):
> --vdev=net_memif0,socket-abstract=no
>
>
> Using '@memif' syntax an option to *replace* 'socket-abstract=no'
> 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=net_memif0
> --vdev=net_memif0,socket-abstract=yes
> --vdev=net_memif0,socket=/tmp/memif.sock,socket-abstract=yes
> [socket-abstract overrides]
>
> regular:
> --vdev=net_memif0,socket=/tmp/memif.sock
> --vdev=net_memif0,socket-abstract=no
> --vdev=net_memif0,socket=/tmp/memif.sock,socket-abstract=no
>
>
> 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éc. 2022 à 22:01, Stephen Hemminger
> > <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> a
> écrit :
> >
> >     On Wed, 7 Dec 2022 17:15:06 +0000
> >     Ferruh Yigit <ferruh.yigit@amd.com <mailto:ferruh.yigit@amd.com>>
> 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 the
> >     > > 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.
> >
>
>

[-- Attachment #2: Type: text/html, Size: 5231 bytes --]

      reply	other threads:[~2023-02-08 13:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-10 10:40 [PATCH] " Nathan Skrzypczak
2022-10-17 12:12 ` [PATCH v2] " Nathan Skrzypczak
2022-12-07 15:14   ` Ferruh Yigit
2022-12-07 15:56     ` Nathan Skrzypczak
2022-12-07 17:15       ` Ferruh Yigit
2022-12-07 21:01         ` Stephen Hemminger
2022-12-08 11:24           ` Nathan Skrzypczak
2022-12-09 15:13             ` Ferruh Yigit
2023-02-07 17:26               ` Nathan Skrzypczak [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABsT2sPo+fAkdTi_rf=2zUB2xJJpyWw-X5JNUujimoL0Zc4wNw@mail.gmail.com' \
    --to=nathan.skrzypczak@gmail.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=jgrajcia@cisco.com \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).