All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Andriy Berestovskyy <Andriy.Berestovskyy@caviumnetworks.com>,
	Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH v3] ether: use a default for max Rx frame size in configure()
Date: Fri, 21 Apr 2017 00:25:17 +0200	[thread overview]
Message-ID: <2079307.yoZvx5qzNF@xps> (raw)
In-Reply-To: <40c13c68-aadf-1665-a301-7d74be3017cd@caviumnetworks.com>

07/04/2017 17:27, Andriy Berestovskyy:
> Hey Thomas,
> 
> On 07.04.2017 16:47, Thomas Monjalon wrote:
> >> What if we add to the max_rx_pkt_len description: "the effective maximum
> >> RX frame size depends on PMD, please refer the PMD guide for the
> >> details"?
> > 
> > I think the problem is not in the documentation but in the implementations
> > which should be more consistent.
> 
> The hardware is different, there is not much we can do about it.

We can return an error if the max_rx_pkt_len cannot be set in the NIC.

> Nevertheless, we can fix the false comment and have a default for the
> jumbos, which is beneficial for the apps/examples.

The examples are using a hardcoded value, so they need to be fixed anyway.

> > If I understand well, the inconsistency between drivers was already an
> > issue before your patch.
> > Your patch fixes an inconsistency in ethdev without fixing the drivers.
> > We need to know if it is a good first step and if the drivers can be
> > fixed later.
> 
> Thomas, some of the examples use a hard-coded jumbo frame size, which is
> too big for the underlaying PMDs, so those examples fail. The plan was
> to fix them all with this commit in ethdev but I am not sure now you are
> to accept the change.

This ethdev patch is about a behaviour change of the API.
It is about considering 0 as a request for default value
and return an error if a value cannot be set.
It will require more agreements and changes in the drivers
for returning an error where appropriate.

> It is important for us to have those examples working in the upcoming
> release, do you think it is better to send fixes for those examples
> instead of this commit then?

The examples can be improved independently of this patch.

  reply	other threads:[~2017-04-20 22:25 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-23 17:06 [PATCH] ether: fix configure() to use a default for max_rx_pkt_len Andriy Berestovskyy
2017-03-24 11:52 ` [PATCH v2] ether: use a default for max Rx frame size in configure() Andriy Berestovskyy
2017-03-27  6:15   ` Yang, Qiming
2017-03-27  8:38     ` Andriy Berestovskyy
2017-04-07  8:24       ` Bruce Richardson
2017-04-06 20:48   ` Thomas Monjalon
2017-04-07  8:09     ` Andriy Berestovskyy
2017-04-07  8:34       ` Thomas Monjalon
2017-04-07  8:55         ` Andriy Berestovskyy
2017-04-07 11:02 ` [PATCH v3] " Andriy Berestovskyy
2017-04-07 12:15   ` Thomas Monjalon
2017-04-07 12:29     ` Bruce Richardson
2017-04-07 14:18       ` Andriy Berestovskyy
2017-04-07 14:47         ` Thomas Monjalon
2017-04-07 15:27           ` Andriy Berestovskyy
2017-04-20 22:25             ` Thomas Monjalon [this message]
2017-04-24 14:50               ` Andriy Berestovskyy
2017-07-31 22:33                 ` Thomas Monjalon
2018-05-22 22:30                   ` Thomas Monjalon
2018-05-23  5:21                     ` Shahaf Shuler
2018-05-23  5:23                       ` Jerin Jacob
2018-05-24  9:20                       ` Andriy Berestovskyy
2019-01-23 18:36                         ` Ferruh Yigit
2019-01-25 21:15                           ` Andriy Berestovskyy
2017-04-10 14:30 ` [PATCH 1/3] examples/ip_fragmentation: limit max frame size Andriy Berestovskyy
2017-04-10 14:30   ` [PATCH 2/3] examples/ip_reassembly: " Andriy Berestovskyy
2017-04-10 14:30   ` [PATCH 3/3] examples/ipv4_multicast: " Andriy Berestovskyy
2017-04-21  0:21   ` [PATCH 1/3] examples/ip_fragmentation: " Thomas Monjalon
2023-06-08 16:51 ` [PATCH v3] ether: use a default for max Rx frame size in configure() Stephen Hemminger

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=2079307.yoZvx5qzNF@xps \
    --to=thomas@monjalon.net \
    --cc=Andriy.Berestovskyy@caviumnetworks.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    /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.