<div dir="ltr">Thank you sirs. But in fact, I don't alloc/free for every packet. I did exactly as what you said---reuse. <div><br></div><div>I am a little confused why GFP_ATOMIC can work but GFP_KERNEL will cause the system to panic. Does it because that GFP_KERNEL can sleep in kmalloc, then ip_xmit_queue will be held or something? But anyway, GFP_ATOMIC works perfectly.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 2, 2014 at 1:15 AM, Mulyadi Santosa <span dir="ltr"><<a href="mailto:mulyadi.santosa@gmail.com" target="_blank">mulyadi.santosa@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Jan 2, 2014 at 12:41 PM, <<a href="mailto:Valdis.Kletnieks@vt.edu">Valdis.Kletnieks@vt.edu</a>> wrote:<br>
> On Thu, 02 Jan 2014 12:12:49 +0700, Mulyadi Santosa said:<br>
><br>
>> Other than what others have said, IMHO it is better to avoid such<br>
>> rapid alloc/free, assuming your code fragment is running on every<br>
>> packet reception/sending.<br>
>><br>
>> Instead, I suggest to allocate the memory before the ip_queue_xmit and<br>
>> use-reuse it inside ip_queue_xmit.<br>
><br>
> Be careful with re-entrancy issues - you'll want a separate instance of memory<br>
> for all possible concurrent callers of ip_queue_xmit (you may need one per<br>
> active interface, because you can e transmitting packets on multiple interfaces<br>
> at the same time).<br>
<br>
</div></div>Ah yes, you're correct Valdis. Thanks for note.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
--<br>
regards,<br>
<br>
Mulyadi Santosa<br>
Freelance Linux trainer and consultant<br>
<br>
blog: <a href="http://the-hydra.blogspot.com" target="_blank">the-hydra.blogspot.com</a><br>
training: <a href="http://mulyaditraining.blogspot.com" target="_blank">mulyaditraining.blogspot.com</a><br>
</div></div></blockquote></div><br></div>