실제 해보지 않았지만

제가 생각 했을 때 속도는 그렇게 차이가 없을 것으로 보입니다.

kernel 내 usb interface driver 로 만든다면 좀더 빠를 것이라는 보편적인 생각은 있지만

system call 1-2개 차이로 보입니다. 

kernel 내에서 구현한다면 file operation 및 기타 device driver 관련된 처리를 해야 하기 때문에

구현하고 난 뒤에 속도 개선이 없으면 쓸모없는 일을 한게 되어버리지 않을까요?

먼저 cpu load 가 걸리는 포인트를 정확히 측정 하셔야 된다고 봅니다.

class 를 벗어난 회사 전용의 interface를 설계 하셨기 때문에 

libusb 를 사용하셨을거라 봅니다.

(class 에 포함 된다면 대부분 kernel 내에 driver 가 있기 때문에 이렇게 추측 했습니다.)

usb 통신으로 오는 data는 아마도 max rate 가 있을 것이고

이 data를 처리하는 부분은 kernel 내에 이미 다 구현 되고 처리 되고 있습니다.

시스템이 느려서 혹은 usb host 컨트롤러 드라이버가 삐꾸여서 data를 처리하는데 있어서 애를 먹는다면 

kernel 로 옮기던지 userspace에서 구현하던지 별 효과는 없을 것이라 확실하게 판단 됩니다.

data를 파싱하는데 있어서 대부분의 cpu를 소비하고 계시는것 아닌지요?

간단하게 data 파싱하는 부분을 막고 usb 로 부터 오는 data를 그냥 bypass 만 시켜서

cpu load 가 얼마나 걸리는지 먼저 한번 살펴 보세요.

주요 로드가 어디서 걸리는지 체킹을 해 보시는게 좋겠네요.

제 경험상, 커널이 빠르긴 할걸로 보여집니다.

통상 userspace로 데이터 복사하는데 많은 부분을 소진하기 때문입니다.

profiling을 해 보시기 바랍니다.

주고 받는 데이터가 크지 않고 실시간으로 확인만 하면 된다면 USB Bulk device driver로도 충분합니다.

usb driver의 skeleton드라이버 강추합니다. (tty 같은 복잡한 layer는 naver..)

http://elixir.free-electrons.com/linux/v4.13.11/source/drivers/usb/usb-skeleton.c#L435

주의 해야 할점은 bulk driver의 경우에 zero length packet 핸들링을 하지 않기 때문에 

http://elixir.free-electrons.com/linux/v4.13.11/source/include/linux/usb.h#L1296 아래 옵션을 urb_transfer_flag에 추가하세요.

그러면 usb core에서 zero length packet에 대해서 알아서 핸들링해줄 겁니다.