netdev
[Top] [All Lists]

Re: net packet queue scheduler, packet_type and proto handlers

To: netdev@xxxxxxxxxxx
Subject: Re: net packet queue scheduler, packet_type and proto handlers
From: Krzysztof Halasa <khc@xxxxxxxxxxxxxxxxxx>
Date: 22 Feb 2001 16:41:43 +0100
Cc: Andi Kleen <ak@xxxxxx>
In-reply-to: Andi Kleen's message of "Wed, 21 Feb 2001 22:33:38 +0100"
References: <m3ofvx4k3x.fsf@xxxxxxxxxxxxxxxxxx> <20010221223338.B1758@xxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Andi Kleen <ak@xxxxxx> writes:

> >         switch (skb->data[1]) {
> > #ifdef CONFIG_INET
> >                 case AX25_P_IP:
> 
> Ugh.
> 
> Looks like a bug in the AX25 layer.

Well... Not a classic bug - misdesign probably. However, current
packet scheduler just asks for things like that.

> I think it's not nice to let the upper layer handle the retry in all cases,
> although it's only needed in a few special cases. Using netif_rx for the
> uncommon case of reexamining the packet is better, because you keep it out
> of the fast path.

Why is it better? It's slower, requires more operations as a whole (packets
being handled twice). It probably decreases latency marginally for other
devices.

BTW: AX25 does exactly what I propose, except that it's done internally,
and it's ugly.

> I don't see the twice examining by taps as a problem, 
> it doesn't break anything as far as I know.

Except taps which get packets twice, while there is just one packet
- it takes time as well, doesn't it?



However we could do that another way - probably better and certainly
giving more options:

inline void process_skb(skb)
{
... look at ptype_base[] and call func();
}

and then net_rx_action() would call that function to dispatch packets
to individual handlers, which would have an option to:
- netif_rx() the packet, or
- call process_skb()

It doesn't change net_rx_action() (except that we make a separate inline
function from a part of it), and we could have a clean lower layer design.

We could even change return value of packet_type->func() to 'void',
and get rid of deliver_to_old_ones() to clean things up.

Objections?
-- 
Krzysztof Halasa
Network Administrator

<Prev in Thread] Current Thread [Next in Thread>