Messages in this thread | | | Date | Wed, 29 Jul 1998 11:59:51 +0100 (GMT/BST) | From | Mike Jagdis <> | Subject | Re: about syslogd and printk() |
| |
On Wed, 22 Jul 1998 kuznet@ms2.inr.ac.ru wrote:
> > It doesn't seem unreasonable to be able to snoop a specific > > protocol in both directions rather than snooping everything > > and having to filter it in the application. Is there some > > standard we are following here? > > The reason not to make it is efficiency. > dev_queue_xmit_nit sits in fast path, and it is protected > by netdev_nit counter. (BTW it was bug in your patch: > if you did it, you should increment netdev_nit count in dev_add_pack()) > When you bind a socket to ETH_P_ALL, > you sign sort of contract, that you agreed to lose these ticks in fast path 8) > > Sure, you are right, such facility must exist, > especially taking into account that BPF does not look > at skb->protocol. New sockopt?
This, presumably, would reach down to set a flag on the device to tell dev_queue_xmit_nit to check the protocol specific list as well as the all list? Or could it be handled when the packet socket is bound? After all you have to bind to set the protocol so at that point you know which device is affected.
In fact should bound packet sockets be moved to device specific lists? The current global list with the device check inside the loop means that a single packet socket affects _every_ device. This sounds wrong. A machine running diald (with its snooping sockets) is, by definition, going to be acting as a router which is the sort of thing that wants a fast path between interfaces...
> > Something else is that diald really wants to know whether > > a packet is being received or transmitted on the interface, > > regardless of whether it orginated locally or is being forwarded > > for someone else. > > sll->sll_pkttype is PACKET_OUTGOING for transmitted packets > and it is PACKET_{HOST,BROADCAST,MULTICAST} for received > frames.
Ah, the comment in include/linux/if_packet.h is perhaps misleading then. For PACKET_OUTGOING it says "Originated by us". Maybe this should be changed to simply "Outgoing" and the comments for the others should be prefixed with "Incoming to"?
> > Taken with the above it sounds as though we > > could have some socket options on packet sockets which would > > allow processing of received/transmitted packets to be enabled > > and disabled. These could default to the current behaviour > > unless changed with setsockopt. Is that at all reasonable? > > Yes, it is very good idea. Have you some idea on name for > this sockopt? 8)8)
How about SOL_PACKET, PACKET_{INCOMING,OUTGOING}? We already have PACKET_OUTGOING defined for other reasons but it's just a number, right?
Mike
-- .----------------------------------------------------------------------. | Mike Jagdis | Internet: mailto:mike@roan.co.uk | | Roan Technology Ltd. | | | 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 | | RG40 1XG, ENGLAND | Fax: +44 118 989 1195 | `----------------------------------------------------------------------'
- 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.altern.org/andrebalsa/doc/lkml-faq.html
| |