From: Andrew Lunn <andrew@lunn.ch>
To: Horatiu Vultur <horatiu.vultur@microchip.com>
Cc: Vladimir Oltean <olteanv@gmail.com>,
Nikolay Aleksandrov <nikolay@cumulusnetworks.com>,
lkml <linux-kernel@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
bridge@lists.linux-foundation.org,
"David S. Miller" <davem@davemloft.net>,
Roopa Prabhu <roopa@cumulusnetworks.com>,
Jakub Kicinski <jakub.kicinski@netronome.com>,
Vivien Didelot <vivien.didelot@gmail.com>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
anirudh.venkataramanan@intel.com, David Ahern <dsahern@gmail.com>,
Jiri Pirko <jiri@mellanox.com>,
Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
Subject: Re: [RFC net-next Patch 0/3] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP)
Date: Fri, 10 Jan 2020 18:56:08 +0100 [thread overview]
Message-ID: <20200110175608.GK19739@lunn.ch> (raw)
In-Reply-To: <20200110172536.42rdfwdc6eiwsw7m@soft-dev3.microsemi.net>
> > Horatiu, could you also give some references to the frames that need
> > to be sent. I've no idea what information they need to contain, if the
> > contents is dynamic, or static, etc.
> It is dynamic - but trivial...
If it is trivial, i don't see why you are so worried about abstracting
it?
> Here is a dump from WireShark with
> annotation on what our HW can update:
>
> Ethernet II, Src: 7a:8b:b1:35:96:e1 (7a:8b:b1:35:96:e1), Dst: Iec_00:00:01 (01:15:4e:00:00:01)
> Destination: Iec_00:00:01 (01:15:4e:00:00:01)
> Source: 7a:8b:b1:35:96:e1 (7a:8b:b1:35:96:e1)
> Type: MRP (0x88e3)
> PROFINET MRP MRP_Test, MRP_Common, MRP_End
> MRP_Version: 1
> MRP_TLVHeader.Type: MRP_Test (0x02)
> MRP_TLVHeader.Type: MRP_Test (0x02)
> MRP_TLVHeader.Length: 18
> MRP_Prio: 0x1f40 High priorities
> MRP_SA: 7a:8b:b1:35:96:e1 (7a:8b:b1:35:96:e1)
> MRP_PortRole: Primary ring port (0x0000)
> MRP_RingState: Ring closed (0x0001)
> MRP_Transition: 0x0001
> MRP_TimeStamp [ms]: 0x000cf574 <---------- Updated automatic
> MRP_TLVHeader.Type: MRP_Common (0x01)
> MRP_TLVHeader.Type: MRP_Common (0x01)
> MRP_TLVHeader.Length: 18
> MRP_SequenceID: 0x00e9 <---------- Updated automatic
> MRP_DomainUUID: ffffffff-ffff-ffff-ffff-ffffffffffff
> MRP_TLVHeader.Type: MRP_End (0x00)
> MRP_TLVHeader.Type: MRP_End (0x00)
> MRP_TLVHeader.Length: 0
>
> But all the fields can change, but to change the other fields we need to
> interact with the HW. Other SoC may have other capabilities in their
> offload. As an example, if the ring becomes open then the fields
> MRP_RingState and MRP_Transition need to change and in our case this
> requires SW interference.
Isn't SW always required? You need to tell your state machine that the
state has changed.
> Would you like a PCAP file as an example? Or do you want a better
> description of the frame format.
I was hoping for a link to an RFC, or some standards document.
Andrew
next prev parent reply other threads:[~2020-01-10 17:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-09 15:06 [RFC net-next Patch 0/3] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP) Horatiu Vultur
2020-01-09 15:06 ` [RFC net-next Patch 1/3] net: bridge: mrp: Add support for Media Redundancy Protocol Horatiu Vultur
2020-01-09 15:06 ` [RFC net-next Patch 2/3] net: bridge: mrp: Integrate MRP into the bridge Horatiu Vultur
2020-01-09 15:06 ` [RFC net-next Patch 3/3] net: bridge: mrp: Add netlink support to configure MRP Horatiu Vultur
2020-01-09 16:19 ` [RFC net-next Patch 0/3] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP) Stephen Hemminger
2020-01-09 17:41 ` [Bridge] " Asbjørn Sloth Tønnesen
2020-01-10 9:02 ` Horatiu Vultur
2020-01-10 15:36 ` Stephen Hemminger
2020-01-10 14:13 ` Nikolay Aleksandrov
2020-01-10 15:38 ` Nikolay Aleksandrov
2020-01-10 16:04 ` Horatiu Vultur
2020-01-10 16:21 ` Vladimir Oltean
2020-01-10 16:48 ` Andrew Lunn
2020-01-10 17:25 ` Horatiu Vultur
2020-01-10 17:56 ` Andrew Lunn [this message]
2020-01-10 20:12 ` Horatiu Vultur
2020-01-10 20:33 ` Andrew Lunn
2020-01-10 19:27 ` David Miller
2020-01-10 20:03 ` nikolay
2020-01-10 20:24 ` Horatiu Vultur
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200110175608.GK19739@lunn.ch \
--to=andrew@lunn.ch \
--cc=UNGLinuxDriver@microchip.com \
--cc=anirudh.venkataramanan@intel.com \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=horatiu.vultur@microchip.com \
--cc=jakub.kicinski@netronome.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jiri@mellanox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=olteanv@gmail.com \
--cc=roopa@cumulusnetworks.com \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).