From: Alex Elder <elder@linaro.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
Network Development <netdev@vger.kernel.org>,
"bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: IPA monitor (Final RFC)
Date: Wed, 26 Jan 2022 17:43:35 -0600 [thread overview]
Message-ID: <89023d8a-4bf2-be3f-99c4-46c137da8599@linaro.org> (raw)
In-Reply-To: <36491c9e-c9fb-6740-9e51-58c23737318f@linaro.org>
Damned double spacing. I'm not sure why it's happening... -Alex
In previous messages I explained how the Qualcomm IP Accelerator
(IPA) sometimes has the ability to replicate all packets it
processes, and supply those replicated packets to the main
application processor (AP). I initially suggested using a network
device as the interface for this, but after some discussion, Jakub
recommended using a debugfs file to supply these packets.
Below is basically a specification for the design I'll use. It is
what I intend to implement, so if anyone has any objection, please
voice it now. I'll be sending this code out for review in the
coming few weeks.
Thank you.
-Alex
- A new debugfs directory "qcom_ipaX" will be created for each IPA
instance (X = IPA device number). There's normally only going to
be one of these, but there is at least one SoC that has two.
/sys/kernel/debug/qcom_ipa0/
- If an IPA instance supports a "monitor endpoint", a "monitor" file
will be created in its "qcom_ipaX" directory.
/sys/kernel/debug/qcom_ipa0/monitor
- The "monitor" file is opened exclusively (no O_EXCL needed). An
attempt to open that file when it's already open produces EBUSY.
- The monitor file is read-only (S_IRUSR), and does not support seeks.
- Once opened, "monitor packets" (which consist of a fixed size
status header, followed by replicated packet data) will be
accumulated in *receive* buffers. If a replicated packet is
large, it will have been truncated by hardware to reduce
monitoring bandwidth.
- Once opened, reads to the monitor file are satisfied as follows:
- If no receive buffers have accumulated, the read will block
until at least one monitor packet can be returned.
- If the file is opened with O_NONBLOCK, a read that would block
will return EAGAIN instead of blocking.
- A read that blocks is interruptible.
- A valid monitor packet is supplied to user space at most once.
- Only "complete" monitor packets are supplied to the reader.
I.e., a status header will always be supplied together with
the packet data it describes.
- A *read* buffer will be filled with as many monitor packets as
possible. If they'll fit in the read buffer, all accumulated
monitor packets will be returned to the reader.
- If the read buffer has insufficient room for the next
available monitor packet, the read request returns.
- If any monitor packet received from hardware is bad, it--along
with everything beyond it in its page--will be discarded.
- The received data must be big enough to hold a status
header.
- The received data must contain the packet data, meaning
packet length in the status header lies within range.
next prev parent reply other threads:[~2022-01-26 23:43 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-14 14:47 Port mirroring (RFC) Alex Elder
2021-12-14 18:27 ` Andrew Lunn
2021-12-14 22:55 ` Alex Elder
2021-12-15 9:18 ` Andrew Lunn
2021-12-15 14:47 ` Alex Elder
2021-12-15 17:42 ` Andrew Lunn
2021-12-20 19:27 ` Alex Elder
2021-12-15 20:12 ` Florian Fainelli
2021-12-20 19:51 ` Alex Elder
2021-12-15 17:48 ` Florian Fainelli
2021-12-20 19:41 ` Alex Elder
2021-12-15 23:33 ` Jakub Kicinski
2021-12-20 20:17 ` Alex Elder
2022-01-14 16:50 ` Port mirroring, v2 (RFC) Alex Elder
2022-01-14 17:03 ` Alex Elder
2022-01-14 20:46 ` Andrew Lunn
2022-01-14 21:12 ` Alex Elder
2022-01-18 18:07 ` Jakub Kicinski
2022-01-18 18:14 ` Alex Elder
2022-01-15 15:14 ` Andrew Lunn
2022-01-18 17:37 ` Alex Elder
2022-01-18 18:30 ` Jakub Kicinski
2022-01-18 18:33 ` Alex Elder
2022-01-26 23:37 ` IPA monitor (Final RFC) Alex Elder
2022-01-26 23:43 ` Alex Elder [this message]
2022-02-02 0:19 ` Andrew Lunn
2022-02-02 0:41 ` Alex Elder
2022-02-02 19:05 ` Andrew Lunn
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=89023d8a-4bf2-be3f-99c4-46c137da8599@linaro.org \
--to=elder@linaro.org \
--cc=andrew@lunn.ch \
--cc=bjorn.andersson@linaro.org \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
/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.