DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [RFC]  DPDK Trace support
@ 2020-01-13 10:40 Jerin Jacob Kollanukkaran
  2020-01-13 11:00 ` Ray Kinsella
                   ` (2 more replies)
  0 siblings, 3 replies; 24+ messages in thread
From: Jerin Jacob Kollanukkaran @ 2020-01-13 10:40 UTC (permalink / raw)
  To: dev
  Cc: Thomas Monjalon, David Marchand, Ferruh Yigit, Andrew Rybchenko,
	Ajit Khaparde, Qi Zhang, Xiaolong Ye, Jerin Jacob Kollanukkaran,
	Raslan Darawsheh, Maxime Coquelin, Tiwei Bie, Akhil Goyal,
	Jerin Jacob Kollanukkaran, Luca Boccassi, Kevin Traynor,
	maintainers, John McNamara, Marko Kovacevic, Ray Kinsella,
	Bruce Richardson, Aaron Conole, Michael Santana,
	Harry van Haaren, Cristian Dumitrescu, Phil Yang, Joyce Kong,
	Mattias Rönnblom, Jan Viktorin, Gavin Hu,
	Jerin Jacob Kollanukkaran, Gavin Hu, David Christensen,
	Bruce Richardson, Konstantin Ananyev, Ferruh Yigit,
	Anatoly Burakov, Harini Ramakrishnan, Omar Cardona, Anand Rawat,
	Ranjit Menon, Olivier Matz, Andrew Rybchenko, Olivier Matz,
	Gage Eads, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko,
	Adrien Mazarguil, Nicolas Chautru, Declan Doherty, Akhil Goyal,
	Declan Doherty, Fiona Trahe, Ashish Gupta,
	Jerin Jacob Kollanukkaran, Erik Gabriel Carrillo,
	Abhinandan Gujjar, Shreyansh Jain, Hemant Agrawal,
	Artem V. Andreev, Andrew Rybchenko, Jerin Jacob Kollanukkaran,
	Nithin Kumar Dabilpuram, Vamsi Krishna Attunuru, Rosen Xu,
	Hemant Agrawal, Sachin Saxena, Stephen Hemminger, Ferruh Yigit,
	Chas Williams, Ferruh Yigit, John W. Linville, Xiaolong Ye,
	Qi Zhang, Prasun Kapoor, Marcin Wojtas, Michal Krawczyk,
	Guy Tzalik, Evgeny Schemeilin, Igor Chauskin, Ravi Kumar,
	Igor Russkikh, Pavel Belous, Shepard Siegel, Ed Czeck,
	John Miller, Ajit Khaparde, Somnath Kotur,
	Jerin Jacob Kollanukkaran, Maciej Czekaj, Shijith Thotton,
	Srisivasubramanian Srinivasan, Jerin Jacob Kollanukkaran,
	Rahul Lakkireddy, John Daley, Hyong Youb Kim, Wei Hu (Xavier,
	Min Hu (Connor, Yisen Zhuang, Ziyang Xuan, Xiaoyun Wang,
	Guoyang Zhou, Konstantin Ananyev, Beilei Xing, Xiao Wang,
	Jingjing Wu, Wenzhuo Lu, Xiao Wang, Qiming Yang, Wenzhuo Lu,
	Rosen Xu, Tomasz Duszynski, Liron Himi, Zyta Szpak, Liron Himi,
	Jerin Jacob Kollanukkaran, Nithin Kumar Dabilpuram,
	Kiran Kumar Kokkilagadda, Matan Azrad, Shahaf Shuler,
	Matan Azrad, Shahaf Shuler, Viacheslav Ovsiienko, Matan Azrad,
	Stephen Hemminger, K. Y. Srinivasan, Haiyang Zhang, Jan Remes,
	Jan Remes, Heinrich Kuhn, Jan Gutter, Hemant Agrawal,
	Sachin Saxena, Hemant Agrawal, Sachin Saxena, Gagandeep Singh,
	Sachin Saxena, Gagandeep Singh, Akhil Goyal, Rasesh Mody,
	Shahed Shaikh, Rasesh Mody, Shahed Shaikh, Andrew Rybchenko,
	Yong Wang, Maxime Coquelin, Tiwei Bie, Zhihong Wang,
	Maxime Coquelin, Tiwei Bie, Zhihong Wang, Maxime Coquelin,
	Tiwei Bie, Zhihong Wang, Steven Webster, Matt Peters,
	Ferruh Yigit, Keith Wiles, Ferruh Yigit, Bruce Richardson,
	Tetsuya Mukawa, Gaetan Rivet, Jasvinder Singh,
	Cristian Dumitrescu, Jakub Grajciar, Ravi Kumar, Ruifeng Wang,
	Anoob Joseph, Fan Zhang, Declan Doherty, Pablo de Lara,
	Declan Doherty, Pablo de Lara, John Griffin, Fiona Trahe,
	Deepak Kumar Jain, Pablo de Lara, Tomasz Duszynski,
	Michael Shamis, Liron Himi, Nagadheeraj Rottela,
	Srikanth Jampala, Ankur Dwivedi, Anoob Joseph, Declan Doherty,
	Gagandeep Singh, Hemant Agrawal, Akhil Goyal, Hemant Agrawal,
	Akhil Goyal, Hemant Agrawal, Declan Doherty, Pablo de Lara,
	Jay Zhou, Pablo de Lara, Ashish Gupta, Fiona Trahe, Lee Daly,
	Sunila Sahu, Jerin Jacob Kollanukkaran, Hemant Agrawal,
	Nipun Gupta, Hemant Agrawal, Nipun Gupta, Harry van Haaren,
	Mattias Rönnblom, Liang Ma, Peter Mccarthy, Rosen Xu,
	Tianfei zhang, Bruce Richardson, Satha Koteswara Rao Kottidi,
	Vamsi Krishna Attunuru, Xiaoyun Li, Jingjing Wu, Olivier Matz,
	Jasvinder Singh, Konstantin Ananyev, Konstantin Ananyev,
	Bernard Iremonger, Vladimir Medvedkin, Bernard Iremonger,
	David Hunt, Reshma Pattan, Cristian Dumitrescu, Jasvinder Singh,
	Reshma Pattan, Cristian Dumitrescu, Konstantin Ananyev,
	Byron Marohn, Sameh Gobriel, Vladimir Medvedkin, Yipeng Wang,
	Sameh Gobriel, Vladimir Medvedkin, Honnappa Nagarahalli,
	Gaetan Rivet, David Hunt, Robert Sanford, Erik Gabriel Carrillo,
	Reshma Pattan, Kevin Laatz, Konstantin Ananyev, Reshma Pattan,
	Wenzhuo Lu, Jingjing Wu, Bernard Iremonger, Declan Doherty,
	Jerin Jacob Kollanukkaran, Maryam Tahhan, Reshma Pattan,
	Marko Kovacevic, Ori Kam, Bruce Richardson, Radu Nicolau,
	Akhil Goyal, Bruce Richardson, Tomasz Kantecki, Sunil Kumar Kori,
	Pavan Nikhilesh Bhagavatula, John McNamara, Kirill Rybalchenko,
	Bruce Richardson, John McNamara, Harry van Haaren,
	Bruce Richardson, John McNamara, Xiaoyun Li, Prasun Kapoor,
	Keith Wiles, Kadam, Pallavi

Hi All,

I would like to add tracing support for DPDK.
I am planning to add this support in v20.05 release.

This RFC attempts to get feedback from the community on

a) Tracing Use cases.
b) Tracing Requirements.
b) Implementation choices.
c) Trace format.

