On 2004-10-08 07:46, Robert Watson <rwatson_at_freebsd.org> wrote: > On Fri, 8 Oct 2004, Giorgos Keramidas wrote: > > > Are we allowed to change the prototype of ether_demux()? > > > > If yes, we could make ether_demux() return -1 if it frees the mbuf, and > > avoid calling random_harvest() on that particular frame. Note that I > > haven't had a chance to test build or run the following patch yet, but > > if anyone has a better idea or comments that would help us improve it, > > they're welcome. > > > > One note that I have taken down while writing this and I have to check > > is the possibility of calling random_harvest(m->m_data, 16, ...) with an > > mbuf whose m->m_data contains less than 16 bytes. > > I looked at a couple of things: > > - Move the harvesting before the call to ether_demux() > - Delete the harvesting call There are many ways in which the mbuf can get "taken away" from under ether_input()'s feet, now that I look at teh changes in more detail. The mbuf can go away in ether_demux() or ip_fastforward() or even deeper in netisr_dispatch() or ... so it's not very safe to keep the harvesting call after ether_demux(). I've added a sysctl to count the packets that are indeed passed to the random_harvest() function with my proposed patch, but I have a lingering suspicion that none is (because the mbuf is handled in ether_demux() and freed before the harvester has a chance to run). More on that later... > I haven't yet tried to make the harvesting call use real mbuf data, but > I'm somewhat dubious of the real value of that: Bill Simpson has pointed > out that in practice most hosts talk primarily to their default gateway or > a very small set of local peers. In a local area network where several machines are on the same LAN (virtual or not), the machines might be more than a handful though. I regularly ssh into 3-4 development/testing Solaris machines here. Then we have the DNS server, the Samba fileshares, and yes there's a gateway too. It all depends on what one considers a "very small set of local peers", I guess. > In interrupt-driven operation, you're > already reaping entropy from receiving the interrupt, so in that scenario, > I think there are diminishing returns from trying to also reap entropy at > the ether_demux() point. In the netperf branch, I've simply deleted it -- > that said, in polling operation, you don't get network interrupts so there > may be some benefit here for that. Hmmm, that sounds very reasonable. Can we make the call to the harvest function conditional on non-interrupt driven operation? > I'll prepare a candidate patch and post it in the next couple of days. Sure. I'll go on reading the source. I know you've been sort of offline so there's no reason to rush anything. Take your time ;-) - Giorgos PS: I dropped RE from the Cc: list since I'm sure they get too many email messages already.Received on Fri Oct 08 2004 - 10:26:27 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:16 UTC