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