Use-cases
---------
- Most of the cases, The DPDK provider will not have access to the DPDK customer applications.
To debug/analyze the slow path and fast path DPDK API usage from the field,
we need to have integrated trace support in DPDK.

- Need a low overhead Fast path multi-core PMD driver debugging/analysis
infrastructure in DPDK to fix the functional and performance issue(s) of PMD.

- Post trace analysis tools can provide various status across the system such
as cpu_idle() using the timestamp added in the trace.


Requirements:
-------------
- Support for Linux, FreeBSD and Windows OS
- Open trace format
- Multi-platform Open source trace viewer
- Absolute low overhead trace API for DPDK fast path tracing/debugging.
- Dynamic enable/disable of trace events


To enable trace support in DPDK, following items need to work out: 

a) Add the DPDK trace points in the DPDK source code.

- This includes updating DPDK functions such as,
rte_eth_dev_configure(), rte_eth_dev_start(), rte_eth_dev_rx_burst() to emit the trace.

b) Choosing suitable serialization-format

- Common Trace Format, CTF, is an open format and language to describe trace formats.
This enables tool reuse, of which line-textual (babeltrace) and 
graphical (TraceCompass) variants already exist.

CTF should look familiar to C programmers but adds stronger typing. 
See CTF - A Flexible, High-performance Binary Trace Format.

