The driver was using it in only few places, so the rest of the code
was covered with those statement.
Details
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
My opinion is generally that branch predictions should be sparse. Is it really going to make any difference in setup/teardown functions, which many of the functions edited here appear to be?
That said, I tried to verify that none of the actual conditions changed, and I don't see any problems with this patch in that respect, so I don't have any objections.
sys/dev/ena/ena.c | ||
---|---|---|
1384–1387 ↗ | (On Diff #34524) | Is this one right? |
1407 ↗ | (On Diff #34524) | This seems just to be a loop counter... Is there any point to predicting its value? |
sys/dev/ena/ena.c | ||
---|---|---|
1384–1387 ↗ | (On Diff #34524) | Yes, if it is true, it means that DMA mapping of the mbuf was successfull (we can predict that it will be almost always true). |
1407 ↗ | (On Diff #34524) | This code is in hot path and the counter in the loop was added only to reduce latency on the RX. If TX cleanup would work in separate thread, there should be while(1). When the traffic will not be very high, we will rather call break inside the loop than hit budget == 0. |