On 2019/9/24 上午12:31, Matt Cover wrote:
I think it's better to safe to just drop the packet instead of trying to
workaround it.
This patch aside, dropping the packet here
seems like the wrong choice. Loading a
prog at this hookpoint "configures"
steering. The action of configuring
steering should not result in dropped
packets.
Suboptimal delivery is generally preferable
to no delivery. Leaving the behavior as-is
(i.e. relying on netdev_cap_txqueue()) or
making any return which doesn't fit in a
u16 simply use queue 0 would be highly
preferable to dropping the packet.
Thanks
It leaves a choice for steering ebpf program to drop the packet that it
can't classify. But consider we have already had socket filter, it
probably not a big problem since we can drop packets there.
Thanks
