On Thu, Jun 11, 2015 at 6:00 AM, Jamal Hadi Salim wrote:
> Full quote below. So what is the consensus on this topic?
> I read the emails but i dont see a resolution.
I think I dropped the ball on this one. I'll go ahead and submit the
last patch I posted to this email thread to resume the conver
Full quote below. So what is the consensus on this topic?
I read the emails but i dont see a resolution.
cheers,
jamal
On 06/03/15 08:08, Jamal Hadi Salim wrote:
On 06/02/15 10:30, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 4:43 AM, Jamal Hadi Salim
wrote:
On 06/02/15 03:10, Scott Feldman w
On 6/4/15, 8:04 AM, Toshiaki Makita wrote:
On 15/06/04 (木) 3:41, roopa wrote:
On 6/3/15, 8:43 AM, Toshiaki Makita wrote:
On 15/06/03 (水) 4:01, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 9:58 AM, roopa
wrote:
On 6/2/15, 7:30 AM, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 4:43 AM, Jamal Ha
On 15/06/04 (木) 3:41, roopa wrote:
On 6/3/15, 8:43 AM, Toshiaki Makita wrote:
On 15/06/03 (水) 4:01, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 9:58 AM, roopa wrote:
On 6/2/15, 7:30 AM, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 4:43 AM, Jamal Hadi Salim
wrote:
On 06/02/15 03:10, Scott
On 15/06/04 (木) 15:05, Scott Feldman wrote:
On Thu, 4 Jun 2015, Toshiaki Makita wrote:
Bridge's vlan_filtering is handled in master->op->foo(), not in
port->op->foo().
Can't we introduce another switchdev handler that performs MASTER
operation instead of calling SELF operation?
br_afspec()
nbp
On Thu, 4 Jun 2015, Toshiaki Makita wrote:
Bridge's vlan_filtering is handled in master->op->foo(), not in
port->op->foo().
Can't we introduce another switchdev handler that performs MASTER operation
instead of calling SELF operation?
br_afspec()
nbp_vlan_add()
netdev_switch_port_vlan_add(
On 6/3/15, 8:43 AM, Toshiaki Makita wrote:
On 15/06/03 (水) 4:01, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 9:58 AM, roopa wrote:
On 6/2/15, 7:30 AM, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 4:43 AM, Jamal Hadi Salim
wrote:
On 06/02/15 03:10, Scott Feldman wrote:
Actually, we're no
On 6/2/15, 12:01 PM, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 9:58 AM, roopa wrote:
On 6/2/15, 7:30 AM, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 4:43 AM, Jamal Hadi Salim wrote:
On 06/02/15 03:10, Scott Feldman wrote:
Actually, we're now consistent with bridge man page which says ma
On 15/06/03 (水) 4:01, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 9:58 AM, roopa wrote:
On 6/2/15, 7:30 AM, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 4:43 AM, Jamal Hadi Salim wrote:
On 06/02/15 03:10, Scott Feldman wrote:
Actually, we're now consistent with bridge man page which says
On 06/02/15 10:30, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 4:43 AM, Jamal Hadi Salim wrote:
On 06/02/15 03:10, Scott Feldman wrote:
Question to ask when looking at something of this nature:
Will it work with no suprises if you used today's unmodified app?
The default behavior shouldnt c
On Tue, Jun 2, 2015 at 9:58 AM, roopa wrote:
> On 6/2/15, 7:30 AM, Scott Feldman wrote:
>>
>> On Tue, Jun 2, 2015 at 4:43 AM, Jamal Hadi Salim wrote:
>>>
>>> On 06/02/15 03:10, Scott Feldman wrote:
>>>
>>>
Actually, we're now consistent with bridge man page which says master
is the defa
On 6/2/15, 7:30 AM, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 4:43 AM, Jamal Hadi Salim wrote:
On 06/02/15 03:10, Scott Feldman wrote:
Actually, we're now consistent with bridge man page which says master
is the default.
Want we want, I believe, is to adjust what the man page says (and th
On Tue, Jun 2, 2015 at 4:43 AM, Jamal Hadi Salim wrote:
> On 06/02/15 03:10, Scott Feldman wrote:
>
>
>> Actually, we're now consistent with bridge man page which says master
>> is the default.
>>
>> Want we want, I believe, is to adjust what the man page says (and the
>> bridge vlan command itsel
On 06/02/15 03:10, Scott Feldman wrote:
Actually, we're now consistent with bridge man page which says master
is the default.
Want we want, I believe, is to adjust what the man page says (and the
bridge vlan command itself), by making the default master and self.
The kernel and driver are fine
On Mon, Jun 1, 2015 at 10:24 PM, David Miller wrote:
> From: Toshiaki Makita
> Date: Tue, 02 Jun 2015 13:51:06 +0900
>
>> On 2015/06/02 3:39, sfel...@gmail.com wrote:
>>> From: Scott Feldman
>>>
>>> Remove support for legacy ndo ops
>>> .ndo_vlan_rx_add_vid/.ndo_vlan_rx_kill_vid. Rocker will us
On 2015/06/02 14:24, David Miller wrote:
> From: Toshiaki Makita
> Date: Tue, 02 Jun 2015 13:51:06 +0900
>
>> On 2015/06/02 3:39, sfel...@gmail.com wrote:
>>> From: Scott Feldman
>>>
>>> Remove support for legacy ndo ops
>>> .ndo_vlan_rx_add_vid/.ndo_vlan_rx_kill_vid. Rocker will use
>>> bridge
From: Toshiaki Makita
Date: Tue, 02 Jun 2015 13:51:06 +0900
> On 2015/06/02 3:39, sfel...@gmail.com wrote:
>> From: Scott Feldman
>>
>> Remove support for legacy ndo ops
>> .ndo_vlan_rx_add_vid/.ndo_vlan_rx_kill_vid. Rocker will use
>> bridge_setlink/dellink exclusively for VLAN add/del operat
On 2015/06/02 3:39, sfel...@gmail.com wrote:
> From: Scott Feldman
>
> Remove support for legacy ndo ops
> .ndo_vlan_rx_add_vid/.ndo_vlan_rx_kill_vid. Rocker will use
> bridge_setlink/dellink exclusively for VLAN add/del operations.
>
> The legacy ops are needed if using 8021q driver module to
From: Scott Feldman
Remove support for legacy ndo ops
.ndo_vlan_rx_add_vid/.ndo_vlan_rx_kill_vid. Rocker will use
bridge_setlink/dellink exclusively for VLAN add/del operations.
The legacy ops are needed if using 8021q driver module to setup VLANs on
the port. But an alternative exists in usin
19 matches
Mail list logo
