All the other protocols have corresponding start and input routines
which are used in the fast path, but not the none protocol. Currently
the none protocol is treated specially to indicates whether a working
protocol is configured. In the fast path it is always checked and it
smells like to be overkilled and be unfaire to other protocols, which
are more commonly used in production.
A PR 289017 also reveals that there's a small window between checking
the protocol and calling lagg_proto_start(). It is possible that
lagg_proto_start() can still see none protocol and does NULL deferencing.
Fix that by making the none protocol first class citizen, so that it
has start and input routines just the same with other protocols.
Then we can stop checking it in the fast path, and hence lagg_proto_start()
and lagg_proto_input() will never fail to work.
The error ENETDOWN is choosen for start routine of none protocol, as it
is obviously no ports will be choosen. It should be also a better error
than ENXIO, since we indeed has a Tx algorithm ( the none protocol ).
PR: 289017
Diagnosed by: Qiu-ji Chen<chenqiuji666@gmail.com>
Reported by: Gui-Dong Han <hanguidong02@gmail.com>
MFC after: 1 week