> From: Robin Jarry [mailto:rja...@redhat.com]
> Sent: Sunday, 21 July 2024 23.51
>
> Hi Morten, Stephen,
>
> Morten Brørup, Jul 21, 2024 at 18:12:
> > If the IPv6 address type you tested with was a struct containing
> > a union of different types (other than an array of 16 bytes), then
> > those
> Vladimir Medvedkin, Jul 18, 2024 at 23:25:
> > I think alignment should be 1 since in FIB6 users usually don't copy IPv6
> > address and just provide a pointer to the memory inside the packet. Current
> > vector implementation loads IPv6 addresses using unaligned access (
> > _mm512_loadu_si512
Hi Morten, Stephen,
Morten Brørup, Jul 21, 2024 at 18:12:
If the IPv6 address type you tested with was a struct containing
a union of different types (other than an array of 16 bytes), then
those sub-types made your IPv6 address type non-byte aligned, and
caused padding when used in other stru
> From: Robin Jarry [mailto:rja...@redhat.com]
> Sent: Saturday, 20 July 2024 22.33
>
> Stephen Hemminger, Jul 20, 2024 at 22:26:
> > There is no need for packing or alignment in in6_addr or current DPDK,
> > what would be the benefit? Compilers generate worse code if
> > a structure is marked pa
Stephen Hemminger, Jul 20, 2024 at 22:26:
There is no need for packing or alignment in in6_addr or current DPDK,
what would be the benefit? Compilers generate worse code if
a structure is marked packed.
The only benefit is to maintain current behaviour.
At first, I had not packed nor aligned
Cutting down the quoting a bit.
I understand the arguments against having an unaligned packed struct.
But it is precisely what we have in the current code base. All IPv6
addresses are uint8_t[16] arrays. And nobody ever complained about it.
Since this rework is already massive, could we proce
On Fri, 19 Jul 2024 17:47:47 +0200
Morten Brørup wrote:
> > From: Robin Jarry [mailto:rja...@redhat.com]
> >
> > Morten Brørup, Jul 19, 2024 at 12:46:
> > > When passing an IPv4 address as a value, alignment does matter; it
> > > must be 4 byte aligned.
> >
> > I was expecting the compiler
> From: Robin Jarry [mailto:rja...@redhat.com]
>
> Morten Brørup, Jul 19, 2024 at 12:46:
> > When passing an IPv4 address as a value, alignment does matter; it
> > must be 4 byte aligned.
>
> I was expecting the compiler to do what is necessary to copy the data to
> an aligned register before jum
Morten Brørup, Jul 19, 2024 at 12:46:
When passing an IPv4 address as a value, alignment does matter; it
must be 4 byte aligned.
I was expecting the compiler to do what is necessary to copy the data to
an aligned register before jumping to the function.
On a CPU with 128 bit registers, I wou
> From: Robin Jarry [mailto:rja...@redhat.com]
>
> Morten Brørup, Jul 19, 2024 at 11:12:
> > > Vladimir Medvedkin, Jul 18, 2024 at 23:25:
> > > > I think alignment should be 1 since in FIB6 users usually don't
> > > > copy IPv6 address and just provide a pointer to the memory inside
> > > > the pa
Hi Morten,
On 19/07/2024 10:12, Morten Brørup wrote:
From: Robin Jarry [mailto:rja...@redhat.com]
Vladimir Medvedkin, Jul 18, 2024 at 23:25:
I think alignment should be 1 since in FIB6 users usually don't copy
IPv6
address and just provide a pointer to the memory inside the packet.
How can
On Fri, Jul 19, 2024 at 12:02:38PM +0200, Robin Jarry wrote:
> Morten Brørup, Jul 19, 2024 at 11:12:
> > > Vladimir Medvedkin, Jul 18, 2024 at 23:25:
> > > > I think alignment should be 1 since in FIB6 users usually don't > >
> > copy IPv6 address and just provide a pointer to the memory inside > >
Morten Brørup, Jul 19, 2024 at 11:12:
> Vladimir Medvedkin, Jul 18, 2024 at 23:25:
> > I think alignment should be 1 since in FIB6 users usually don't
> > copy IPv6 address and just provide a pointer to the memory inside
> > the packet.
How can they do that? The bulk lookup function takes an
> From: Robin Jarry [mailto:rja...@redhat.com]
>
> Vladimir Medvedkin, Jul 18, 2024 at 23:25:
> > I think alignment should be 1 since in FIB6 users usually don't copy
> IPv6
> > address and just provide a pointer to the memory inside the packet.
How can they do that? The bulk lookup function take
Stephen Hemminger, Jul 18, 2024 at 23:15:
If you look at the standard netinet/in.h the storage of IPv6 addresses
is in in6_addr. DPDK has always wanted to do its own thing...
The in6_addr is a union with no explicit alignment.
struct in6_addr
{
union
{
uint8_t __u6_addr8[16]
Vladimir Medvedkin, Jul 18, 2024 at 23:25:
I think alignment should be 1 since in FIB6 users usually don't copy IPv6
address and just provide a pointer to the memory inside the packet. Current
vector implementation loads IPv6 addresses using unaligned access (
_mm512_loadu_si512) so it doesn't re
Hi Robin,
Thanks, that is a good idea.
чт, 18 июл. 2024 г. в 21:27, Morten Brørup :
> > From: Robin Jarry [mailto:rja...@redhat.com]
> >
> > Hi folks,
> >
> > while working on IPv6 support for grout [1], I noticed that all DPDK
> > IPv6 APIs used fixed sized arrays in the route lookup functio
On Thu, 18 Jul 2024 22:27:03 +0200
Morten Brørup wrote:
> > From: Robin Jarry [mailto:rja...@redhat.com]
> >
> > Hi folks,
> >
> > while working on IPv6 support for grout [1], I noticed that all DPDK
> > IPv6 APIs used fixed sized arrays in the route lookup functions [2].
> >
> > int rte_fib6
> From: Robin Jarry [mailto:rja...@redhat.com]
>
> Hi folks,
>
> while working on IPv6 support for grout [1], I noticed that all DPDK
> IPv6 APIs used fixed sized arrays in the route lookup functions [2].
>
> int rte_fib6_lookup_bulk(struct rte_fib6 *fib,
> uint8_t ips
Hi folks,
while working on IPv6 support for grout [1], I noticed that all DPDK
IPv6 APIs used fixed sized arrays in the route lookup functions [2].
int rte_fib6_lookup_bulk(struct rte_fib6 *fib,
uint8_t ips[][RTE_FIB6_IPV6_ADDR_SIZE],
uint64_t
20 matches
Mail list logo
