ANLAB-KAIST / rust-dpdk

BSD 3-Clause "New" or "Revised" License
86 stars 14 forks source link

MLX5 지원 추가 #45

Closed lkaybob closed 4 years ago

lkaybob commented 4 years ago

이전에 @leeopop 님이 알려주신 방법대로, DPDK가 MLX5 PMD를 포함해 빌드가 된 것을 확인하고, 만약 그렇다면 rust-dpdk의 빌드에도 포함되게 수정했습니다.

lkaybob commented 4 years ago

@leeopop 님의 추가 코멘트 옮겨옵니다.

As-is

MLX5 드라이버에서 Queue stop을 구현하지 않아, 프로그램 말미에 Panic을 내고 프로그램이 죽는 경우가 발생

To-be

패닉을 일으키는 assertion 확인 후 드라이버의 미 구현으로 인한 에러라 판단되면 warning 출력 후 넘어가기

2020-07-20 12:08:28,122 WARN  [dpdk::eal] RxQInner::drop, non-severe error code(-95) while stopping queue 0:0
2020-07-20 12:08:28,122 WARN  [dpdk::eal] TxQInner::drop, non-severe error code(-95) while stopping queue 0:0
2020-07-20 12:08:28,122 INFO  [dpdk::eal] Port 0 cleaned up
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `false`,
 right: `true`', <::std::macros::panic macros>:5:6
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
lkaybob commented 4 years ago

Panic 나는 것 관련해서 확인을 해봤는데, 실제로는 GC하는 부분에서 에러가 나는 것으로 보여서 드라이버의 미구현의 문제라고 보기는 어려울 것 같은데... 혹시 짐작가시는 부분이 있으실까요? @leeopop

2020-07-20 13:15:39,561 INFO  [dpdk::eal] Port 1 cleaned up
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `false`,              
 right: `true`', <::std::macros::panic macros>:5:6
stack backtrace:         
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86
...(생략)
  11: rust_begin_unwind
             at src/libstd/panicking.rs:378
  12: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:332
  13: <dpdk::eal::EalInner as core::ops::drop::Drop>::drop
             at ./<::std::macros::panic macros>:5
  14: core::ptr::drop_in_place
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/ptr/mod.rs:177
  15: alloc::sync::Arc<T>::drop_slow
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/liballoc/sync.rs:739
leeopop commented 4 years ago

gc는 잘못한게 없습니다.. 문제의 근본적인 이유를 찾아보시면 답을 찾으실 수 있을겁니다. 이따 장비 전달하러 방문드릴 때 알려드릴게요

lkaybob commented 4 years ago

gc는 잘못한게 없습니다.. 문제의 근본적인 이유를 찾아보시면 답을 찾으실 수 있을겁니다. 이따 장비 전달하러 방문드릴 때 알려드릴게요

알려주신 점 참고해서, 수정해봤습니다. 방법은 2가지가 나올 수 있었는데

  1. impl Drop for EalInner에서 assertion 제거
    • graceful shutdown 지원 안되는 pmd에 대해서는 그냥 leak 하고 종료하자고 제안하신 것을 생각하면 이렇게 가능합니다.
    • 제거를 해도 rte_eal_cleanup에서는 에러가 안 납니다.
  2. impl Drop for PortInner 에서 rte_eth_dev_stop rte_eth_dev_close 수행
    • 확실하게 Port의 Resource들을 Cleanup할 수 있습니다.
    • 둘 중 하나만 하면 여전히 Panic이 일어나 둘이 함께 사용해줘야합니다.
    • 대신, rte_eth_dev_close특징 때문에 Port는 재시작될 수 없다는 단점이 존재

저는 Assertion을 빼는 것보다는 확실하게 Cleanup하는 방법이 더 낫다고 판단해서, 방금 전 올린 커밋에는 후자의 방법으로 반영했는데, 어떠신가요? (impl Drop for PortInner에서 owner_unset만 하신거 보면 eth_dev_stop/close는 생각을 안 하고 계셨던 것 같습니다만...)

leeopop commented 4 years ago

@lkaybob 후자가 좋은 것 같습니다. Port 에서 stop/close 를 하지 않은 것은 아마 저의 불찰인 것 같습니다.

lkaybob commented 4 years ago

그럼 현재 상태로 머지하도록 하겠습니다. (실제 실행 결과 바이너리들 모두 정상 작동하는 것 확인했습니다.)

bors r+

ghost commented 4 years ago

Build succeeded: