lander writes:
> In Net_device, there is a "tx_queue_len" member, which by default is
> 100 or 1000(1G ethernet), where is the memory of this queue's memory
> loated?

Nowhere. It is the maximum number of skbs ('struct sk_buff') the
network layer will queue while the interface queue has been stopped by
the driver, usually, because the hardware is currently busy and cannot
accept new transmission requests. The structures themselves are
dynamically allocated from RAM.

> If it's in the hardware device, this value shall be modified in
> driver's initialization routine according to the actual length of Tx
> queue in the hardware, right?

Why this?

On 10ÔÂ5ÈÕ, ÏÂÎç5ʱ53·Ö, Rainer Weikusat wrote:
> lander writes:
> > In Net_device, there is a "tx_queue_len" member, which by default is
> > 100 or 1000(1G ethernet), where is the memory of this queue's memory
> > loated?
>
> Nowhere. It is the maximum number of skbs ('struct sk_buff') the
> network layer will queue while the interface queue has been stopped by
> the driver, usually, because the hardware is currently busy and cannot
> accept new transmission requests. The structures themselves are
> dynamically allocated from RAM.
>
> > If it's in the hardware device, this value shall be modified in
> > driver's initialization routine according to the actual length of Tx
> > queue in the hardware, right?
>
> Why this?

If the buffer is located in the internal RAM of the network hardware,
the initialization routine shall notify the driver how long the queue
is, and driver can notify uppper layer when the queue is full.

lander writes:
> On 10ÔÂ5ÈÕ, ÏÂÎç5ʱ53·Ö, Rainer Weikusat wrote:
>> lander writes:
>> > In Net_device, there is a "tx_queue_len" member, which by default is
>> > 100 or 1000(1G ethernet), where is the memory of this queue's memory
>> > loated?
>>
>> Nowhere. It is the maximum number of skbs ('struct sk_buff') the
>> network layer will queue while the interface queue has been stopped by
>> the driver, usually, because the hardware is currently busy and cannot
>> accept new transmission requests. The structures themselves are
>> dynamically allocated from RAM.
>>
>> > If it's in the hardware device, this value shall be modified in
>> > driver's initialization routine according to the actual length of Tx
>> > queue in the hardware, right?
>>
>> Why this?
>
> If the buffer is located in the internal RAM of the network
> hardware,

There is no 'queue buffer' involved here and present-day network
interfaces are usually DMA-capable, meaning, the host CPU gets an
interrupt after the DMA-engine coupled with the MAC has transferred a
complete frame from main memory to the NIC (and the corresponding
DMA queue slot can be reused).

On 10ÔÂ6ÈÕ, ÏÂÎç4ʱ52·Ö, Rainer Weikusat wrote:
> lander writes:
> > On 10ÔÂ5ÈÕ, ÏÂÎç5ʱ53·Ö, Rainer Weikusat wrote:
> >> lander writes:
> >> > In Net_device, there is a "tx_queue_len" member, which by default is
> >> > 100 or 1000(1G ethernet), where is the memory of this queue's memory
> >> > loated?
>
> >> Nowhere. It is the maximum number of skbs ('struct sk_buff') the
> >> network layer will queue while the interface queue has been stopped by
> >> the driver, usually, because the hardware is currently busy and cannot
> >> accept new transmission requests. The structures themselves are
> >> dynamically allocated from RAM.
>
> >> > If it's in the hardware device, this value shall be modified in
> >> > driver's initialization routine according to the actual length of Tx
> >> > queue in the hardware, right?
>
> >> Why this?
>
> > If the buffer is located in the internal RAM of the network
> > hardware,
>
> There is no 'queue buffer' involved here and present-day network
> interfaces are usually DMA-capable, meaning, the host CPU gets an
> interrupt after the DMA-engine coupled with the MAC has transferred a
> complete frame from main memory to the NIC (and the corresponding
> DMA queue slot can be reused).- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
>
> - ÏÔʾÒýÓõÄÎÄ×Ö -

I'll look into the code. Thanks !