Fair enough... I think that is just something we're going to have to live with.
The other solutions are either much more painful, or much more work.
If we can use header/buffer splitting that would be superior. Right now we
can't use that everywhere because it isn't available everywhere.
On Mar
On Tue, 26 Mar 2024 10:43:30 -0700
Garrett D'Amore wrote:
> This had occurred to me as well. I think most hardware DMA engines can align
> on 32-bit boundaries. I've yet to see a device that actually requires 64-bit
> DMA alignment. (But I have only looked at a subset of devices, and most o
tephen Hemminger
> ; Morten Brørup
> Cc: dev@dpdk.org; Parthakumar Roy
> Subject: RE: meson option to customize RTE_PKTMBUF_HEADROOM patch
>
> This could work. Not that we would like to have the exceptional case of IPv6
> use less headroom. So we would say 40 is our compiled in
This had occurred to me as well. I think most hardware DMA engines can align
on 32-bit boundaries. I've yet to see a device that actually requires 64-bit
DMA alignment. (But I have only looked at a subset of devices, and most of
the ones I have looked at are not ones that would be considere
now it is supported
by mlx5 PMD only.
From: Garrett D'Amore
Sent: Tuesday, March 26, 2024 2:19 PM
To: Bruce Richardson ; Stephen Hemminger
; Morten Brørup
Cc: dev@dpdk.org; Parthakumar Roy
Subject: RE: meson option to customize RTE_PKTMBUF_HEADROOM patch
This could work. Not that we would
Something just struck me…
The buffer address field in the RX descriptor of some NICs may have alignment
requirements, i.e. the lowest bits in the buffer address field of the NIC’s RX
descriptor may be used for other purposes (and assumed zero for buffer address
purposes). 40 is divisible by 8,
This could work. Not that we would like to have the exceptional case of IPv6
use less headroom. So we would say 40 is our compiled in default and then we
reduce it by 20 on IPv6 which doesn’t have to support all the same devices that
IPv4 does. This would give the lowest disruption to the exis
Interesting requirement. I can easily imagine how a (non-forwarding, i.e.
traffic terminating) application, which doesn’t really care about the preceding
headers, can benefit from having its actual data at a specific offset for
alignment purposes. I don’t consider this very exotic. (Even the Lin
So we need (for reasons that I don't want to get to into in too much detail)
that our UDP payload headers are at a specific offset in the packet.
This was not a problem as long as we only used IPv4. (We have configured 40
bytes of headroom, which is more than any of our PMDs need by a hefty mar
On Mon, 25 Mar 2024 10:01:52 +
Bruce Richardson wrote:
> On Sat, Mar 23, 2024 at 01:51:25PM -0700, Garrett D'Amore wrote:
> >So we right now (at WEKA) have a somewhat older version of DPDK that we
> >have customized heavily, and I am going to to need to to make the
> >headroom *dy
On Sat, Mar 23, 2024 at 01:51:25PM -0700, Garrett D'Amore wrote:
>So we right now (at WEKA) have a somewhat older version of DPDK that we
>have customized heavily, and I am going to to need to to make the
>headroom *dynamic* (passed in at run time, and per port.)
>We have this requi
So we right now (at WEKA) have a somewhat older version of DPDK that we have
customized heavily, and I am going to to need to to make the headroom *dynamic*
(passed in at run time, and per port.)
We have this requirement because we need payload to be at a specific offset,
but have to deal with
Hello,
On Thu, Feb 15, 2024 at 8:02 PM Parthakumar Roy wrote:
>
> Hello,
> Bruce Richardson suggested that I submit this patch - at IBM we needed to
> adjust the pkt_mbuf_headroom for our application to work. This is my first
> ever patch through a mailing list, I have only done it through Pull
13 matches
Mail list logo