https://diamon.org/ctf/

c) Writing the on-target serialization code,

See the section below.(Lttng CTF trace emitter vs DPDK specific CTF trace emitter)
 
d) Deciding on and writing the I/O transport mechanics,

For performance reasons, it should be backed by a huge-page and write to file IO.

e) Writing the PC-side deserializer/parser,

Both the babletrace(CLI tool) and Trace Compass(GUI tool) support CTF.
See: 
https://lttng.org/viewers/

f) Writing tools for filtering and presentation.

See item (e)


Lttng CTF trace emitter vs DPDK specific CTF trace emitter
----------------------------------------------------------

I have written a performance evaluation application to measure the overhead
of Lttng CTF emitter(The fastpath infrastructure used by https://lttng.org/ library to emit the trace)

https://github.com/jerinjacobk/lttng-overhead
https://github.com/jerinjacobk/lttng-overhead/blob/master/README

I could improve the performance by 30% by adding the "DPDK"
based plugin for get_clock() and get_cpu(),
Here are the performance numbers after adding the plugin on 
x86 and various arm64 board that I have access to,

On high-end x86, it comes around 236 cycles/~100ns @ 2.4GHz (See the last line in the log(ZERO_ARG)) 
On arm64, it varies from 312 cycles to 1100 cycles(based on the class of CPU).
In short, Based on the "IPC capabilities", The cost would be around 100ns to 400ns
for single void trace(a trace without any argument)


[lttng-overhead-x86] $ sudo ./calibrate/build/app/calibrate -c 0xc0
make[1]: Entering directory '/export/lttng-overhead-x86/calibrate'
make[1]: Leaving directory '/export/lttng-overhead-x86/calibrate'
EAL: Detected 56 lcore(s)
EAL: Detected 2 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: Probing VFIO support...
EAL: PCI device 0000:01:00.0 on NUMA socket 0
EAL:   probe driver: 8086:1521 net_e1000_igb
EAL: PCI device 0000:01:00.1 on NUMA socket 0
EAL:   probe driver: 8086:1521 net_e1000_igb
CPU Timer freq is 2600.000000MHz
NOP: cycles=0.194834 ns=0.074936
GET_CLOCK: cycles=47.854658 ns=18.405638
GET_CPU: cycles=30.995892 ns=11.921497
ZERO_ARG: cycles=236.945113 ns=91.132736


We will have only 16.75ns to process 59.2 mpps(40Gbps), So IMO, Lttng CTF emitter
may not fit the DPDK fast path purpose due to the cost associated with generic Lttng features.

One option could be to have, native CTF emitter in EAL/DPDK to emit the
trace in a hugepage. I think it would be a handful of cycles if we limit the features
to the requirements above:

The upside of using Lttng CTF emitter:
a) No need to write a new CTF trace emitter(the item (c))

The downside of Lttng CTF emitter(the item (c))
a) performance issue(See above)
b) Lack of Windows OS support. It looks like, it has basic FreeBSD support.
c) dpdk library dependency to lttng for trace.

