On Mon, Feb 1, 2021 at 5:14 AM Martin Schiller wrote:
>
> But control frames are currently sent past the lapb write_queue.
> So another queue would have to be created.
>
> And wouldn't it be better to have it in the hdlc_x25 driver, leaving
> LAPB unaffected?
Hmm.. Indeed. I agree.
I also think
On 2021-02-01 12:38, Xie He wrote:
On Mon, Feb 1, 2021 at 1:18 AM Martin Schiller wrote:
I have thought about this issue again.
I also have to say that I have never noticed any problems in this area
before.
So again for (my) understanding:
When a hardware driver calls netif_stop_queue, the f
On Mon, Feb 1, 2021 at 1:18 AM Martin Schiller wrote:
>
> I have thought about this issue again.
>
> I also have to say that I have never noticed any problems in this area
> before.
>
> So again for (my) understanding:
> When a hardware driver calls netif_stop_queue, the frames sent from
> layer 3
On 2021-01-31 04:16, Xie He wrote:
On Sat, Jan 30, 2021 at 11:16 AM Jakub Kicinski
wrote:
Sounds like too much afford for a sub-optimal workaround.
The qdisc semantics are borken in the proposed scheme (double
counting packets) - both in term of statistics and if user decides
to add a policer,
On Sat, Jan 30, 2021 at 11:16 AM Jakub Kicinski wrote:
>
> Sounds like too much afford for a sub-optimal workaround.
> The qdisc semantics are borken in the proposed scheme (double
> counting packets) - both in term of statistics and if user decides
> to add a policer, filter etc.
Hmm...
Another
On Sat, 30 Jan 2021 06:29:20 -0800 Xie He wrote:
> On Fri, Jan 29, 2021 at 5:36 PM Jakub Kicinski wrote:
> > I'm still struggling to wrap my head around this.
> >
> > Did you test your code with lockdep enabled? Which Qdisc are you using?
> > You're queuing the frames back to the interface they ca
On Fri, Jan 29, 2021 at 5:36 PM Jakub Kicinski wrote:
>
> I'm still struggling to wrap my head around this.
>
> Did you test your code with lockdep enabled? Which Qdisc are you using?
> You're queuing the frames back to the interface they came from - won't
> that cause locking issues?
Hmm... Than
On Fri, 29 Jan 2021 06:56:10 +0100 Martin Schiller wrote:
> On 2021-01-28 23:06, Xie He wrote:
> > On Thu, Jan 28, 2021 at 11:47 AM Jakub Kicinski
> > wrote:
> >>
> >> Noob question - could you point at or provide a quick guide to
> >> layering
> >> here? I take there is only one netdev, and
On 2021-01-28 23:06, Xie He wrote:
On Thu, Jan 28, 2021 at 11:47 AM Jakub Kicinski
wrote:
Noob question - could you point at or provide a quick guide to
layering
here? I take there is only one netdev, and something maintains an
internal queue which is not stopped when HW driver stops the qdi
On Thu, Jan 28, 2021 at 11:47 AM Jakub Kicinski wrote:
>
> Noob question - could you point at or provide a quick guide to layering
> here? I take there is only one netdev, and something maintains an
> internal queue which is not stopped when HW driver stops the qdisc?
Yes, there is only one netde
On Wed, 27 Jan 2021 01:07:47 -0800 Xie He wrote:
> An HDLC hardware driver may call netif_stop_queue to temporarily stop
> the TX queue when the hardware is busy sending a frame, and after the
> hardware has finished sending the frame, call netif_wake_queue to
> resume the TX queue.
>
> However, t
On 2021-01-27 21:29, Xie He wrote:
On Wed, Jan 27, 2021 at 2:14 AM David Laight
wrote:
If I read this correctly it adds a (potentially big) queue between the
LAPB code that adds the sequence numbers to the frames and the
hardware
that actually sends them.
Yes. The actual number of outgoing
On Wed, Jan 27, 2021 at 2:14 AM David Laight wrote:
>
> If I read this correctly it adds a (potentially big) queue between the
> LAPB code that adds the sequence numbers to the frames and the hardware
> that actually sends them.
Yes. The actual number of outgoing LAPB frames being queued depends
From: Xie He
> Sent: 27 January 2021 09:08
>
> An HDLC hardware driver may call netif_stop_queue to temporarily stop
> the TX queue when the hardware is busy sending a frame, and after the
> hardware has finished sending the frame, call netif_wake_queue to
> resume the TX queue.
>
> However, the
An HDLC hardware driver may call netif_stop_queue to temporarily stop
the TX queue when the hardware is busy sending a frame, and after the
hardware has finished sending the frame, call netif_wake_queue to
resume the TX queue.
However, the LAPB module doesn't know about this. Whether or not the
ha
15 matches
Mail list logo
