On 21 Aug 2017, at 1:11, Gopakumar Pillai wrote:
Looks like later FreeBSD already has some amount of queueing from what
Oleg has pointed out:
$ sysctl net.link.ether.inet.maxhold
net.link.ether.inet.maxhold: 1
As Mike mentioned, my fix looks into a logical IP packet. And it keeps
only one logical IP packet – i.e 64K bytes – 43 packets. I did
test it in my code, didn’t see any issues yet.
Latest FreeBSD code would keep the specified number of physical IP
packets, possible to have more than one logical IP packet, but could
possibly break a logical IP packet too.
I do now understand its not a big deal, especially since there’s a
way to configure that in latest FreeBSD code. I shall fix my code one
of the above 2 ways.
Why not just set maxhold to your favorite value (e.g. 43?).
Thank You all for your support and help.
--Gopu
On 8/19/17, 9:56 AM, "Mike Karels" <m...@karels.net> wrote:
On 19 Aug 2017, at 4:00, Julian Elischer wrote:
> On 18/8/17 11:33 am, Mike Karels wrote:
>> Another $.02 (inline):
>>
>> On 17 Aug 2017, at 18:39, Gopakumar Pillai wrote:
>>
>>> Thank You Bjoern. Could you please point me to the RFC?
>>
>> I don’t know if there is anything more recent than RFC1122 on
this.
>> IIRC, it requires queuing at least one packet. Queing one
packet is
>> what BSD has done essentially since ARP was implemented.
>
> This asks the question: One physical packet or one logical
packet?
> Gopakumar's change effectively changes the queuing from one
physical
> packet to the logical one.
> The next question becomes "how much extra work do we do to
achieve
> this and does it affect anything else"?
That isn’t the whole question. It’s one physical packet, one
logical packet, or multiple frames?
It makes more sense to me to support multiple frames rather than
just
one logical packet. However,
I don’t see a good reason to change from the current code.
>>> If this is not a MUST behavior in RFC, would my fix be good? I
agree
>>> that this would affect only ICMP/UDP traffic.
>>
>> People have been asking for queuing of multiple packets for
years.
>> That is a more general change. Consider another dumb
application
>> that starts out by sending multiple UDP packets back-to-back.
>> However, well-designed application protocols don’t experience
>> problems like this. I’ll quickly note that ping isn’t an
>> application, but a network measuring tool. If you ask the
question
>> “what happens if I start off a session with a single large
packet
>> and I don’t support retransmission”, ping answers that
question
>> correctly.
>>
>> If badly-designed protocols get bad performance, that doesn’t
seem
>> like a bug to me, but a feature.
>>
>>> On 8/17/17, 2:40 PM, "Bjoern A. Zeeb"
>>> <bzeeb-li...@lists.zabbadoz.net> wrote:
>>>
>>> On 17 Aug 2017, at 21:16, Gopakumar Pillai wrote:
>>>
>>> > Hi FreeBSD Networking Gurus,
>>> > I came across an issue with an old version of FreeBSD
and
>>> looking at
>>> > the latest FreeBSD code, seems it exists even now. I am
>>> assuming that
>>> > this issue is not reported.
>>> >
>>> > Observation:
>>> > When a ping was performed with larger payload than MTU,
the
>>> first ping
>>> > failed when the ARP entry was absent for that IP.
>>>
>>> That is because ping/ICMP has no retransmit.
>>>
>>>
>>> > Noticed on the wire that the last IP fragment was sent
for the
>>> first
>>> > request and then the subsequent requests were fine.
>>> >
>>> > Root Cause:
>>> > * ip_output fragments the packets and loops through
the
>>> fragments to
>>> > send them to ether_output.
>>> > * ether_output does an arpresolve and if there is no
>>> existing ARP
>>> > entry it'll return EWOULDBLOCK after sending ARP
Request.
>>> > * ether_output ignores the error and propagates
success to
>>> ip_output
>>> > and it continues to send the remaining fragments.
>>> > * llentry keeps only one mbuf and the last fragment is
>>> retained when
>>> > the ARP Reply comes and the fragment is sent.
>>>
>>> Yes, according to the spec (RFC) we are supposed to throw
the
>>> packet
>>> away entirely and simply report that to the next upper
layer.
>>> However
>>> over the years people realised that this sucks for a TCP
SYN
>>> packet with
>>> a retransmit timer and hence we store one of them.
>>>
>>> A large UDP packet would btw see the same behaviour to
your
>>> ping.
>>> There’s no guarantee any of these packets will not be
dropped
>>> anywhere
>>> on the network, so we can as well.
>>>
>>> Just my 2ct
>>>
>>> /bz
>>
>> Mike
>> _______________________________________________
>> freebsd-net@freebsd.org mailing list
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freebsd.org_mailman_listinfo_freebsd-2Dnet&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=SPMIiiJNfXk7ujuip5qobK77LnnVM8kVNC-LzM_0RWk&m=gVqPCwvWs-eO0Y8jGefr8abxlnmG_GklVISDsn3solU&s=_748SiGYexZf7oZMSG2ZVDkzcelyZECM0lFMpbojDWA&e=
>> To unsubscribe, send any mail to
>> "freebsd-net-unsubscr...@freebsd.org"
>>
>>
>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freebsd.org_mailman_listinfo_freebsd-2Dnet&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=SPMIiiJNfXk7ujuip5qobK77LnnVM8kVNC-LzM_0RWk&m=gVqPCwvWs-eO0Y8jGefr8abxlnmG_GklVISDsn3solU&s=_748SiGYexZf7oZMSG2ZVDkzcelyZECM0lFMpbojDWA&e=
> To unsubscribe, send any mail to
"freebsd-net-unsubscr...@freebsd.org"
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
