* Flush Tx skbs after link down
@ 2003-01-15 8:31 Feldman, Scott
2003-01-15 9:50 ` Stefan Rompf
0 siblings, 1 reply; 3+ messages in thread
From: Feldman, Scott @ 2003-01-15 8:31 UTC (permalink / raw)
To: netdev; +Cc: Cramer, Jeb J
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
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Flush Tx skbs after link down
2003-01-15 8:31 Flush Tx skbs after link down Feldman, Scott
@ 2003-01-15 9:50 ` Stefan Rompf
2003-01-15 9:57 ` Stefan Rompf
0 siblings, 1 reply; 3+ messages in thread
From: Stefan Rompf @ 2003-01-15 9:50 UTC (permalink / raw)
To: Feldman, Scott; +Cc: netdev, Cramer, Jeb J
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
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Flush Tx skbs after link down
2003-01-15 9:50 ` Stefan Rompf
@ 2003-01-15 9:57 ` Stefan Rompf
0 siblings, 0 replies; 3+ messages in thread
From: Stefan Rompf @ 2003-01-15 9:57 UTC (permalink / raw)
To: Feldman, Scott, netdev, Cramer, Jeb J
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-01-15 9:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-15 8:31 Flush Tx skbs after link down Feldman, Scott
2003-01-15 9:50 ` Stefan Rompf
2003-01-15 9:57 ` Stefan Rompf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).