On Fri, 18 Jul 2014, Adrian Chadd wrote:
On 18 July 2014 13:40, Bruce Evans wrote:
On Fri, 18 Jul 2014, hiren panchasara wrote:
On Wed, Jul 16, 2014 at 11:00 AM, Adrian Chadd wrote:
Hi!
So the UDP transmit path is udp_usrreqs->pru_send() == udp_send() ->
udp_output() -> ip_output()
udp_
> On Jul 18, 2014, at 23:34, Adrian Chadd wrote:
>
> It upsets the ALTQ people too.
I'm an ALTQ person (pfSense, so maybe one if the biggest) and I'm not upset.
That cr*p needs to die in a fire.
___
freebsd-net@freebsd.org mailing list
http://lists.
Hi,
On 18 July 2014 13:40, Bruce Evans wrote:
> On Fri, 18 Jul 2014, hiren panchasara wrote:
>
>> On Wed, Jul 16, 2014 at 11:00 AM, Adrian Chadd wrote:
>>>
>>> Hi!
>>>
>>> So the UDP transmit path is udp_usrreqs->pru_send() == udp_send() ->
>>> udp_output() -> ip_output()
>>>
>>> udp_output() d
On Fri, 18 Jul 2014, hiren panchasara wrote:
On Wed, Jul 16, 2014 at 11:00 AM, Adrian Chadd wrote:
Hi!
So the UDP transmit path is udp_usrreqs->pru_send() == udp_send() ->
udp_output() -> ip_output()
udp_output() does do a M_PREPEND() which can return ENOBUFS. ip_output
can also return ENOBU
On Wed, Jul 16, 2014 at 11:00 AM, Adrian Chadd wrote:
> Hi!
>
> So the UDP transmit path is udp_usrreqs->pru_send() == udp_send() ->
> udp_output() -> ip_output()
>
> udp_output() does do a M_PREPEND() which can return ENOBUFS. ip_output
> can also return ENOBUFS.
>
> it doesn't look like the sock
Hi!
So the UDP transmit path is udp_usrreqs->pru_send() == udp_send() ->
udp_output() -> ip_output()
udp_output() does do a M_PREPEND() which can return ENOBUFS. ip_output
can also return ENOBUFS.
it doesn't look like the socket code (eg sosend_dgram()) is doing any
buffering - it's just copying
Return values in sendto() manpage says:
[ENOBUFS] The system was unable to allocate an internal buffer.
The operation may succeed when buffers become avail-
able.
[ENOBUFS] The output queue for a network interface was ful
