Hi Scott,
On Jul 29, 2015, at 5:17 PM, Scott Feldman sfel...@gmail.com wrote:
> On Wed, Jul 29, 2015 at 12:14 PM, Vivien Didelot
> wrote:
>> Hi Scott, David,
>>
>> On Jul 29, 2015, at 2:28 PM, David da...@davemloft.net wrote:
>>
>>> From: Scott Feldman
>>> Date: Wed, 29 Jul 2015 00:31:44 -0700
On Wed, Jul 29, 2015 at 12:14 PM, Vivien Didelot
wrote:
> Hi Scott, David,
>
> On Jul 29, 2015, at 2:28 PM, David da...@davemloft.net wrote:
>
>> From: Scott Feldman
>> Date: Wed, 29 Jul 2015 00:31:44 -0700
>>
>>> Since the netlink request (for example vlan add) includes the range,
>>> I'm not se
From: Vivien Didelot
Date: Wed, 29 Jul 2015 15:14:05 -0400 (EDT)
> While a range might be convenient to a user, exposing it to drivers is
> likely to end up writing the same vid_begin to vid_end for loop.
It is impossible not to expose this to the driver.
We have to have a prepare/commit sequen
Hi Scott, David,
On Jul 29, 2015, at 2:28 PM, David da...@davemloft.net wrote:
> From: Scott Feldman
> Date: Wed, 29 Jul 2015 00:31:44 -0700
>
>> 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
From: Scott Feldman
Date: Wed, 29 Jul 2015 00:31:44 -0700
> 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
On Sun, Jul 26, 2015 at 4:45 PM, Vivien Didelot
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
