I am involved in porting a broadband-bridge-router to Linux. I
decided against using the linux bridging code since we already have
all the necessary data-structures & code etc... in place. Using Linux
briding code would mean sufficient re-write of our code ...we might do
it later on but definitely not for version 1.0. So what I am planning
to do is to define our own LLC protocol type (ETH_P_OUROWN), define a
handler for it. The ethernet driver (also written by us) stamps the
incoming packets with ETH_P_OUROWN (after eth_type_trans() call) . The
handler takes care of diverting it to linux code (for ARP packets
etc..) or to our code for IP packets.
I have following questions in this regard:
 Is defining ETH_P_OUROWN OK ... I mean it fits well from a
coding-perspective..but I am not sure if there are any other issues
involved here ... I mean do we need to officially register it ? Can
someone point me to helpful resources on web ?
 Is this the usual way of doing it...are there any better ways ?
Basically IP packets have to go to our code before they go to Linux IP
code...We are planning to use our code as a net-filter hook at
LOCAL_OUT...however for forwarding & packets destined for
localhost...we plan to define a protocol handler ...this handler takes
the incoming packets (local/forward) does XXXXX on them, uses IP
exposed functions to do some IP operations....and does local_deliver /
We could have very well used IP pre-routing hook...but as I said
before,,,the emphasis is on minimal code changes (to our code).
This is my first project on Linux networking so any, even seemingly
obvious hints/solutions will help.
 Are there any issues related to the amount of processing involved
in the protocol handler... I mean if the protocol handler (the func()
invoked from net_rx_action) is quite heavy (in processing) , are there
any problems ?...since I guess this same tasklet is responsible for
dequeing the packets from the per-CPU queue (in which the driver
deposits the packets)....are they any gotchas or design tricks
P.S. we had thought of using ETH_P_ALL first...but since our handler
is a kind of protocol-mangler (packets may be even dropped...) so we
ruled out that option (since as per comments in dev_add_pack() ...
ETH_P_ALL was meant only for packet watchers and not packet manglers).