RX-fixup question.

Bjørn Mork bjorn at mork.no
Tue Nov 4 23:28:31 PST 2014


Dan Williams <dcbw at redhat.com> writes:

> On Tue, 2014-11-04 at 21:07 +0100, Markus Gothe wrote:
>> To reduce overhead on embedded / slow systems one should IMO implement the mac destination fix for specific devices by the means of ebtables only.
>> 
>> Thus gaining performance in most cases.
>
> If fixup was only done with ebtables in userspace it would require
> another list of devices somewhere (which duplicates the kernel lists)
> and the network driver for that device would be broken-by-default.  I
> don't think this would be a reliable or viable approach.
>
> These bugs aren't necessarily specific to certain devices, they were
> just observed in those devices initially.  They are likely specific to
> certain Qualcomm firmware branches/versions which might be used by many
> different manufacturers.
>
> What's the actual performance hit that qmi_wwan_rx_fixup() incurs? 5%?
> 10%? 20%?

I have a hard time imagining such high numbers.  qmi_wwan_rx_fixup()
doesn't do that much.  If it really has a measurable performance impact,
then it does something very wrong and we should fix that instead.  Maybe
it has an unaligned access or something making some platforms unhappy?

I used to worry about performance loss due to unnecessary testing or
copying of data. But I stopped after looking at a few out-of-tree
drivers.  Reality is that we can do lots of ugly stuff in a driver
without any signicant performance hit.

> I'd rather whitelist specific devices known to work than turn the fixup
> off for everything and push stuff to userspace.

I'm afraid that is impossible due to the random appearance of this bug
even on affected devices. It's not feasible to build a complete
whitelist.


Bjørn


More information about the libqmi-devel mailing list