[dpdk-dev,1/1] arm: set CONFIG_RTE_ARCH_STRICT_ALIGN=y for armv7 target

  This patch reduces number of warnings from 53 to 40. It removes the usual false
positives utilizing unaligned_uint*_t data types.

Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
---
As far as I know, only a 64-bit unaligned access can be a problem for ARMv7.
I found only one such occurence:

118 struct rte_mbuf *                                                               
119 rte_ipv4_frag_reassemble_packet(struct rte_ip_frag_tbl *tbl,                    
120                 struct rte_ip_frag_death_row *dr, struct rte_mbuf *mb, uint64_t tms,
121                 struct ipv4_hdr *ip_hdr)
...
133         psd = (unaligned_uint64_t *)&ip_hdr->src_addr;                          
134         /* use first 8 bytes only */                                            
135         key.src_dst[0] = psd[0];                                                
136         key.id = ip_hdr->packet_id;                                             
137         key.key_len = IPV4_KEYLEN

Is this a real issue?
---
 config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
 1 file changed, 1 insertion(+)
  

2015-12-09 16:16, Jan Viktorin:
> This patch reduces number of warnings from 53 to 40. It removes the usual false
> positives utilizing unaligned_uint*_t data types.
> 
> Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>

Applied, thanks

Jan, what is the problem with the other ARM alignment warnings?
Can they be fixed?
  

On Mon, 29 Feb 2016 16:14:58 +0100
Thomas Monjalon <thomas.monjalon@6wind.com> wrote:

> 2015-12-09 16:16, Jan Viktorin:
> > This patch reduces number of warnings from 53 to 40. It removes the usual false
> > positives utilizing unaligned_uint*_t data types.
> > 
> > Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>  
> 
> Applied, thanks
> 
> Jan, what is the problem with the other ARM alignment warnings?
> Can they be fixed?

This is the full list of warnings I can see on the current origin/master
for ARMv7 (42 occurences) including examples (+10 more). The origin of
all of them is:

  cast increases required alignment of target type [-Wcast-align]

After skimming through the list, you can see that they are mostly casts
to uint32_t * or something similar. I believe that all of them are OK.
However, I don't know how to persuade GCC to not be angry...

Probably, we can add some explicit alignment of certain structures.

app/test/test_thash.c
116   rte_convert_rss_key((uint32_t *)&default_rss_key,
117     (uint32_t *)rss_key_be, RTE_DIM(default_rss_key));

