Re: [PATCH v8 4/7] can: canxl: introduce CAN XL data structure

[Vincent Mailhol <vincent.mailhol@gmail.com>]

On Sun. 11 Sept. 2022 at 21:11, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> Hi Vincent,
>
> On 11.09.22 09:50, Vincent Mailhol wrote:
> > On Thu. 8 Sep. 2022 at 16:24, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> (..)
>
> >>> The CAN-ID was (due to its arbitration nature) always also a priority
> >>> field.
> >
> > The CAN-(FD) ID holds two roles: priority and ID. For CAN XL, it is
> > only ID.
>
> Typo? It is only the priority ;-)

Yes, typo ^^;

> > While I agree that both have the priority attributes, my
> > concerns are on the semantics. The type is canid_t, not canprio_t. I
> > just want to point that it is weird to had ID in the type when that
> > field doesn't have an ID property anymore.
>
> CAN XL moves away from the two roles combined in the CAN(FD) Identifier.
> The main focus is on arbitration now (CAN XL is like CAN arbitration
> with Ethernet data).
>
> But in the end the CAN bitstream at the beginning of the frame including
> the arbitration is completely identical for all CAN variants.
>
> Even when this arbitration field is now named priority for CAN XL it is
> still the exact mechanism of the CAN identifier (what we introduces
> canid_t for).
>
> Therefore having canid_t for can_id and prio seems appropriate.

I guess you have a better insight. Thanks for the details.

> >>> So nothing changed here. There is no RTR and no 29-bit priority anymore
> >>> now. The RTR flag has already been disabled for CAN FD (see presentation
> >>> at the end of this mail).
> >>>
> >>> Therefore it makes sense to handle the SFF 11-bit prio analogue to the
> >>> former CAN-ID - and also use canid_t to simply keep the entire CAN
> >>> filter handling in af_can.c !
> >
> > This is a good argument to keep using the canid_t. If we make it a
> > u16, we lose the alignment (unless we add dirty endianness
> > preprocessing macros).
>
> Yep.
>
> (..)
>
> >>> Btw. I uploaded a presentation which shows the way from classical CAN to
> >>> CAN XL which might depict some relations of the bits in a clearer way:
> >>>
> >>> https://github.com/linux-can/can-doc/blob/master/presentations/CAN-XL-Intro.pdf
> >
> > Thanks. With the Bosch PDF now returning error 404, I suggest
> > replacing the link in the cover letter with your link (or the CIA
> > knowledge page).
>
> Ok, will do.

Yours sincerely,
Vincent Mailhol