Date: Mon, 25 May 1998 12:18:00 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: Julian Elischer <julian@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-sys@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf options src/sys/netinet ip_divert.c Message-ID: <Pine.BSF.3.95.980525120612.1187A-100000@current1.whistle.com> In-Reply-To: <199805251216.OAA20496@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 25 May 1998, Luigi Rizzo wrote: > > The new semantic (which is how we should have done it the first time) > > is that the port number in the sendto() is the rule number AFTER which > > processing should restart, and on a recvfrom(), the port number is the > > rule number which caused the diversion. This is much more flexible, > > and also more intuitive. If the user uses the same sockaddr received > > for sure it is more flexible, but to me it is not that intuitive to > mix port and rule numbers. What about your original idea (that i > implemented in dummynet) of adding a field to the m_pkthdr so that you > can carry around a pointer to the matching rule and be able to do the > right thing later on the packet ? Actually that was your interpretation of two different ideas merged together.. :-) I always intended to redo the 'reinjection' semantic this way. In my opinion there should be no state within the kernel that is relied on by the diverting daemon to reinject it's packets back to where they should go. The diverting daemon should be able to fabricate and inject packets that have never been diverted, as part of it's task. Using an extra field in the mbuf to hold a reference to a rule is only a way of getting rid of the horrible global variables. It also gives you a place to pass out 'flow' information to (say) ALTQ. The main part of this change was to change what the number passed back DOES. I didn't want to change too many things at once. Just because I did this doesn't mean I'm not going to dop other things as well :-) for example the SKIPTO optimisation you did will probably make it in in the next day or so. > > (BTW the divert hack, i never fully understood if/how it works in case > the processing for a diverted packet is suspended, or multiple copies > of the packet are generated -- since there is > only one state variable for this purpose). DIVERT packets are totally asynchronous. you may pass out 1200 packets and only get the first one back after the last one goes out, or you may get totally fabricated packets. The daemon may decide to arbitrarily discard a packet. This is why there must be no held state in the kernel and injected packets must not require some state in the kernel. This is why all you can do is specify a rule number to start after. It will always succeed. > This is a problem in dummynet, but i wonder if it also has some > interaction with TEE rules or multicast traffic. > > cheers > luigi > -----------------------------+-------------------------------------- > Luigi Rizzo | Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it | Universita' di Pisa > tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ > _____________________________|______________________________________ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980525120612.1187A-100000>