Low-level Fibre Channel

["Nikita V. Youshchenko" <yoush@cs.msu.su>]

Hello.

In a project we work on, we are using custom hardware that provides direct 
access to low-level Fibre Channel protocol layers. So software (running on 
linux host) can send/receive FC2 sequences and even individual FC1 frames. 
This is used to work with "non-so-mainstream" FC protocols (such as those 
used in avionics) that commodity FC hardware can't deal with.

I'm now working on drivers for that.

I was going to implement /dev/fcraw device class with ioctl()s to send and 
receive FC1/FC2, and provide in-kernel API for particular device drivers.
This is something I've already done for mil-std-1553 devices, and also for 
other devices, and have experience with.

Question I'd like to ask is - isn't it better to use socket-based API - 
create FC protocol family, support sockets to send and receive FC2 
sequences or FC1 frames, etc etc

I currently have very limited experience with in-kernel network layer.
Is there any practical benefit in doing socket-based API instead of a 
custom ioctl()-based API (e.g.: easier to implement or to use)?

Maybe someone did FC protocol family support before? I wasn't able to find, 
but still?

I guess that FC1 frames (~2200 bytes max) can map well into skb's, but what 
about FC2 sequences that are up to 16 megabytes in size? Is linux network 
layer ready to handle "messages" of that size?

If creating custom interface, I could use in-memory receive buffer that is 
DMAed to by hardware, and read-only mmapped into consumer process address 
space. Thus avoiding on-cpu copy, which could be essential for high data 
rates of FC. Is something similar implementable within socket API?

[we have device that does FC2 in hardware, and can DMA received FC2 
sequences in chunks of 64 kilobytes, but for application software, having 
entire sequence continuous in application's virtual address space is much 
preferred]

Also, to handle high data rate, I am thinking of early filtering. Such as 
driver could first analyse header of particular incoming frame or sequence 
(using direct access to adapter memory via pci), and then decide if it's 
content should be DMAed from adapter memory to host memory or not. Doesn't 
this conflict with socket API?

Any other advice on topic?

Thanks.

Nikita

P.S.
Btw, anyone interested in /dev/mstd1553 or /dev/arinc429? We can share some 
code... although particular API implemented is overengineered and 
questionable, and driver support is done only for virtual devices and for 
several adapters manufactured by local Russian companies not widely known.