mbox series

[net-next,v7,0/5] net: hdlc_fr: Improve fr_rx and add support for any Ethertype

Message ID 20201031181043.805329-1-xie.he.0141@gmail.com (mailing list archive)
Headers show
Series net: hdlc_fr: Improve fr_rx and add support for any Ethertype | expand

Message

Xie He Oct. 31, 2020, 6:10 p.m. UTC
The main purpose of this series is the last patch. The previous 4 patches
are just code clean-ups so that the last patch will not make the code too
messy. The patches must be applied in sequence.

The receiving code of this driver doesn't support arbitrary Ethertype
values. It only recognizes a few known Ethertypes when receiving and drops
skbs with other Ethertypes.

However, the standard document RFC 2427 allows Frame Relay to support any
Ethertype values. This series adds support for this.

Change from v6:
Remove the explanation about why only a 2-byte address field is accepted
because I think it is inadequate and unnecessary.

Change from v5:
Small fix to the commit messages.

Change from v4:
Drop the change related to the stats.rx_dropped count.
Improve the commit message by stating why only a 2-byte address field
is accepted.

Change from v3:
Split the last patch into 2 patches.
Improve the commit message about the stats.rx_dropped count.

Change from v2:
Small fix to the commit messages.

Change from v1:
Small fix to the commit messages.

Xie He (5):
  net: hdlc_fr: Simpify fr_rx by using "goto rx_drop" to drop frames
  net: hdlc_fr: Change the use of "dev" in fr_rx to make the code
    cleaner
  net: hdlc_fr: Do skb_reset_mac_header for skbs received on normal PVC
    devices
  net: hdlc_fr: Improve the initial checks when we receive an skb
  net: hdlc_fr: Add support for any Ethertype

 drivers/net/wan/hdlc_fr.c | 118 +++++++++++++++++++++++---------------
 1 file changed, 72 insertions(+), 46 deletions(-)

Comments

Jakub Kicinski Nov. 3, 2020, 11:22 p.m. UTC | #1
On Sat, 31 Oct 2020 11:10:38 -0700 Xie He wrote:
> The main purpose of this series is the last patch. The previous 4 patches
> are just code clean-ups so that the last patch will not make the code too
> messy. The patches must be applied in sequence.
> 
> The receiving code of this driver doesn't support arbitrary Ethertype
> values. It only recognizes a few known Ethertypes when receiving and drops
> skbs with other Ethertypes.
> 
> However, the standard document RFC 2427 allows Frame Relay to support any
> Ethertype values. This series adds support for this.

Applied, but going forward please limit any refactoring and extensions
to the HDLC code. I thought you are actually using it. If that's not
the case let's leave the code be, it's likely going to be removed in 
a few years time.
Xie He Nov. 4, 2020, 2:03 a.m. UTC | #2
On Tue, Nov 3, 2020 at 3:22 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> Applied, but going forward please limit any refactoring and extensions
> to the HDLC code. I thought you are actually using it. If that's not
> the case let's leave the code be, it's likely going to be removed in
> a few years time.

OK. I understand.

Thanks!
Xie He Nov. 7, 2020, 2:34 p.m. UTC | #3
On Tue, Nov 3, 2020 at 6:03 PM Xie He <xie.he.0141@gmail.com> wrote:
>
> On Tue, Nov 3, 2020 at 3:22 PM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > Applied, but going forward please limit any refactoring and extensions
> > to the HDLC code. I thought you are actually using it. If that's not
> > the case let's leave the code be, it's likely going to be removed in
> > a few years time.
>
> OK. I understand.
>
> Thanks!

The HDLC layer is still used by X.25 people (to be precise, Martin
Schiller <ms@dev.tdt.de>). Although we currently have three X.25
drivers in the kernel (lapbether, x25_asy, hdlc_x25), it seems to me
that only hdlc_x25 is used in the real world. So I guess the HDLC
layer will be there as long as the X.25 stack is still there.