Hi,
I came to a situation that requires to send multiple TCP packets (one
for each connection) from a kernel thread as soon as possible. The
following is the skeleton of my code:
kernel_thread()
{
foreach sk in (alive connections){
tp = &(sk->tp_pinfo.af_tcp);
skb = alloc_skb(xxx, GFP_ATOMIC);
/* build TCP header */
tcp_build_and_update_options(.....);
tp->af_specific->send_check(sk, th, skb->len, skb);
tp->af_specific->queue_xmit(skb);
printk("packet send out for sk %p, at %lu\n", sk, jiffies);
}
}
the output is always like this:
packet send out for sk 1 at 1000
packet send out for sk 2 at 1001
packet send out for sk 3 at 1002
...
It looks like this kernel thread get rescheduled after it has sent out 1
packet. But why? each iteration certainly does not need 10ms, why it get
rescheduled? Is it because af_specific->queue_xmit() is blocking
operation? but I notice that tcp_transmit_skb() also call it, and
tcp_transmit_skb() should not call any blockalbe operation. I try to
increase its priority or change its schedule policy,but has no effect
at all. Any suggestion is appreciated! This is really urgent.
Ronghua
On Sun, Jun 29, 2003 at 10:37:12AM -0400, Ronghua Zhang wrote:
> Hi,
> I came to a situation that requires to send multiple TCP packets (one
> for each connection) from a kernel thread as soon as possible. The
> following is the skeleton of my code:
I should say this is a heissenbug ... one which happens because
you are observing it with printk().
> kernel_thread()
> {
> foreach sk in (alive connections){
> tp = &(sk->tp_pinfo.af_tcp);
>
> skb = alloc_skb(xxx, GFP_ATOMIC);
> /* build TCP header */
> tcp_build_and_update_options(.....);
> tp->af_specific->send_check(sk, th, skb->len, skb);
>
> tp->af_specific->queue_xmit(skb);
> printk("packet send out for sk %p, at %lu\n", sk, jiffies);
> }
> }
>
> the output is always like this:
> packet send out for sk 1 at 1000
> packet send out for sk 2 at 1001
> packet send out for sk 3 at 1002
> ...
>
> It looks like this kernel thread get rescheduled after it has sent out 1
> packet. But why? each iteration certainly does not need 10ms, why it get
> rescheduled? Is it because af_specific->queue_xmit() is blocking
> operation? but I notice that tcp_transmit_skb() also call it, and
> tcp_transmit_skb() should not call any blockalbe operation. I try to
> increase its priority or change its schedule policy,but has no effect
> at all. Any suggestion is appreciated! This is really urgent.
>
>
> Ronghua
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
I don't think so, because the timestamp is when prinkt is called, not when
the content is actually printed out, and printk will not block.
Ronghua
On Sun, 29 Jun 2003, Matti Aarnio wrote:
> On Sun, Jun 29, 2003 at 10:37:12AM -0400, Ronghua Zhang wrote:
> > Hi,
> > I came to a situation that requires to send multiple TCP packets (one
> > for each connection) from a kernel thread as soon as possible. The
> > following is the skeleton of my code:
>
> I should say this is a heissenbug ... one which happens because
> you are observing it with printk().
>
> > kernel_thread()
> > {
> > foreach sk in (alive connections){
> > tp = &(sk->tp_pinfo.af_tcp);
> >
> > skb = alloc_skb(xxx, GFP_ATOMIC);
> > /* build TCP header */
> > tcp_build_and_update_options(.....);
> > tp->af_specific->send_check(sk, th, skb->len, skb);
> >
> > tp->af_specific->queue_xmit(skb);
> > printk("packet send out for sk %p, at %lu\n", sk, jiffies);
> > }
> > }
> >
> > the output is always like this:
> > packet send out for sk 1 at 1000
> > packet send out for sk 2 at 1001
> > packet send out for sk 3 at 1002
> > ...
> >
> > It looks like this kernel thread get rescheduled after it has sent out 1
> > packet. But why? each iteration certainly does not need 10ms, why it get
> > rescheduled? Is it because af_specific->queue_xmit() is blocking
> > operation? but I notice that tcp_transmit_skb() also call it, and
> > tcp_transmit_skb() should not call any blockalbe operation. I try to
> > increase its priority or change its schedule policy,but has no effect
> > at all. Any suggestion is appreciated! This is really urgent.
> >
> >
> > Ronghua
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>