Björn Töpel <bjorn.topel@xxxxxxxxx> writes: > On Mon, 9 Dec 2019 at 18:42, Björn Töpel <bjorn.topel@xxxxxxxxx> wrote: >> > [...] >> > You mentioned in the earlier version that this would impact the time it >> > takes to attach an XDP program. Got any numbers for this? >> > >> >> Ah, no, I forgot to measure that. I'll get back with that. So, when a >> new program is entered or removed from dispatcher, it needs to be >> re-jited, but more importantly -- a text poke is needed. I don't know >> if this is a concern or not, but let's measure it. >> > > Toke, I tried to measure the impact, but didn't really get anything > useful out. :-( > > My concern was mainly that text-poking is a point of contention, and > it messes with the icache. As for contention, we're already > synchronized around the rtnl-lock. As for the icache-flush effects... > well... I'm open to suggestions how to measure the impact in a useful > way. Hmm, how about: Test 1: - Run a test with a simple drop program (like you have been) on a physical interface (A), sampling the PPS with interval I. - Load a new XDP program on interface B (which could just be a veth I guess?) - Record the PPS delta in the sampling interval on which the program was loaded on interval B. You could also record for how many intervals the throughput drops, but I would guess you'd need a fairly short sampling interval to see anything for this. Test 2: - Run an XDP_TX program that just reflects the packets. - Have the traffic generator measure per-packet latency (from it's transmitted until the same packet comes back). - As above, load a program on a different interface and look for a blip in the recorded latency. Both of these tests could also be done with the program being replaced being the one that processes packets on the physical interface (instead of on another interface). That way you could also see if there's any difference for that before/after patch... -Toke
