All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Feldman <sfeldma@gmail.com>
To: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Netdev <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jiri Pirko <jiri@resnulli.us>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kernel <kernel@savoirfairelinux.com>
Subject: Re: [PATCH] net: switchdev: restrict vid range abstraction
Date: Wed, 29 Jul 2015 00:31:44 -0700	[thread overview]
Message-ID: <CAE4R7bA5jh3Rgn_U1Sit3qW+i2vKNE++c9TYTJ8sp5j8h=awbw@mail.gmail.com> (raw)
In-Reply-To: <1437954348-11859-1-git-send-email-vivien.didelot@savoirfairelinux.com>

On Sun, Jul 26, 2015 at 4:45 PM, Vivien Didelot
<vivien.didelot@savoirfairelinux.com> wrote:
> This patch replaces the vid_begin and vid_end members of the
> switchdev_obj_vlan structure for a single vid member. This way, the VID
> range abstraction is restricted to switchdev, not exposed to drivers.
>
> The main benefice to do so is to allow the prepare phase to be called
> for each VID, not only once for the whole range.
>
> For example, when adding VLANs 2-5, a switch chip may not be able to add
> hardware VLAN 2 due to some bridge restriction (thus must return
> -EOPNOTSUPP), while VLAN 3-5 are allowed.

Hi Vivien,

Since the netlink request (for example vlan add) includes the range,
I'm not seeing how we can response with success for the satisfied
vlans in the range, and also respond with an error for the unsatisfied
vlans in the range.   In other words, from the netlink msgs
perspective, we need to treat a vlan range as all-or-nothing.  So in
your example, if hw can't add vlan 2, we fail the entire request to
add range 2-5.  This is where the prepare phase checks to make sure
the entire request can be satisfied before committing to hw.

-scott

  reply	other threads:[~2015-07-29  7:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-26 23:45 [PATCH] net: switchdev: restrict vid range abstraction Vivien Didelot
2015-07-29  7:31 ` Scott Feldman [this message]
2015-07-29 18:28   ` David Miller
2015-07-29 19:14     ` Vivien Didelot
2015-07-29 19:28       ` David Miller
2015-07-29 21:17       ` Scott Feldman
2015-08-01  1:02         ` Vivien Didelot

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='CAE4R7bA5jh3Rgn_U1Sit3qW+i2vKNE++c9TYTJ8sp5j8h=awbw@mail.gmail.com' \
    --to=sfeldma@gmail.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=jiri@resnulli.us \
    --cc=kernel@savoirfairelinux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@savoirfairelinux.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.