DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: Dumitru Ceara <dceara@redhat.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] net/ring: advertise multi segment support.
Date: Mon, 28 Sep 2020 12:01:45 +0100	[thread overview]
Message-ID: <20200928110145.GB951@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <5df07200-8a27-98a9-4121-76c44dd652fd@intel.com>

On Mon, Sep 28, 2020 at 11:25:34AM +0100, Ferruh Yigit wrote:
> On 9/28/2020 8:31 AM, Dumitru Ceara wrote:
> > On 9/22/20 4:21 PM, Ferruh Yigit wrote:
> > > On 9/18/2020 11:36 AM, Dumitru Ceara wrote:
> > > > Even though ring interfaces don't support any other TX/RX offloads they
> > > > do support sending multi segment packets and this should be advertised
> > > > in order to not break applications that use ring interfaces.
> > > > 
> > > 
> > > Does ring PMD support sending multi segmented packets?
> > > 
> > 
> > Yes, sending multi segmented packets works fine with ring PMD.
> > 
> 
> Define "works fine" :)
> 
> All PMDs can put the first mbuf of the chained mbuf to the ring, in that
> case what is the difference between the ones supports
> 'DEV_TX_OFFLOAD_MULTI_SEGS' and the ones doesn't support?
> 
> If the traffic is only from ring PMD to ring PMD, you won't recognize the
> difference between segmented or not-segmented mbufs, and it will look like
> segmented packets works fine.
> But if there is other PMDs involved in the forwarding, or if need to process
> the packets, will it still work fine?
> 

What other PMDs do or don't do should be irrelevant here, I think. The fact
that multi-segment PMDs make it though the ring PMD in valid form should be
sufficient to mark it as supported.

> > > As far as I can see ring PMD doesn't know about the mbuf segments.
> > > 
> > 
> > Right, the PMD doesn't care about the mbuf segments but it implicitly
> > supports sending multi segmented packets. From what I see it's actually
> > the case for most of the PMDs, in the sense that most don't even check
> > the DEV_TX_OFFLOAD_MULTI_SEGS flag and if the application sends multi
> > segment packets they are just accepted.
> >
> 
> As far as I can see, if the segmented packets sent, the ring PMD will put
> the first mbuf into the ring without doing anything specific to the next
> segments.
> 
> If the 'DEV_TX_OFFLOAD_MULTI_SEGS' is supported I expect it should detect
> the segmented packets and put each chained mbuf into the separate field in
> the ring.
> 

Why, what would be the advantage of that? Right now if you send in a valid
packet chain to the Ring PMD, you get a valid packet chain out again the
other side, so I don't see what needs to change about that behaviour.

> > 
> > However, the fact that the ring PMD doesn't advertise this implicit
> > support forces applications that use ring PMD to have a special case for
> > handling ring interfaces. If the ring PMD would advertise
> > DEV_TX_OFFLOAD_MULTI_SEGS this would allow upper layers to be oblivious
> > to the type of underlying interface.
> > 
> 
> This is not handling the special case for the ring PMD, this is why he have
> the offload capability flag. Application should behave according capability
> flags, not per specific PMD.
> 
> Is there any specific usecase you are trying to cover?

  parent reply	other threads:[~2020-09-28 11:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-18 10:36 Dumitru Ceara
2020-09-22 14:21 ` Ferruh Yigit
2020-09-28  7:31   ` Dumitru Ceara
2020-09-28 10:25     ` Ferruh Yigit
2020-09-28 11:00       ` Ananyev, Konstantin
2020-09-28 12:42         ` Ferruh Yigit
2020-09-28 13:10           ` Ananyev, Konstantin
2020-09-28 13:26             ` Ferruh Yigit
2020-09-28 13:58               ` Dumitru Ceara
2020-09-28 15:02                 ` Ferruh Yigit
2020-09-28 11:01       ` Bruce Richardson [this message]
2020-09-28 12:45         ` Ferruh Yigit
2020-09-28 18:47 ` [dpdk-dev] [PATCH v2] net/ring: advertise multi segment TX and scatter RX Dumitru Ceara
2020-09-29  8:37   ` Bruce Richardson
2020-09-30 17:04     ` Ferruh Yigit

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=20200928110145.GB951@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dceara@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).