Hey!
On Wed, 22 Mar 2000 kuznet@xxxxxxxxxxxxx wrote:
> > Just one more question, about backporting: spinlock_bh doesn't exist in
> > 2.2 AFAICS, I guess I need to use spinlock_irqsave?
>
> You need not any spinlock in 2.2.
>
> In 2.2 all xmit path executes only on BH, it is single thread
> and no more locks are required.
Okay, yeah, now I remember... However, it's not true as long as the lock
might be grabbed from (pppd) process context, right. So, basically I do
have two options: Use spinlock_irqsave, which is always safe, or schedule
a task from process context, so the lock will always be grabbed from BH. I
think I prefer the latter.
> Yes, it is true provided it is never used from hard irq!
> If it is, then you have to use irq protection in 2.3 as well.
> Or better to queue a BH task.
If it was called from interrupt, that would be a bug that needs to be
fixed (I put some detection code in, so I'll find out. Doesn't seem to
happen)
>
> > netif_stop_queue();
>
> It is better to avoid to use netif_stop_queue(dev) outside
> of spin_lock_bh(&dev->xmit_lock). Most of devices sets it only
> in hard_start_xmit(), where this lock is grabbed by caller.
>
> If you submit frame internally, it is not bad idea to acquire
> this lock. It is not necessary, but you will lose the property
> that hard_start_xmit is not entered when device is throttled.
> If it is not a problem for your device, then this is not required.
Well, if hard_start_xmit() is called although we're busy (due to the
apparent race when not holding the lock, I guess), I'll notice and return
1. So no problem here.
However, it's okay to grab dev->xmit_lock? I mean, is it kind of an
exported interface? If I can use it, I can get rid of my
channel->xmit_lock entirely. That'd make the code easier, so it's a good
thing. The channel lock has finer granularity, but the contention equals
zero in real life any way, so who cares?
cu,
Kai
|