Hello Jesper, On Sun, 2018-10-07 at 18:13 +0200, Jesper Dangaard Brouer wrote: > On Fri, 5 Oct 2018 15:56:31 -0400 > Justin Azoff <justin.azoff@xxxxxxxxx> wrote: > > > > People on this list might not realize that there is a significant > > > overhead in supporting larger that 4K frames for XDP, that is > > > larger > > > than one memory-page. So let me explain... ... > One thing I realize is that people on this list, are perhaps not > familiar how NIC RX (via DMA) works. On RX, we cannot know the RX > packet size up-front. Thus, when filling the NIC RX-ring memory > slots, > then we have to allocated room for the "worse-case", e.g. 9000Bytes > is > minimum 3x4K=12K, and due to page-alloc limits min 4x4K=16K. Thus, > regardless of packet length the alloc size is the same. (I will not > go > into detail on how different drivers tries to reduce this mem- > overhead, > but only say that those tricks costs CPU cycles). > > A last word of adding features to XDP: When adding features, I look > long and hard for ways that the features checks can be pushed to > setup > time, rather than runtime. I get your point about performance and really understand why they matter but we have kind of an issue for pure packet sniffing here. For this type of usage we get a copy of the organization network traffic via methods such as TAP devices or port mirroring. The consequences is that we receive the jumbo frames of other devices and can not set their length. As we need a pure copy of packets to be able to analyze the traffic correctly we have to be able to send the full jumbo frame to userspace for analysis (or feature like file extraction will not work). Is there a possible workaround even if lower performance (kind of slow path) ? Best regards, -- Eric Leblond <eric@xxxxxxxxx>
|