Flush Tx skbs after link down

Flush Tx skbs after link down

[Feldman, Scott]

Someone most know the answer to this: What's the proper way to dispose
of Tx skbs that are owned by the h/w ("in-flight") when link was lost?
Lets say your h/w stops Tx processing when link is lost, but you've got
apps waiting for those Tx resources to be returned.  h/w isn't giving
those resources back until link is up.  Bonding doesn't like this.

We've tried walking the h/w list, and skb_orphan'ing the skbs, but that
only works if the usage count = 1.  The other solution is to tear down
and rebuild the Tx ring, but that requires a h/w reset to recover.  Yuk!

Any ideas?

-scott

Re: Flush Tx skbs after link down

[Stefan Rompf]

Hi,

> Someone most know the answer to this: What's the proper way to dispose
> of Tx skbs that are owned by the h/w ("in-flight") when link was lost?

I think this can't be achieved without driver support, simply because
pending DMA transfers must be removed before freeing the skbs, and this
is specific. So the driver model needs to be extended to have a reset
method similiar to the qdiscs. If available, this method is called on
link down event by the linkwatch stuff included in recent 2.5 kernels.

Stefan

Re: Flush Tx skbs after link down

[Stefan Rompf]

> I think this can't be achieved without driver support, simply because
> pending DMA transfers must be removed before freeing the skbs, and this
> is specific. So the driver model needs to be extended to have a reset

PS: We also need to avoid that new skbs are enqueued while the link is
down without making the critical code path in dev_queue_xmit() much
longer. Right now, I don't have any ideas beyond a proof of concept for
this part.

Stefan