2017-05-30 9 views
0

私はdpdkを使ってパケット送信実験を行っています。しかし、受信側アプリケーションは全くパケットを受信しませんでした。 rte_eth_stats_get()から得られた統計データは、すべてのポートが多くの "rx_error"を報告していることを示しました。デバッグ後、これらのエラーはすべて「rx_length_error」という名前のエラーであることがわかりました。 googleからの説明によると、MACヘッダーの入ってくるパケット長フィールドがパケット長と一致しない場合、長さエラーが発生します。しかし、私が知る限り、MACヘッダーには長さフィールドはありません。NICはどのような場合にrx_length_errorを報告しますか?

私の質問はどのようにNICは長さフィールドなしでこの長さエラーを報告するのですか?

ありがとうございました!

答えて

1

これは、イーサネットヘッダを適切に設定する必要があることyour previous question here、特にイーサタイプを指摘しました。

いくつかのイーサタイプはそれほど82599は、それらのフレームを認識し、特定のイーサタイプのために予想される長さは、あなたの実際のフレームサイズと一致しない場合、それらをドロップし、あなたは固定長フレームを持っている暗示します。

+0

私はその質問のあなたの提案としてパケットにether_hdrを追加しました。それはとてもうまく機能しました。ご協力いただきありがとうございます。しかし、私はまだパケットがether_hdrなしで正しく送信される理由について混乱していますか?たとえば、単純な文字列をtx mbufに追加しただけで、受信者はrxエラーなしでこれらの文字列をすべて受け取ることができます。基本的にはランダムなデータがEthertypeフィールドに挿入されているので、 –

+0

@ K.Xuです。したがって、それは動作する場合もあれば、そうでない場合もあります。それはNICにも依存しますので、82599ではいくつかのEthertypesを削除し、別のNICではいくつかのNICを削除します。いくつかのCPUサイクルを節約するために、すべてのmbufに同じEthernetヘッダーをあらかじめ入力することができます。しかし、イーサネットヘッダーの代わりにデータを挿入することはかなり危険です。 –

+0

このフィルタ戦略は、dpdkドライバコードで変更できますか?それとも、NICのハードウェアで実装されているだけですか? –

関連する問題