On Wed, Apr 26, 2017 at 9:46 AM, Jarod Wilson <ja...@redhat.com> wrote: > On 2017-04-26 12:11 PM, Cong Wang wrote: >> >> On Wed, Apr 26, 2017 at 8:55 AM, Jarod Wilson <ja...@redhat.com> wrote: >>> >>> >>> We already have struct sockaddr_storage that could be used throughout >>> this >>> set as well. We just converted a few pieces of the bonding driver over to >>> using it for better support of ipoib bonds, via commit >>> faeeb317a5615076dff1ff44b51e862e6064dbd0. Might be better to just use >>> that >>> in both bonding and team, rather than having different per-driver >>> structs, >>> or Yet Another Address Storage implementation. >> >> >> Technically, struct sockaddr_storage is not enough either, given the >> max is MAX_ADDR_LEN. This is why I gave up on sockaddr_storage. > > > Wait, what? Am I missing something? MAX_ADDR_LEN is 32, and sockaddr_storage > is a #define for __kernel_sockaddr_storage, which has it's __data member > defined as being of size 128 - sizeof(unsigned short).
My bad, I thought it is same with sizeof(in6addr) without looking into it. The question is, why do we waste 126 - 32 = 94 bytes on stack to just use struct sockaddr_storage? I totally understand we want a unified struct, but we already redefine it in multiple places in tree...
