Julian Elischer writes:
>
>
> On Wed, 27 Mar 2002, Andrew Gallatin wrote:
>
> >
> > Archie Cobbs writes:
> > > Luigi Rizzo writes:
> > > > > Is if_tx_rdy() something that can be used generally or does it only
> > > > > work with dummynet ?
> > > >
> > > > well, the function i
On Wed, 27 Mar 2002, Andrew Gallatin wrote:
>
> Archie Cobbs writes:
> > Luigi Rizzo writes:
> > > > Is if_tx_rdy() something that can be used generally or does it only
> > > > work with dummynet ?
> > >
> > > well, the function is dummynet-specific, but I would certainly like
> > > a g
On Wed, 27 Mar 2002, Archie Cobbs wrote:
> Luigi Rizzo writes:
> > > Is if_tx_rdy() something that can be used generally or does it only
> > > work with dummynet ?
> >
> > well, the function is dummynet-specific, but I would certainly like
> > a generic callback list to be implemented in ifnet
On Wed, 27 Mar 2002, Luigi Rizzo wrote:
> On Wed, Mar 27, 2002 at 09:53:00AM -0800, Archie Cobbs wrote:
> ...
> > > managed and can be extended to point to additional ifnet state that
> > > does not fit in the immutable one...
> >
> > Why is it important to avoid changing 'struct ifnet' ?
>
>
On Wed, Mar 27, 2002 at 09:53:00AM -0800, Archie Cobbs wrote:
...
> > managed and can be extended to point to additional ifnet state that
> > does not fit in the immutable one...
>
> Why is it important to avoid changing 'struct ifnet' ?
backward compatibility with binary-only drivers ...
Not th
Archie Cobbs writes:
> Luigi Rizzo writes:
> > > Is if_tx_rdy() something that can be used generally or does it only
> > > work with dummynet ?
> >
> > well, the function is dummynet-specific, but I would certainly like
> > a generic callback list to be implemented in ifnet which is
> > i
Luigi Rizzo writes:
> > Is if_tx_rdy() something that can be used generally or does it only
> > work with dummynet ?
>
> well, the function is dummynet-specific, but I would certainly like
> a generic callback list to be implemented in ifnet which is
> invoked on tx_empty events.
Me too :-)
> T
On Tue, Mar 26, 2002 at 10:48:33PM -0800, Archie Cobbs wrote:
> Luigi Rizzo writes:
> > As a matter of fact, i even implemented a similar thing in dummynet,
> > and if device drivers call if_tx_rdy() when they complete a
> > transmission, then the tx interrupt can be used to clock
> > packets out
Luigi Rizzo writes:
> > Along those lines, this might be a handy thing to add...
> >
> > int if_get_next(struct ifnet *ifp); /* runs at splimp() */
> >
> > This function tries to "get" the next packet scheduled to go
> > out interface 'ifp' and, if successful, puts it on &ifp->if
Luigi Rizzo writes:
> As a matter of fact, i even implemented a similar thing in dummynet,
> and if device drivers call if_tx_rdy() when they complete a
> transmission, then the tx interrupt can be used to clock
> packets out of the dummynet pipes. A patch for if_tun.c is below,
So if_tx_rdy() so
the ENOBUFS is very typical with UDP applications that try to
send as fast as possible (e.g. the various network test utilities
in ports), and as i said in a previous message, putting up a mechanism to
pass around queue full/queue not full events is expensive because
it might trigger on every sing
On Tue, Mar 26, 2002 at 10:10:05PM -0800, Archie Cobbs wrote:
> Luigi Rizzo writes:
...
> Along those lines, this might be a handy thing to add...
>
> int if_get_next(struct ifnet *ifp); /* runs at splimp() */
>
> This function tries to "get" the next packet scheduled to go
> o
Luigi Rizzo writes:
> > >if you could suggest a few modifications that would be required, i'd like
> > >to pursue this further.
> >
> > Look at tsleep/wakeup on ifnet of if_snd.
>
> I am under the impression that implementing this mechanism would
> not be so trivial. It is not immediate to tell
Matthew Luckie wrote:
> hmm, we looked at how other protocols handled the ENOBUFS case from
> ip_output.
>
> tcp_output calls tcp_quench on this error.
>
> while the interface may not be able to send any more packets than it
> does currently, closing the congestion window back to 1 segment
> I am under the impression that implementing this mechanism would
> not be so trivial.
hmm, we looked at how other protocols handled the ENOBUFS case from
ip_output.
tcp_output calls tcp_quench on this error.
while the interface may not be able to send any more packets than it does
currently,
On Mon, Mar 25, 2002 at 02:06:19PM -0800, Lars Eggert wrote:
> Matthew Luckie wrote:
> >>>Is there a mechanism to tell when ip_output should be called again?
...
> >if you could suggest a few modifications that would be required, i'd like
> >to pursue this further.
>
> Look at tsleep/wakeup on if
On Mon, 25 Mar 2002, Matthew Luckie wrote:
> Hi
>
>
> Is there a mechanism to tell when ip_output should be called again?
> Ideally, I would block until such time as i could send it via ip_output
no, there is no such mechanism that I know of..
>
> (please CC: me on any responses)
>
> Mat
Lars Eggert wrote:
> Matthew Luckie wrote:
>
Is there a mechanism to tell when ip_output should be called again?
Ideally, I would block until such time as i could send it via ip_output
>>>
>>>
>>> You probably get that because the outbound interface queue gets full,
>>> so you want to
Matthew Luckie wrote:
>>>Is there a mechanism to tell when ip_output should be called again?
>>>Ideally, I would block until such time as i could send it via ip_output
>>
>>You probably get that because the outbound interface queue gets full, so
>>you want to block your caller until space becomes
> > Is there a mechanism to tell when ip_output should be called again?
> > Ideally, I would block until such time as i could send it via ip_output
>
> You probably get that because the outbound interface queue gets full, so
> you want to block your caller until space becomes available there. Th
Matthew Luckie wrote:
> I have written a syscall that creates a packet in kernel-space,
> timestamps it, and then sends it via ip_output
>
> If the user-space application uses this system call faster than the
> packets can be sent, ip_output will return ENOBUFS.
>
> Is there a mechanism to tell
21 matches
Mail list logo
