linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vadym Kochan <vadym.kochan@plvision.eu>
To: David Miller <davem@davemloft.net>
Cc: kuba@kernel.org, jiri@mellanox.com, idosch@mellanox.com,
	andrew@lunn.ch, oleksandr.mazur@plvision.eu,
	serhiy.boiko@plvision.eu, serhiy.pshyk@plvision.eu,
	volodymyr.mytnyk@plvision.eu, taras.chornyi@plvision.eu,
	andrii.savka@plvision.eu, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, andy.shevchenko@gmail.com,
	mickeyr@marvell.com
Subject: Re: [net-next v5 1/6] net: marvell: prestera: Add driver for Prestera family ASIC devices
Date: Sun, 30 Aug 2020 10:49:58 +0300	[thread overview]
Message-ID: <20200830074958.GA2568@plvision.eu> (raw)
In-Reply-To: <20200826.073446.971357864812593855.davem@davemloft.net>

Hi David,

On Wed, Aug 26, 2020 at 07:34:46AM -0700, David Miller wrote:
> From: Vadym Kochan <vadym.kochan@plvision.eu>
> Date: Wed, 26 Aug 2020 11:17:44 +0300
> 
> > Initially there was (in RFC patch set), not locking, but _rcu list API
> > used, because the port list is modified only by 1 writer when creating
> > the port or deleting it on switch uninit (the really theoretical case
> > which might happen is that event might be received at that time which
> > causes to loop over this list to find the port), as I understand
> > correctly list_add_rcu is safe to use with no additional locking if there is 1
> > writer and many readers ? So can I use back this approach ?
> 
> Are you really certain only one writer can exist at one time?

Yes, list_add() is called on:

    prestera_pci_probe() -> prestera_device_register() -> prestera_switch_init() -> prestera_create_ports()

and list_del() is called on:

    prestera_pci_remove() -> prestera_device_unregister() -> prestera_switch_fini() -> prestera_destroy_ports()

in all other cases the port_list is used for port lookup on rx or when
event is received from the fw. So I really think that at least RCU list
API might be used or rw lock. In early version the ports were creating
before fw event handlers registration, but in this version the ports are
creating after event handlers are registered so it really needs locking.

Regarding DMA comments, looks like I can get rid of those bounce buffer
handling because swiotlb can handle this ? In that case looks like just
DMA map/unmap and sync should be enough.

Regards,
Vadym Kochan

  reply	other threads:[~2020-08-30  7:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-25 12:20 [net-next v5 0/6] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX326x (AC3x) Vadym Kochan
2020-08-25 12:20 ` [net-next v5 1/6] net: marvell: prestera: Add driver for Prestera family ASIC devices Vadym Kochan
2020-08-26  0:20   ` David Miller
2020-08-26  8:17     ` Vadym Kochan
2020-08-26 13:04       ` Andrew Lunn
2020-08-26 14:34       ` David Miller
2020-08-30  7:49         ` Vadym Kochan [this message]
2020-08-25 12:20 ` [net-next v5 2/6] net: marvell: prestera: Add PCI interface support Vadym Kochan
2020-08-25 12:20 ` [net-next v5 3/6] net: marvell: prestera: Add basic devlink support Vadym Kochan
2020-08-25 12:20 ` [net-next v5 4/6] net: marvell: prestera: Add ethtool interface support Vadym Kochan
2020-08-25 12:20 ` [net-next v5 5/6] net: marvell: prestera: Add Switchdev driver implementation Vadym Kochan
2020-08-25 12:20 ` [net-next v5 6/6] dt-bindings: marvell,prestera: Add description for device-tree bindings Vadym Kochan
2020-08-26  4:30 ` [net-next v5 0/6] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX326x (AC3x) Chris Packham
2020-08-30  8:00   ` Vadym Kochan

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=20200830074958.GA2568@plvision.eu \
    --to=vadym.kochan@plvision.eu \
    --cc=andrew@lunn.ch \
    --cc=andrii.savka@plvision.eu \
    --cc=andy.shevchenko@gmail.com \
    --cc=davem@davemloft.net \
    --cc=idosch@mellanox.com \
    --cc=jiri@mellanox.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mickeyr@marvell.com \
    --cc=netdev@vger.kernel.org \
    --cc=oleksandr.mazur@plvision.eu \
    --cc=serhiy.boiko@plvision.eu \
    --cc=serhiy.pshyk@plvision.eu \
    --cc=taras.chornyi@plvision.eu \
    --cc=volodymyr.mytnyk@plvision.eu \
    /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).