Re: [PATCH v2 1/2] can: add support for filtering own messages only

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi again,

Sorry for being slow to reply...

On Mon, 10 May 2021 at 14:28, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote:
>
>
>
> On 09.05.21 13:28, Erik Flodin wrote:
> > On Thu, 6 May 2021 at 07:26, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote:
>
> >>>>    From what I understood your main requirement is to double check the
> >>>> outgoing traffic whether is has been sent.
> >>>
> >>> What I would like to have is:
> >>> 1. Be notified when a frame has been sent. I send (from user space) a
> >>> single frame and wait until I get confirmation before sending the next
> >>> to give other nodes on the bus a slot to start sending, even if their
> >>> frames have ID with lower priority.
> >>
> >> o_O
> >>
> >> Sorry, but I have problems to get behind your use-case.
> >>
> >> 1. You are sending a frame
> >> 2. You get a confirmation
> >> 3. You are waiting some time (which is not written above), to give other
> >> nodes a slot??
> >
> > No explicit sleep is needed. The machine is sufficient slow so that
> > just waiting for the confirmation before sending the next frame is
> > enough. But if the frames are queued in the socket/device then the
> > frames are sent back-to-back.
>
> Ok, I feel I'm getting behind your requirement ...
>
> You mainly want to throttle the outgoing traffic, to make sure that e.g.
> a specific CAN ID is not sent 'back-to'back' and might lead to a DoS
> situation on the wire?!?

Yes, so after a frame has been sent, I want to leave the bus idle long
enough to give another device on the bus that has something in its TX
queue an opportunity to send.

> Do you know about the Linux CAN queuing disciplines that might provide
> the solution to your question?

Yes, I came across that when I started my journey in CAN-land, but
unfortunately the kernel I have to use doesn't have support for
traffic control. That's when I started using RECV_OWN_MSGS which
worked until I added filters and here we are now :)

If I get the chance to update the kernel (which would have to happen
before my proposed patch could be used anyway) I should perhaps try to
get tc support instead. That would simplify my application at least.

Thanks for your time!

Best regards,
// Erik



[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux