for stacked VLANs, but the current net/dsa
> supported chips don't handle those anyway.)
Sounds like a good start - we could have a different interface for
stacked variants. I think you should push in the patch.
cheers,
jamal
--
To unsubscribe from this list: send the line "un
levels.
Yes, that would provide a solution.
I havent seen anything where you can rate limit the learning(SA lookup
failure).
cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
Even at 4 port switch at 100Mbs, hitting 500Kpps to the CPU (I am
thinking these tiny switches end up in some tiny MIPS/ARM cpu) could
be devastating. How do you deal with that?
cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a messag
.e s/ware only.
IOW, I would make that the 0.
cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
idges. Does this proposal meet that requirement?
> >
I dont see any issues with those requirements being met.
> Jamal, so why do "They have to be different calls"? I'm not so sure anymore...
> moving to RTM_FDB_XXXENTRY saved some refactoring in the bridge module but
> that
ending this RFC,
>
> [RFC] hardware bridging support for DSA switches
> http://patchwork.ozlabs.org/patch/16578/
Certainly - thats one approach that is reasonable.
Where is Lennert? ;-> I changed his email address to one that i am
familiar with.
cheers,
jamal
--
To unsubscribe fro
On Tue, 2012-02-28 at 21:14 -0800, John Fastabend wrote:
> Just checked looks like the DSA infrastructure has commands to enable
> STP so guess it is doing learning.
IIRC, Lennert built some of this stuff tied to the kernel.
cheers,
jamal
--
To unsubscribe from this list: send th
t; Plus there is already a proliferation of LINK attributes and dumping
> the FDB out of this seems a bit much but could be done with some
> bitmasks. Although the current ext_filter_mask u32 doesn't seem to
> be sufficient for events to trigger this.
Dumping the FDB table should be som
ve the
> synchronization into a user space daemon.
Yep.
Thanks for listening John. Waiting to see them patches.
cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t becomes impossible or at
> least very disruptive to migrate it to another host that doesn't have a
> compatible VF available.
In the scheme i described to John in last email, libvirt needs not be aware of
existence of hardware offloading (and migration should be transparent of whether
On Wed, 2012-02-15 at 17:26 -0800, John Fastabend wrote:
> On 2/15/2012 6:10 AM, Jamal Hadi Salim wrote:
> > On Tue, 2012-02-14 at 10:57 -0800, John Fastabend wrote:
> >
> >> Roopa was likely on the right track here,
> >>
> >> http://patchwork.ozlabs.org/
door. Even in
Canada with a default policy of not locking your door we sometimes lock
our doors ;->
> I have no problem with drawing the line here and trying to implement something
> over PF_BRIDGE:RTM_xxx nlmsgs.
My comment/concern was in regard to the bridge built-in policy of
readi
have. I can go and add YAK (Yet Another Knob) - but where
is the line drawn?
cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
quare peg in round hole.
Agreed.
cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
bloats.
I am always bigoted to move all policy control to user space instead of
bloating in the kernel.
On Thu, 2012-02-09 at 20:14 -0800, John Fastabend wrote:
> >
> > Hi Jamal,
> >
> > The user space app in this case would listen for FDB updates to the SW
> > brid
further.
This stuff shouldnt be in the kernel at all.
The disadvantage is you need a user space app to update the hardware.
i.e, the same mechanism should be usable for either a switch embedded
in a NIC or a standalone hardware switch (with/out the s/ware bridge
presence)
cheers,
jamal
--
To u
16 matches
Mail list logo
