All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sergei.shtylyov@gmail.com>
To: Matthias-Christian Ott <ott@mirix.org>,
	Petko Manolov <petkan@nucleusys.com>
Cc: linux-usb@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH] net: usb: pegasus: Do not drop long Ethernet frames
Date: Mon, 27 Dec 2021 12:56:41 +0300	[thread overview]
Message-ID: <36ee5c5c-a03c-c9f5-dd5c-9e3a04b0374a@gmail.com> (raw)
In-Reply-To: <20211226132930.7220-1-ott@mirix.org>

Hello!

On 26.12.2021 16:29, Matthias-Christian Ott wrote:

> The D-Link DSB-650TX (2001:4002) is unable to receive Ethernet frames
> that are longer than 1518 octets, for example, Ethernet frames that
> contain 802.1Q VLAN tags.
> 
> The frames are sent to the pegasus driver via USB but the driver
> discards them because they have the Long_pkt field set to 1 in the
> received status report. The function read_bulk_callback of the pegasus
> driver treats such received "packets" (in the terminology of the
> hardware) as errors but the field simply does just indicate that the
> Ethernet frame (MAC destination to FCS) is longer than 1518 octets.
> 
> It seems that in the 1990s there was a distinction between
> "giant" (> 1518) and "runt" (< 64) frames and the hardware includes
> flags to indicate this distinction. It seems that the purpose of the
> distinction "giant" frames was to not allow infinitely long frames due
> to transmission errors and to allow hardware to have an upper limit of
> the frame size. However, the hardware already has such limit with its
> 2048 octet receive buffer and, therefore, Long_pkt is merely a
> convention and should not be treated as a receive error.
> 
> Actually, the hardware is even able to receive Ethernet frames with 2048
> octets which exceeds the claimed limit frame size limit of the driver of
                                    ^^^^^            ^^^^^
    Too many limits. :-)

> 1536 octets (PEGASUS_MTU).
> 
> Signed-off-by: Matthias-Christian Ott <ott@mirix.org>
[...]

MBR, Sergey

  parent reply	other threads:[~2021-12-27  9:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-26 13:29 [PATCH] net: usb: pegasus: Do not drop long Ethernet frames Matthias-Christian Ott
2021-12-26 15:39 ` Andrew Lunn
2021-12-26 16:01   ` Matthias-Christian Ott
2021-12-26 16:31     ` Andrew Lunn
2021-12-26 22:21       ` Matthias-Christian Ott
2021-12-26 22:28     ` Petko Manolov
2021-12-27  9:56 ` Sergei Shtylyov [this message]
2022-01-02 14:22   ` Matthias-Christian Ott

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=36ee5c5c-a03c-c9f5-dd5c-9e3a04b0374a@gmail.com \
    --to=sergei.shtylyov@gmail.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ott@mirix.org \
    --cc=petkan@nucleusys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.