[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <551ABF47.5030508@cumulusnetworks.com>
Date: Tue, 31 Mar 2015 08:37:43 -0700
From: roopa <roopa@...ulusnetworks.com>
To: Scott Feldman <sfeldma@...il.com>
CC: "Arad, Ronen" <ronen.arad@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"jiri@...nulli.us" <jiri@...nulli.us>,
"linux@...ck-us.net" <linux@...ck-us.net>,
"f.fainelli@...il.com" <f.fainelli@...il.com>
Subject: Re: [PATCH net-next 02/18] switchdev: flesh out get/set attr ops
On 3/30/15, 5:38 PM, Scott Feldman wrote:
> On Mon, Mar 30, 2015 at 5:22 PM, Arad, Ronen <ronen.arad@...el.com> wrote:
>>
>>> -----Original Message-----
>>> From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org] On
>>> Behalf Of sfeldma@...il.com
>>> Sent: Monday, March 30, 2015 1:40 AM
>>> To: netdev@...r.kernel.org
>>> Cc: jiri@...nulli.us; roopa@...ulusnetworks.com; linux@...ck-us.net;
>>> f.fainelli@...il.com
>>> Subject: [PATCH net-next 02/18] switchdev: flesh out get/set attr ops
>>>
>>> From: Scott Feldman <sfeldma@...il.com>
>>>
>> [cut]
>>> int swdev_port_attr_set(struct net_device *dev, struct swdev_attr *attr)
>>> {
>>> - return -EOPNOTSUPP;
>>> + struct swdev_attr prev = *attr;
>>> + int err, get_err;
>>> +
>>> + get_err = swdev_port_attr_get(dev, &prev);
>>> +
>>> + err = _swdev_port_attr_set(dev, attr);
>>> + if (err && !get_err && !(attr->flags & SWDEV_ATTR_F_NO_RECOVER))
>>> + /* Some err on set: revert to previous value */
>>> + _swdev_port_attr_set(dev, &prev);
>> Netlink requests could contain multiple attributes within a single request.
>> Reverting to the previous value applies only to the first
>> swdev_port_attr_set error. It does not rollback all prior changes that
>> were triggered by the same Netlink request.
> Since attr_set scope is a single attr across ports, it can only revert
> that attr for those ports. So rewinding multiple attributes needs to
> happen above attr_set. I guess we could have a multi_attr_set that
> takes an array of *attrs, but something like this can be built on top
> of attr_set. Maybe baby steps is best first so we can see how things
> shape up.
Having a multi attr set/del is necessary in some cases where the hw api
may be able to handle more than one attr set/del. I can see this
especially in the vlan case. Having the driver get all attributes and do
the necessary optimizations to program hardware might be better.
thanks,
Roopa
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists