On Tuesday 02 August 2005 07:30, Patrick McHardy wrote: > Daniel Phillips wrote: > > ...being a net newbie, it is not entirely > > clear to me that we can call netif_receive_skb directly when packets are > > also being queued through the softnet interface. May I have some > > guidance on this point, please? > > > > If that works, I am prepared to justify and prove the rest. > > It can cause reordering, but I think it should be possible.
That is encouraging. Re reordering, I thought that any protocol that breaks because of packet reordering is already broken? > But there > can also be other memory allocations, like dst_alloc, secpath_alloc, > ipq_alloc, ip_conntrack_alloc, ..., which you need to take care of. > Socket delivery is last on the input path and a lot can happen to a > packet in between. Yes, each path has to be memory-bounded if it isn't going to deadlock under block IO. Probably, most of that is already memory-bounded, but all paths will need auditing. I plan to invoke the whole delivery path in PF_MEMALLOC mode, which gives these paths access to a general pool of reserve memory without needing to code, e.g., mempool reserves throughout. So long as everything is properly bounded, this is supposed to work. To do the job properly, the size of the memalloc reserve should be calculated as the maximum number of requests that may be in flight, times the sum of the maximum requirement per request of each "feature path" in the packet handling path. > IIRC Linus called the whole swapping over ISCSI idea > broken because apparently even userspace needs to allocate memory in > some situations to make things work. Even a user space task may run in PF_MEMALLOC mode (and so guarantee its syscalls access to a modest amount of working memory) so long as it follows the same rules as a kernel task: all per-request memory usage must be statically analyzable and bounded. But I am getting ahead of myself: the immediate challenge is to deal accurately with the network-receive facet of this multi-facetted problem. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