So, Probably it good to have native CTF emitter in DPDK and reuse all
open-source trace viewer(babeltrace and  TraceCompass) and format(CTF) infrastructure.
I think, it would be best of both world.

Any thoughts on this subject? Based on the community feedback, I can work on the patch for v20.05.

^ permalink raw reply	[flat|nested] 24+ messages in thread
* Re: [dpdk-dev] [RFC]  DPDK Trace support
@ 2020-01-20  4:48 Jerin Jacob Kollanukkaran
  2020-01-20 12:08 ` Ray Kinsella
  0 siblings, 1 reply; 24+ messages in thread
From: Jerin Jacob Kollanukkaran @ 2020-01-20  4:48 UTC (permalink / raw)
  To: dave, 'Ray Kinsella', 'dpdk-dev'

> -----Original Message-----
> From: dave@barachs.net <dave@barachs.net>
> Sent: Saturday, January 18, 2020 8:45 PM
> To: 'Ray Kinsella' <mdr@ashroe.eu>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; 'dpdk-dev' <dev@dpdk.org>
> Subject: [EXT] RE: [RFC] [dpdk-dev] DPDK Trace support
> 
> It would be well worth considering one of the vpp techniques to minimize trace
> impact:
> 
> static inline ring_handler_inline (..., int is_traced) {
>   for (i = 0; i < vector_size; i++)
>     {
>       if (is_traced)
> 	{
> 	  do_trace_work;
> 	}
>       normal_packet_processing;
>     }
> }
> 
> ring_handler (...)
> {
>   if (PREDICT_FALSE(global_trace_flag != 0))
>     return ring_handler_inline (..., 1 /* is_traced */);
>   else
>     return ring_handler_inline (..., 0 /* is_traced */); }
> 
> This reduces the runtime tax to the absolute minimum, but costs space.
> 
> Please consider it.

Thanks Dave for your thoughts.

> 
> HTH... Dave
> 
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Monday, January 13, 2020 6:00 AM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dpdk-dev
> <dev@dpdk.org>; dave@barachs.net
> Subject: Re: [RFC] [dpdk-dev] DPDK Trace support
> 
> Hi Jerin,
> 
> Any idea why lttng performance is so poor?
> I would have naturally gone there to benefit from the existing toolchain.
> 
> Have you looked at the FD.io logging/tracing infrastructure for inspiration?
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__wiki.fd.io_view_VPP_elog&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1
> DGob4H4rxz6H8uITozGOCa0s5f4wCNtTa4UUKvcsvI&m=b9wJHO_k_ijKT84q47_
> fO7MrN-LddnfpVSuNh6ce6Ks&s=WNwcIA86Rk2TY_C7O4bNTj3055Ofutab-
> bMPuM9-D4A&e=
> 
> Ray K
> 
> On 13/01/2020 10:40, Jerin Jacob Kollanukkaran wrote:
> > Hi All,
> >
> > I would like to add tracing support for DPDK.
> > I am planning to add this support in v20.05 release.
> >
> > This RFC attempts to get feedback from the community on
> >
> > a) Tracing Use cases.
> > b) Tracing Requirements.
> > b) Implementation choices.
> > c) Trace format.
> >
> > Use-cases
> > ---------
> > - Most of the cases, The DPDK provider will not have access to the DPDK
> customer applications.
> > To debug/analyze the slow path and fast path DPDK API usage from the
> > field, we need to have integrated trace support in DPDK.
> >
> > - Need a low overhead Fast path multi-core PMD driver
> > debugging/analysis infrastructure in DPDK to fix the functional and
> performance issue(s) of PMD.
> >
> > - Post trace analysis tools can provide various status across the
> > system such as cpu_idle() using the timestamp added in the trace.
> >
> >
> > Requirements:
> > -------------
> > - Support for Linux, FreeBSD and Windows OS
> > - Open trace format
> > - Multi-platform Open source trace viewer
> > - Absolute low overhead trace API for DPDK fast path tracing/debugging.
> > - Dynamic enable/disable of trace events
> >
> >
> > To enable trace support in DPDK, following items need to work out:
> >
> > a) Add the DPDK trace points in the DPDK source code.
> >
> > - This includes updating DPDK functions such as,
> > rte_eth_dev_configure(), rte_eth_dev_start(), rte_eth_dev_rx_burst() to emit
> the trace.
> >
> > b) Choosing suitable serialization-format
> >
> > - Common Trace Format, CTF, is an open format and language to describe
> trace formats.
> > This enables tool reuse, of which line-textual (babeltrace) and
> > graphical (TraceCompass) variants already exist.
> >
> > CTF should look familiar to C programmers but adds stronger typing.
> > See CTF - A Flexible, High-performance Binary Trace Format.
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__diamon.org_ctf_&d
> >
> =DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1DGob4H4rxz6H8uITozGOCa0s5f4
> wCNtTa4
> > UUKvcsvI&m=b9wJHO_k_ijKT84q47_fO7MrN-
> LddnfpVSuNh6ce6Ks&s=QErjHnVHM1me2
> > 4a6NGGIwiU6O5yot32ZW0vHbPnwZRg&e=
> >
> > c) Writing the on-target serialization code,
> >
> > See the section below.(Lttng CTF trace emitter vs DPDK specific CTF
> > trace emitter)
> >
> > d) Deciding on and writing the I/O transport mechanics,
> >
> > For performance reasons, it should be backed by a huge-page and write to file
> IO.
> >
> > e) Writing the PC-side deserializer/parser,
> >
> > Both the babletrace(CLI tool) and Trace Compass(GUI tool) support CTF.
> > See:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lttng.org_viewers
> >
> _&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1DGob4H4rxz6H8uITozGOCa0s
> 5f4wCNt
> > Ta4UUKvcsvI&m=b9wJHO_k_ijKT84q47_fO7MrN-
> LddnfpVSuNh6ce6Ks&s=JCCywchwpf
> > jb7Cta5ykYG-SHkMnNUyqPRHh9QAFIcXg&e=
> >
> > f) Writing tools for filtering and presentation.
> >
> > See item (e)
> >
> >
> > Lttng CTF trace emitter vs DPDK specific CTF trace emitter
> > ----------------------------------------------------------
> >
> > I have written a performance evaluation application to measure the
> > overhead of Lttng CTF emitter(The fastpath infrastructure used by
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lttng.org_&d=DwIF
> >
> aQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1DGob4H4rxz6H8uITozGOCa0s5f4wCNtT
> a4UUKvc
> > svI&m=b9wJHO_k_ijKT84q47_fO7MrN-
> LddnfpVSuNh6ce6Ks&s=dgfSVlEy8_W0IovAga
> > TnUT2ZbwCojfHimNxuyp4w7gI&e=  library to emit the trace)
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jerinj
> > acobk_lttng-
> 2Doverhead&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1DGob4H4rxz
> > 6H8uITozGOCa0s5f4wCNtTa4UUKvcsvI&m=b9wJHO_k_ijKT84q47_fO7MrN-
> LddnfpVSu
> > Nh6ce6Ks&s=uSB4IwIan6cs9NuEUvGezK_jfdJj7Rjp0qrbThjk08M&e=
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jerinj
> > acobk_lttng-
> 2Doverhead_blob_master_README&d=DwIFaQ&c=nKjWec2b6R0mOyPaz
> >
> 7xtfQ&r=1DGob4H4rxz6H8uITozGOCa0s5f4wCNtTa4UUKvcsvI&m=b9wJHO_k_i
> jKT84q
> > 47_fO7MrN-LddnfpVSuNh6ce6Ks&s=CudvGIANC2gl_e-
> TIAQt2IfpoczlIJIUee9IF78L
> > GHo&e=
> >
> > I could improve the performance by 30% by adding the "DPDK"
> > based plugin for get_clock() and get_cpu(), Here are the performance
> > numbers after adding the plugin on
> > x86 and various arm64 board that I have access to,
> >
> > On high-end x86, it comes around 236 cycles/~100ns @ 2.4GHz (See the
> > last line in the log(ZERO_ARG)) On arm64, it varies from 312 cycles to 1100
> cycles(based on the class of CPU).
> > In short, Based on the "IPC capabilities", The cost would be around
> > 100ns to 400ns for single void trace(a trace without any argument)
> >
> >
> > [lttng-overhead-x86] $ sudo ./calibrate/build/app/calibrate -c 0xc0
> > make[1]: Entering directory '/export/lttng-overhead-x86/calibrate'
> > make[1]: Leaving directory '/export/lttng-overhead-x86/calibrate'
> > EAL: Detected 56 lcore(s)
> > EAL: Detected 2 NUMA nodes
> > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > EAL: Selected IOVA mode 'PA'
> > EAL: Probing VFIO support...
> > EAL: PCI device 0000:01:00.0 on NUMA socket 0
> > EAL:   probe driver: 8086:1521 net_e1000_igb
> > EAL: PCI device 0000:01:00.1 on NUMA socket 0
> > EAL:   probe driver: 8086:1521 net_e1000_igb
> > CPU Timer freq is 2600.000000MHz
> > NOP: cycles=0.194834 ns=0.074936
> > GET_CLOCK: cycles=47.854658 ns=18.405638
> > GET_CPU: cycles=30.995892 ns=11.921497
> > ZERO_ARG: cycles=236.945113 ns=91.132736
> >
> >
> > We will have only 16.75ns to process 59.2 mpps(40Gbps), So IMO, Lttng
> > CTF emitter may not fit the DPDK fast path purpose due to the cost
> associated with generic Lttng features.
> >
> > One option could be to have, native CTF emitter in EAL/DPDK to emit
> > the trace in a hugepage. I think it would be a handful of cycles if we
> > limit the features to the requirements above:
> >
> > The upside of using Lttng CTF emitter:
> > a) No need to write a new CTF trace emitter(the item (c))
> >
> > The downside of Lttng CTF emitter(the item (c))
> > a) performance issue(See above)
> > b) Lack of Windows OS support. It looks like, it has basic FreeBSD support.
> > c) dpdk library dependency to lttng for trace.
> >
> > So, Probably it good to have native CTF emitter in DPDK and reuse all
> > open-source trace viewer(babeltrace and  TraceCompass) and format(CTF)
> infrastructure.
> > I think, it would be best of both world.
> >
> > Any thoughts on this subject? Based on the community feedback, I can work
> on the patch for v20.05.
> >


^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2020-02-17 10:24 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-13 10:40 [dpdk-dev] [RFC] DPDK Trace support Jerin Jacob Kollanukkaran
2020-01-13 11:00 ` Ray Kinsella
2020-01-13 12:04   ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2020-01-18 15:14   ` [dpdk-dev] " dave
2020-01-20 16:51     ` Stephen Hemminger
2020-01-13 13:05 ` Bruce Richardson
2020-01-13 14:46   ` Jerin Jacob
2020-01-13 14:58     ` Bruce Richardson
2020-01-13 15:13       ` Jerin Jacob
2020-01-13 16:12         ` Bruce Richardson
2020-01-17  4:41           ` Jerin Jacob
2020-01-17  8:04             ` David Marchand
2020-01-17  9:52               ` Jerin Jacob
2020-01-17 10:30                 ` Mattias Rönnblom
2020-01-17 10:54                   ` Jerin Jacob
2020-02-15 10:21                     ` Jerin Jacob
2020-02-17  9:35                       ` Mattias Rönnblom
2020-02-17 10:23                         ` Jerin Jacob
2020-01-17 10:43                 ` David Marchand
2020-01-17 11:08                   ` Jerin Jacob
2020-01-27 16:12 ` Aaron Conole
2020-01-27 17:23   ` Jerin Jacob
2020-01-20  4:48 Jerin Jacob Kollanukkaran
2020-01-20 12:08 ` Ray Kinsella

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).