Peter Teoh wrote: > inside squeue.c: > > 78 * > 79 * Once created, squeues are never deleted. Hence squeue pointers are > > 80 * always valid. This means that functions outside the squeue can > still > 81 * refer safely to conn_sqp and their is no need for ref counts. > 82 * > > if squeue are attached to a particular network card interface, and then > the RJ45 wire is hotplugged removed, and the reattached to another RJ45 > port, won't that create a problem - as all the threads queued are never > requeued on the other interface?
There are probably performance issues related to receiving and transmitting traffic on a different interface, but it's unclear to me exactly how these things are related. It's really not as simple as just looking at the wires. For instance, the CPU on which an application thread is dispatched seems to have no particular relationship to the CPU binding for any of that application's squeues. My understanding of how this works is that if a given squeue has no CPU thread executing within its perimeter (CPUs sometimes do work other than networking, so it does happen), then direct entry on another CPU is possible, and any outstanding work within the squeue will happen at that time. The implication is that in the scenario you cite, you'd stop receiving interrupts on the CPU related to the first interface, and start getting them on the CPU for the second. Those threads would find that they've got mostly uncontended entry into the squeues because the first CPU isn't doing that work now. (But that's just my high-level understanding; it sounds like you need more than that.) The FireEngine folks don't seem to have piped up on this thread yet. I'd suggest trying over on crossbow-disc...@opensolaris.org, as many of the folks on the Crossbow team were also on the previous FireEngine team, and they're the ones with the detailed design information. > And this persistent existence of the > squeue pointer could be a problem - in all possible manifestation (DoS, > memory leak etc). I don't understand the concern related to DoS or memory leaks. Non-privileged users and external entities (i.e., received network traffic) are not able to create squeues, so the DoS aspect is unclear. As for memory leaks, if any existed, those would just be bugs related to resource allocations that are mishandled. How does the defined persistence of an object relate directly to whether or not there are bugs? It seems to me as though an assertion like that would have to be based on the design details of the code itself. -- James Carlson 42.703N 71.076W <carls...@workingcode.com> _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
