Ok, I will fix my patch in this way. I will resend it. Should I also rebase following patches in the patch serie and resent them also? Thanks Andrea On Tue, Feb 18, 2014 at 8:22 PM, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > On Tue, Feb 18, 2014 at 08:06:51PM +0100, Andrea Merello wrote: >> Thank for pointing out this. Yes, I probably exaggerated trying hard >> to allocate memory. >> >> If your point is about if pci_map_single may or not ever fail in real >> life (that is was I thought you meant in your first mail), then I >> think that it's worth to keep the check anyway (I think it could >> happen). > > Please keep the check. > >> >> If your point is that it can be not so much useful to try and retry >> hard the allocation (I must admit I'm not even sure that after freeing >> the skb the kernel will not likely re-allocate the same one at the >> next try), then I will keep the error check, but I can remove code >> that retries allocation (failing at the first error as you suggested). > > Yes. Please remove the retry code unless there is some real life > justification for it where you have seen partial allocations before. > >> >> BTW consider that the allocation is done in ieee80211 start callback, >> that is called every time the interface is brought down/up, and not >> once at the begining. >> > > You are right. I didn't realize that. > >> On one hand I cared avoiding wasting memory when the interface is not up. >> On the other hand I had thought also to move memory allocation in >> initialization, exactly to increase success probability as you pointed >> out.. >> >> I chosen the first option because after the interface is brought up, >> the RX ant TX processes will start to perform a lot of other skb >> allocations and dma maps. >> If we assume, as you pointed out, they will likely ALL fail or >> succeeds, not just few of them, then probably even if we allocated >> some memory at init time, we have gained not advantage. >> >> Do you agree ? > > Yes. > > regards, > dan carpenter > > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
