lkml.org 
[lkml]   [1998]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.070 / U:0.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site