Low-level trace-buffers in CAM

[Pokala, Ravi]

-----Original Message-----


From: John Baldwin <jhb at freebsd.org>
Date: 2015-11-24, Tuesday at 18:07
To: "freebsd-hackers at freebsd.org" <freebsd-hackers at freebsd.org>
Cc: Adrian Chadd <adrian.chadd at gmail.com>, Ravi Pokala <rpokala at panasas.com>, "freebsd-geom at freebsd.org" <freebsd-geom at freebsd.org>, "ken at freebsd.org" <ken at freebsd.org>, "scottl at freebsd.org" <scottl at freebsd.org>, "freebsd-scsi at freebsd.org" <freebsd-scsi at freebsd.org>, "imp at freebsd.org" <imp at freebsd.org>
Subject: Re: Low-level trace-buffers in CAM

>On Monday, October 26, 2015 09:52:25 PM Adrian Chadd wrote:
>> Hi,
>> 
>> ok. So this is where I create work for people. :-)
>> 
>> Something I've been tossing up for quite some time is a generic
>> version of this that exposes a ring-buffer of entries back to
>> userland. For things like this, things like ALQ/KTR, etc, it's all
>> just a producer-consumer ring based thing. You don't even care about
>> multiple readers; that's a userland thing.
>> 
>> So, I'm a big fan of this. I did this for the ath driver to debug
>> descriptors and register accesses and it was a big help. I'd really
>> like to see a more generic way we can expose this data in an efficient
>> manner!
>
>I actually think bpf might not be a bad interface (as I suggested at
>the vendor summit), though I think we need a way to enumerate BPF taps
>that aren't network interfaces (if we fix this then we can remove the
>fake USB ifnets and make glebius@ happy as well).  Then you can look
>at these things in wireshark (which would be a bit bizarre perhaps)

Wait, you're talking about using Berkeley Packet Filter in the context of storage command tracing? That's giving me a major parse error...

-Ravi

>-- 
>John Baldwin