From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Murali Karicheri <m-karicheri2@ti.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, netdev <netdev@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
linux-api@vger.kernel.org, Sekhar Nori <nsekhar@ti.com>,
Grygorii Strashko <grygorii.strashko@ti.com>
Subject: Re: [net-next RFC PATCH 00/13] net: hsr: Add PRP driver
Date: Tue, 26 May 2020 11:09:37 -0700 [thread overview]
Message-ID: <87imgilg9q.fsf@intel.com> (raw)
In-Reply-To: <CA+h21hqiV71wc0v=-KkPbWNyXSY+-oiz+DsQLAe1XEJw7eP=_Q@mail.gmail.com>
Hi Vladimir,
Vladimir Oltean <olteanv@gmail.com> writes:
>>
>> I don't really like these prefixes, I am thinking of when support for
>> IEEE 802.1CB is added, do we rename this to "hsr_prp_frer"?
>>
>> And it gets even more complicated, and using 802.1CB you can configure
>> the tagging method and the stream identification function so a system
>> can interoperate in a HSR or PRP network.
>>
>
> Is it a given that 802.1CB in Linux should be implemented using an hsr
> upper device?
What I was trying to express is the idea of using "hsr" as the directory
name/prefix for all the features that deal with frame replication for
reliability, including 802.1CB. At least until we find a better name.
> 802.1CB is _much_ more flexible than both HSR and PRP. You can have
> more than 2 ports, you can have per-stream rules (each stream has its
> own sequence number), and those rules can identify the source, the
> destination, or both the source and the destination.
Same understanding here.
Cheers,
--
Vinicius
prev parent reply other threads:[~2020-05-26 18:09 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 16:30 [net-next RFC PATCH 00/13] net: hsr: Add PRP driver Murali Karicheri
2020-05-06 16:30 ` [net-next RFC PATCH 01/13] net: hsr: Re-use Kconfig option to support PRP Murali Karicheri
2020-05-06 16:30 ` [net-next RFC PATCH 02/13] net: hsr: rename hsr directory to hsr-prp to introduce PRP Murali Karicheri
2020-05-06 16:30 ` [net-next RFC PATCH 03/13] net: hsr: rename files to introduce PRP support Murali Karicheri
2020-05-06 16:30 ` [net-next RFC PATCH 04/13] net: hsr: rename hsr variable inside struct hsr_port to priv Murali Karicheri
2020-05-06 16:30 ` [net-next RFC PATCH 05/13] net: hsr: rename hsr_port_get_hsr() to hsr_prp_get_port() Murali Karicheri
2020-05-06 16:30 ` [net-next RFC PATCH 06/13] net: hsr: some renaming to introduce PRP driver support Murali Karicheri
2020-05-06 16:30 ` [net-next RFC PATCH 07/13] net: hsr: introduce common uapi include/definitions for HSR and PRP Murali Karicheri
2020-05-06 16:30 ` [net-next RFC PATCH 08/13] net: hsr: migrate HSR netlink socket code to use new common API Murali Karicheri
2020-05-06 16:30 ` [net-next RFC PATCH 09/13] net: hsr: move re-usable code for PRP to hsr_prp_netlink.c Murali Karicheri
2020-05-06 16:30 ` [net-next RFC PATCH 10/13] net: hsr: add netlink socket interface for PRP Murali Karicheri
2020-05-06 16:30 ` [net-next RFC PATCH 11/13] net: prp: add supervision frame generation and handling support Murali Karicheri
2020-05-06 16:30 ` [net-next RFC PATCH 12/13] net: prp: add packet " Murali Karicheri
2020-05-06 16:30 ` [net-next RFC PATCH 13/13] net: prp: enhance debugfs to display PRP specific info in node table Murali Karicheri
2020-05-13 12:27 ` [net-next RFC PATCH 00/13] net: hsr: Add PRP driver Murali Karicheri
2020-05-21 12:34 ` Murali Karicheri
2020-05-21 17:31 ` Vinicius Costa Gomes
2020-05-25 16:49 ` Murali Karicheri
2020-05-26 18:56 ` Vinicius Costa Gomes
2020-05-26 21:51 ` Murali Karicheri
2020-05-25 21:37 ` Vladimir Oltean
2020-05-26 14:12 ` Murali Karicheri
2020-05-26 18:25 ` Vladimir Oltean
2020-05-26 21:33 ` Murali Karicheri
2020-05-26 18:09 ` Vinicius Costa Gomes [this message]
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=87imgilg9q.fsf@intel.com \
--to=vinicius.gomes@intel.com \
--cc=davem@davemloft.net \
--cc=grygorii.strashko@ti.com \
--cc=kuba@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m-karicheri2@ti.com \
--cc=netdev@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=olteanv@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.