Hi,
On 08.09.2020 11:04, Henrik Bjoernlund - M31679 wrote:
On Sun, 2020-09-06 at 20:21 +0200, Horatiu Vultur wrote:
The 09/04/2020 15:44, Stephen Hemminger wrote:
> On Fri, 4 Sep 2020 09:15:20 +0000 Henrik Bjoernlund
> <henrik.bjoernlund@xxxxxxxxxxxxx> wrote:
Hi, I also had the same initial thought - this really doesn't seem to
affect the bridge in any way, it's only collecting and transmitting
information. I get that you'd like to use the bridge as a passthrough
device to switchdev to program your hw, could you share what would be
offloaded more specifically ?
Yes.
The HW will offload the periodic sending of CCM frames, and the
reception.
If CCM frames are not received as expected, it will raise an interrupt.
This means that all the functionality provided in this series will be
offloaded to HW.
The offloading is very important on our HW where we have a small CPU,
serving many ports, with a high frequency of CFM frames.
The HW also support Link-Trace and Loop-back, which we may come back to
later.
All you do - snooping and blocking these packets can easily be done
from user- space with the help of ebtables, but since we need to have
a software implementation/fallback of anything being offloaded via
switchdev we might need this after all, I'd just prefer to push as
much as possible to user-space.
In addition to Henriks comment, it is worth mentioning that we are
trying to push as much of the functionallity to user-space (learnings
from the MRP discussions).
This is why there are currently no in-kernel users of the CCM-lose
singnal. When a CCM-defect is happening the network typically needs to
be re-configured. This we are trying to keep in user-space.
I plan to review the individual patches tomorrow.
Thanks.
/Allan
