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
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
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