DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: Jakub Grajciar <jgrajcia@cisco.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] net/memif: use abstract socket address
Date: Mon, 5 Oct 2020 11:17:11 -0700
Message-ID: <20201005111711.1e78ee0d@hermes.local> (raw)
In-Reply-To: <5b874482-baaa-1a65-b101-983aa3bff5ee@intel.com>

On Mon, 5 Oct 2020 14:09:20 +0100
Ferruh Yigit <ferruh.yigit@intel.com> wrote:

> On 10/5/2020 1:39 PM, Jakub Grajciar wrote:
> > Abstract socket address has no connection with
> > filesystem pathnames and the socket dissapears
> > once all open references are closed.
> > 
> > Memif pmd will use abstract socket address by default.
> > For backwards compatibility use new argument
> > 'socket-abstract=no'
> >   
> Why this backward compatibility is required? How the end user affected from 
> swithching to abstract sockets?

It would only matter if mixing applications with different versions.

> Since when linux supports abstract sockets, does this switch will cause problem 
> with old kernel versions?

This is not new, it dates back to Linux 2.4 or earlier.

> Is there any benefit of the abstract sockets other than socket cleaned 
> automatically (I assume for unix sockets it is done when file filesystem 
> reference removed)?

The big one is that applications don't have to blindly unlink the old filesystem
remnant. This means that if application can't bind it means another application
is still running with that name. So abstract sockets are safer.

Abstract sockets are not pathnames so they get handled differently by security
systems (like SELinux and AppArmor). This can be helpful in containers.

  parent reply	other threads:[~2020-10-05 18:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05 12:39 Jakub Grajciar
2020-10-05 13:09 ` Ferruh Yigit
2020-10-05 15:23   ` Jakub Grajciar -X (jgrajcia - PANTHEON TECH SRO at Cisco)
2020-10-05 18:17   ` Stephen Hemminger [this message]
2020-10-06  8:59     ` Ferruh Yigit
2020-10-07 10:00 ` [dpdk-dev] [PATCH v2] " Jakub Grajciar
2020-10-09 16:58   ` [dpdk-dev] [PATCH v3] " Jakub Grajciar
2020-10-09 17:17     ` Ferruh Yigit
2020-10-12  8:28     ` [dpdk-dev] [PATCH v4] " Jakub Grajciar
2020-10-12 14:57       ` Ferruh Yigit
2020-10-12 15:17       ` Stephen Hemminger
2020-10-07 15:03 ` [dpdk-dev] [PATCH] " Stephen Hemminger
2020-10-09 15:09   ` Ferruh Yigit

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:

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

  git send-email \
    --in-reply-to=20201005111711.1e78ee0d@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jgrajcia@cisco.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git