Re: [PATCH net-next v2 4/4] net: hdlc_fr: Add support for any Ethertype

[Willem de Bruijn]

On Thu, Oct 29, 2020 at 7:53 PM Xie He <xie.he.0141@xxxxxxxxx> wrote:
>
> On Thu, Oct 29, 2020 at 10:24 AM Willem de Bruijn
> <willemdebruijn.kernel@xxxxxxxxx> wrote:
> >
> > > Also add skb_reset_mac_header before we pass an skb (received on normal
> > > PVC devices) to upper layers. Because we don't use header_ops for normal
> > > PVC devices, we should hide the header from upper layer code in this case.
> >
> > This should probably be a separate commit
>
> OK. I'll make it a separate commit in the next version of the series. Thanks!
>
> > Does it make sense to define a struct snap_hdr instead of manually
> > casting all these bytes?
>
> > And macros or constant integers to self document these kinds of fields.
>
> Yes, we can define a struct snap_hdr, like this:
>
> struct snap_hdr {
>         u8 oui[3];
>         __be16 pid;
> } __packed;
>
> And then the fr_snap_parse function could be like this:
>
> static int fr_snap_parse(struct sk_buff *skb, struct pvc_device *pvc)
> {
>        struct snap_hdr *hdr = (struct snap_hdr *)skb->data;
>
>        if (hdr->oui[0] == OUI_ETHERTYPE_1 &&
>            hdr->oui[1] == OUI_ETHERTYPE_2 &&
>            hdr->oui[2] == OUI_ETHERTYPE_3) {
>                if (!pvc->main)
>                        return -1;
>                skb->dev = pvc->main;
>                skb->protocol = hdr->pid; /* Ethertype */
>                skb_pull(skb, 5);
>                skb_reset_mac_header(skb);
>                return 0;
>
>        } else if (hdr->oui[0] == OUI_802_1_1 &&
>                   hdr->oui[1] == OUI_802_1_2 &&
>                   hdr->oui[2] == OUI_802_1_3) {
>                if (hdr->pid == htons(PID_ETHER_WO_FCS)) {
>
> Would this look cleaner?

Oh, right. The OUI being 3 bytes introduces masking and endianness
issues if casting to a wider type. Similar to IPv6 flowlabel handling,
for instance.

There is a lot of OUI code, such as cea_db_is_hdmi_forum_vsdb. But no
standard way of going about this. Some does byte-by-byte, some memcmp,
some masks.

The existing is probably as concise and readable as anything, and we
don't really care about a few extra branches here. Never mind this
suggestion.