build/include/test_thash.h
179     *((uint32_t *)targ->v6.src_addr + i) =
180       rte_be_to_cpu_32(*((const uint32_t *)orig->src_addr + i));
181     *((uint32_t *)targ->v6.dst_addr + i) =
182       rte_be_to_cpu_32(*((const uint32_t *)orig->dst_addr + i));
207         ret ^= rte_cpu_to_be_32(((const uint32_t *)rss_key)[j]) << i |
208           (uint32_t)((uint64_t)(rte_cpu_to_be_32(((const uint32_t *)rss_key)[j + 1])) >>
238         ret ^= ((const uint32_t *)rss_key)[j] << i |
239           (uint32_t)((uint64_t)(((const uint32_t *)rss_key)[j + 1]) >> (32 - i));

examples-sdk/usr/local/share/dpdk/arm-armv7a-linuxapp-gcc/include/rte_mbuf.h
1617   ((t)((char *)(m)->buf_addr + (m)->data_off + (o)))

examples/l3fwd-acl/main.c
1074       next = (struct rte_acl_rule *)(route_rules +
1079       next = (struct rte_acl_rule *)(acl_rules +
1115   *pacl_base = (struct rte_acl_rule *)acl_rules;
1117   *proute_base = (struct rte_acl_rule *)route_rules;

netmap_user.h
65 #define NETMAP_IF(b, o)  (struct netmap_if *)((char *)(b) + (o))
68   ((struct netmap_ring *)((char *)(nifp) +  \
72   ((struct netmap_ring *)((char *)(nifp) +  \

examples/vhost/main.c
121 #define MBUF_HEADROOM_UINT32(mbuf) (*(uint32_t *)((uint8_t *)(mbuf) \
945   return ((*(uint64_t *)ea ^ *(uint64_t *)eb) & MAC_ADDR_CMP) == 0;

lib/librte_acl/acl_gen.c
391     qtrp = (uint32_t *)node->transitions;

lib/librte_acl/acl_run.h
46   (*((const int32_t *)((prm)[(idx)].data + *(prm)[idx].data_index++)))

lib/librte_eal/linuxapp/eal/eal_interrupts.c
150   irq_set = (struct vfio_irq_set *) irq_set_buf;
156   fd_ptr = (int *) &irq_set->data;
196   irq_set = (struct vfio_irq_set *) irq_set_buf;
239   irq_set = (struct vfio_irq_set *) irq_set_buf;
245   fd_ptr = (int *) &irq_set->data;
267   irq_set = (struct vfio_irq_set *) irq_set_buf;
293   irq_set = (struct vfio_irq_set *) irq_set_buf;
304   fd_ptr = (int *) &irq_set->data;
330   irq_set = (struct vfio_irq_set *) irq_set_buf;

lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c
176   chdr = (struct cmsghdr *) chdr_buf;
209   chdr = (struct cmsghdr *) chdr_buf;

595       k = (struct rte_hash_key *) ((char *)keys +
615       k = (struct rte_hash_key *) ((char *)keys +
726       k = (struct rte_hash_key *) ((char *)keys +
749       k = (struct rte_hash_key *) ((char *)keys +
841       k = (struct rte_hash_key *) ((char *)keys +
864       k = (struct rte_hash_key *) ((char *)keys +
959   *key_slot = (const struct rte_hash_key *) ((const char *)keys +
1233   next_key = (struct rte_hash_key *) ((char *)h->key_store +

lib/librte_sched/rte_bitmap.h
262   bmp = (struct rte_bitmap *) mem;
264   bmp->array1 = (uint64_t *) &mem[array1_byte_offset];
266   bmp->array2 = (uint64_t *) &mem[array2_byte_offset];

lib/librte_sched/rte_sched.c
684   port->subport = (struct rte_sched_subport *)
687   port->pipe = (struct rte_sched_pipe *)
690   port->queue = (struct rte_sched_queue *)
693   port->queue_extra = (struct rte_sched_queue_extra *)
696   port->pipe_profiles = (struct rte_sched_pipe_profile *)
701   port->queue_array = (struct rte_mbuf **)

lib/librte_vhost/vhost_user/virtio-net-user.c
433   rarp = (struct ether_arp *)(eth_hdr + 1);
527   ifr = (struct ifreq *)ifc.ifc_buf;

Regards
Jan
  

On Mon, 29 Feb 2016 16:55:38 +0100
Jan Viktorin <viktorin@rehivetech.com> wrote:

> On Mon, 29 Feb 2016 16:14:58 +0100
> Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> 
> > 2015-12-09 16:16, Jan Viktorin:  
> > > This patch reduces number of warnings from 53 to 40. It removes the usual false
> > > positives utilizing unaligned_uint*_t data types.
> > > 
> > > Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>    
> > 
> > Applied, thanks
> > 
> > Jan, what is the problem with the other ARM alignment warnings?
> > Can they be fixed?  
> 
> This is the full list of warnings I can see on the current origin/master
> for ARMv7 (42 occurences) including examples (+10 more). The origin of
> all of them is:
> 
>   cast increases required alignment of target type [-Wcast-align]
> 
> After skimming through the list, you can see that they are mostly casts
> to uint32_t * or something similar. I believe that all of them are OK.
> However, I don't know how to persuade GCC to not be angry...
> 
> Probably, we can add some explicit alignment of certain structures.
> 
[snip]
> 
> lib/librte_vhost/vhost_user/virtio-net-user.c
> 433   rarp = (struct ether_arp *)(eth_hdr + 1);
> 527   ifr = (struct ifreq *)ifc.ifc_buf;

Fixed recently in
http://dpdk.org/browse/dpdk/commit/?id=bb66588304632a7e4a043d2921d06709d40f9ed4

> 
> Regards
> Jan