DPDK patches and discussions
 help / color / mirror / Atom feed
From: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Ferruh Yigit <ferruh.yigit@amd.com>,
	andrew.rybchenko@oktetlabs.ru,
	 Jakub Grajciar <jgrajcia@cisco.com>,
	dev@dpdk.org
Subject: Re: [PATCH v2] net/memif: default to physical socket
Date: Thu, 8 Dec 2022 12:24:48 +0100	[thread overview]
Message-ID: <CABsT2sOv+9eREFT5rvtk3X5KPdHCnJV30UAMc62c4xxsU_5ssw@mail.gmail.com> (raw)
In-Reply-To: <20221207130121.5ce3fa18@hermes.local>

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

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

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>
a écrit :

> 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,
> > >
> >
> > 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: 2967 bytes --]

  reply	other threads:[~2022-12-12 11:16 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 [this message]
2022-12-09 15:13             ` Ferruh Yigit
2023-02-07 17:26               ` Nathan Skrzypczak

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=CABsT2sOv+9eREFT5rvtk3X5KPdHCnJV30UAMc62c4xxsU_5ssw@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).