Messages in this thread | | | Subject | Re: Proposed SyncPPP layer modifications | Date | Fri, 18 Feb 2000 15:54:43 +0000 (GMT) | From | Alan Cox <> |
| |
> Proposal 1: implement the equivalent of eth_type_trans(skb, dev) for the > syncppp devices.
Ok
> Proposal 2: implement the common device allocation & registration code > similar to the init_etherdev() and ether_setup() routines.
Ok
> is set to ETH_P_WAN_PPP, the packet is passed to netif_rx(), > and the sppp_input() routine then changes the skb->type > to the appropriate 3rd-layer protocol (IP or IPX) > and passes the skb to netif_rx() once again. This is wrong and it > caused misinterpretation in tcpdump and ipchains in the past (the packet > is seen twice by the network stack). LCP or Cisco keepalive > packets are handled directly (and thus are seen only once).
We can handle them directly. What we cannot do however is handle them directly in netif_rx() . The syncppp processing overhead is too high to put in the IRQ path of the Z85230.
> have the sppp_type_trans(skb, dev) routine for setting up the > skb->proto, skb->mac.raw, and maybe skb->dev fields. It should > immediately decide between the ETH_P_IP, ETH_P_IPX and assign
(Syncppp should be using the generic ppp layer in 2.3.x)
> I propose to implement the init_spppdev(dev, sizeof_priv) routine, > which will allocate the struct net_device (if needed) and all the > other structures, sets up the syncppp device part (struct ppp_device) > and initialize the syncppp layer using sppp_attach() (which seems > to be a good equivalent of ether_setup()).
Ok
> (and add something like ETH_P_CISCO for Cisco HDLC keepalive > and other frames)? Or should I use ETH_P_WAN_PPP type for both > Cisco HDLC service frames and PPP (LCP/IPCP/keepalive) ones?
Add an ETH_P_CHDLC I think
> Alternatively, the sppp_input can be called instead of netif_rx() > by the network driver, but I think it causess too much work to be > done at the (possible) interrupt time.
It causes too much work - I tried it originally. The 85230 is very very time sensitive as its a paticularly stupid chip and people insist on running it at 512Kbit.
> are static. We can add the init_spppdev() into net_init.c, but this > routine should call sppp_attach, which will need the syncppp.c > to be linked into the kernel (possibly with new CONFIG_SYNCPPP > option, which would be set if CONFIG_COSA or CONFIG_HOSTESS or > CONFIG_SEALEVEL is set).
Just make them non static. They are static because nobody needed them
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |