Re: Low-level trace-buffers in CAM

On 25/11/2015 10:07 AM, John Baldwin wrote: 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.

Re: Low-level trace-buffers in CAM

> On Nov 24, 2015, at 6:07 PM, John Baldwin wrote: > > 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

Re: Low-level trace-buffers in CAM

.org" , "i...@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 s

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 lik

Re: Low-level trace-buffers in CAM

t; , "sco...@freebsd.org" Subject: Re: Low-level trace-buffers in CAM >On Tue, Oct 27, 2015 at 02:22:33AM +, Pokala, Ravi wrote: > >> Hi folks, >> >> >> This is an updated re-send of a m

Re: Low-level trace-buffers in CAM

On Tue, Oct 27, 2015 at 02:22:33AM +, Pokala, Ravi wrote: > Hi folks, > > > This is an updated re-send of a message I originally sent about a year ago, > during MeetBSD 2014. A few people expressed interest in person, but no on

Re: Low-level trace-buffers in CAM

-Original Message- From: Ravi Pokala Date: 2015-10-26, Monday at 21:21 To: Adrian Chadd Cc: "freebsd-geom@freebsd.org" , "freebsd-s...@freebsd.org" , "freebsd-hack...@freebsd.org" , "k...@freebsd.org" , "i...@freebsd.org" , "sco

Re: Low-level trace-buffers in CAM

-Original Message- From: Adrian Chadd Date: 2015-10-26, Monday at 19:52 To: Ravi Pokala Cc: "freebsd-geom@freebsd.org" , "freebsd-s...@freebsd.org" , "freebsd-hack...@freebsd.org" , "k...@freebsd.org" , "i...@freebsd.org" , "sco

Re: Low-level trace-buffers in CAM

-Original Message- From: Scott Long Date: 2015-10-26, Monday at 20:08 To: Ravi Pokala Cc: "freebsd-geom@freebsd.org" , "freebsd-s...@freebsd.org" , "freebsd-hack...@freebsd.org" , "k...@freebsd.org" , "i...@freebsd.org" , "sco

Re: Low-level trace-buffers in CAM

Hi Ravi, Yes I was one of the people who never followed up. I'll be at the vendor summit next week, let's chat some more. Scott Sent from my iPhone > On Oct 26, 2015, at 8:22 PM, Pokala, Ravi wrote: > > Hi folks, > > > This i

Re: Low-level trace-buffers in CAM

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 do

Low-level trace-buffers in CAM

Hi folks, This is an updated re-send of a message I originally sent about a year ago, during MeetBSD 2014. A few people expressed interest in person, but no one ever followed up on the lists. I'm bringing this up again, in the hope

Low-level trace-buffers in CAM

Hi folks, At Panasas, we found it useful to have a trace buffer for each ATA drive in the system, for gathering information about command sequences and latency. I implemented that functionality for our old 7-ish ATA driver, and it works quite well, with fairly low overhead. For example (sorry for