From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Abraham vd Merwe <abraham@2d3d.co.za>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linux Kernel Development <linux-kernel@vger.kernel.org>
Subject: Re: questions about network device drivers
Date: Tue, 30 Jul 2002 10:57:08 -0400 [thread overview]
Message-ID: <3D46A944.9080401@mandrakesoft.com> (raw)
In-Reply-To: 20020730164853.A24348@crystal.2d3d.co.za
Abraham vd Merwe wrote:
> Hi Alan!
>
>
>>>hard_start_xmit() method
>>>========================
>>>
>>>when should this function return 0 and when should it return 1 and in which
>>>cases should it do netif_stop_queue() and/or free the dev_kfree_skb() ?
>>
>>0 - OK
>>1 - I am busy, give me it later.
>>
>>If you return 1 be sure to netif_stop_queue. The netif_wake_queue will
>>continue transmission
>
>
> In both cases, should I free the sk_buff structure or only if I return 0?
> Also, if I understand you correctly, I should _only_ call netif_stop_queue()
> if the function fails to transmit the packet?
>
> What about cases where the packet will always fail, e.g. the frame length is
> bigger than what the device supports. I take it in those cases I should
> return 0, but should I call netif_stop_queue() as well?
free it if you are returning zero. But of course, after the card has
handled the packet.
If you set your MTU correctly, you shouldn't get frames larger than
proper length.
netif_stop_queue and netif_start_queue and netif_wake_queue are your
queue management tools. _only_ enable the queue when there is room for
more packets.
Jeff
next prev parent reply other threads:[~2002-07-30 14:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-30 14:15 questions about network device drivers Abraham vd Merwe
2002-07-30 15:48 ` Alan Cox
2002-07-30 14:48 ` Abraham vd Merwe
2002-07-30 14:57 ` Jeff Garzik [this message]
2002-07-30 14:54 ` Jeff Garzik
2002-07-30 15:04 ` Russell King
2002-07-31 8:53 ` Abraham vd Merwe
-- strict thread matches above, loose matches on Subject: below --
2002-07-31 11:14 jamal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D46A944.9080401@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=abraham@2d3d.co.za \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox