| Message ID | 20220428030534.3220410-1-aahringo@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | net: 6lowpan: simplify lookup by nhc id | expand |
Hello. On 28.04.22 05:05, Alexander Aring wrote: > Hi, > > this patch series removes the rb data structure for looking up a nhc by > nhc id. Instead we using the existing nexthdr lookup array by iterating > over it and find the right nhc by nhc id. It's simply not worth it to > use such complex handling for such small amount of nhc. As we only > support nhc ids which fits into 1 byte and there are not two byte nhc > ids values specified yet, we let the nhc layer only handle 1 byte values. > If there is the need for 2 byte nhc values we can add support for it. > > - Alex > > Alexander Aring (3): > net: 6lowpan: remove const from scalars > net: 6lowpan: use array for find nhc id > net: 6lowpan: constify lowpan_nhc structures Marcel, Luiz, are you still picking up generic 6lowpan patches or only the ones for bluetooth? These three have been around for over a month and acked by me and Jukka, but I can't find them anywhere in bluetooth-next or Linus tree. If 6lowpan is of less concern for you I can route them through my ieee80254 tree as well. regards Stefan Schmidt
Hi Stefan, On Wed, Jun 1, 2022 at 2:37 PM Stefan Schmidt <stefan@datenfreihafen.org> wrote: > > Hello. > > On 28.04.22 05:05, Alexander Aring wrote: > > Hi, > > > > this patch series removes the rb data structure for looking up a nhc by > > nhc id. Instead we using the existing nexthdr lookup array by iterating > > over it and find the right nhc by nhc id. It's simply not worth it to > > use such complex handling for such small amount of nhc. As we only > > support nhc ids which fits into 1 byte and there are not two byte nhc > > ids values specified yet, we let the nhc layer only handle 1 byte values. > > If there is the need for 2 byte nhc values we can add support for it. > > > > - Alex > > > > Alexander Aring (3): > > net: 6lowpan: remove const from scalars > > net: 6lowpan: use array for find nhc id > > net: 6lowpan: constify lowpan_nhc structures > > Marcel, Luiz, are you still picking up generic 6lowpan patches or only > the ones for bluetooth? > > These three have been around for over a month and acked by me and Jukka, > but I can't find them anywhere in bluetooth-next or Linus tree. > > If 6lowpan is of less concern for you I can route them through my > ieee80254 tree as well. Up to you, I was not aware they normally were merged thru bluetooth-next but I would be fine merging those as well.
Hello Luiz. On 01.06.22 23:48, Luiz Augusto von Dentz wrote: > Hi Stefan, > > On Wed, Jun 1, 2022 at 2:37 PM Stefan Schmidt <stefan@datenfreihafen.org> wrote: >> >> Hello. >> >> On 28.04.22 05:05, Alexander Aring wrote: >>> Hi, >>> >>> this patch series removes the rb data structure for looking up a nhc by >>> nhc id. Instead we using the existing nexthdr lookup array by iterating >>> over it and find the right nhc by nhc id. It's simply not worth it to >>> use such complex handling for such small amount of nhc. As we only >>> support nhc ids which fits into 1 byte and there are not two byte nhc >>> ids values specified yet, we let the nhc layer only handle 1 byte values. >>> If there is the need for 2 byte nhc values we can add support for it. >>> >>> - Alex >>> >>> Alexander Aring (3): >>> net: 6lowpan: remove const from scalars >>> net: 6lowpan: use array for find nhc id >>> net: 6lowpan: constify lowpan_nhc structures >> >> Marcel, Luiz, are you still picking up generic 6lowpan patches or only >> the ones for bluetooth? >> >> These three have been around for over a month and acked by me and Jukka, >> but I can't find them anywhere in bluetooth-next or Linus tree. >> >> If 6lowpan is of less concern for you I can route them through my >> ieee80254 tree as well. > > Up to you, I was not aware they normally were merged thru > bluetooth-next but I would be fine merging those as well. If you and Marcel don't mind I would like to switch this over to being merged through ieee802154. Mostly because 6lowpan is vital for the 15.4 work we have. With Jukka stepping down from co-maintaining this part (thanks a lot for your work!) this will most likely be reviewed by Alex and me anyway. We still need to ensure that patches are hitting wpan as well as bluetooth mailing list, but the MAINTAINERS file handles this already. Let me know if you are unhappy with the switch. If not I will start with merging these three as well as the MAINTAINERS update from Jukka. regards Stefan Schmidt
Hi Stefan, On Wed, Jun 1, 2022 at 2:56 PM Stefan Schmidt <stefan@datenfreihafen.org> wrote: > > Hello Luiz. > > On 01.06.22 23:48, Luiz Augusto von Dentz wrote: > > Hi Stefan, > > > > On Wed, Jun 1, 2022 at 2:37 PM Stefan Schmidt <stefan@datenfreihafen.org> wrote: > >> > >> Hello. > >> > >> On 28.04.22 05:05, Alexander Aring wrote: > >>> Hi, > >>> > >>> this patch series removes the rb data structure for looking up a nhc by > >>> nhc id. Instead we using the existing nexthdr lookup array by iterating > >>> over it and find the right nhc by nhc id. It's simply not worth it to > >>> use such complex handling for such small amount of nhc. As we only > >>> support nhc ids which fits into 1 byte and there are not two byte nhc > >>> ids values specified yet, we let the nhc layer only handle 1 byte values. > >>> If there is the need for 2 byte nhc values we can add support for it. > >>> > >>> - Alex > >>> > >>> Alexander Aring (3): > >>> net: 6lowpan: remove const from scalars > >>> net: 6lowpan: use array for find nhc id > >>> net: 6lowpan: constify lowpan_nhc structures > >> > >> Marcel, Luiz, are you still picking up generic 6lowpan patches or only > >> the ones for bluetooth? > >> > >> These three have been around for over a month and acked by me and Jukka, > >> but I can't find them anywhere in bluetooth-next or Linus tree. > >> > >> If 6lowpan is of less concern for you I can route them through my > >> ieee80254 tree as well. > > > > Up to you, I was not aware they normally were merged thru > > bluetooth-next but I would be fine merging those as well. > > If you and Marcel don't mind I would like to switch this over to being > merged through ieee802154. Mostly because 6lowpan is vital for the 15.4 > work we have. > > With Jukka stepping down from co-maintaining this part (thanks a lot for > your work!) this will most likely be reviewed by Alex and me anyway. > > We still need to ensure that patches are hitting wpan as well as > bluetooth mailing list, but the MAINTAINERS file handles this already. > > Let me know if you are unhappy with the switch. If not I will start with > merging these three as well as the MAINTAINERS update from Jukka. I have no problem with that.
Hi Stefan, >>>>> this patch series removes the rb data structure for looking up a nhc by >>>>> nhc id. Instead we using the existing nexthdr lookup array by iterating >>>>> over it and find the right nhc by nhc id. It's simply not worth it to >>>>> use such complex handling for such small amount of nhc. As we only >>>>> support nhc ids which fits into 1 byte and there are not two byte nhc >>>>> ids values specified yet, we let the nhc layer only handle 1 byte values. >>>>> If there is the need for 2 byte nhc values we can add support for it. >>>>> >>>>> - Alex >>>>> >>>>> Alexander Aring (3): >>>>> net: 6lowpan: remove const from scalars >>>>> net: 6lowpan: use array for find nhc id >>>>> net: 6lowpan: constify lowpan_nhc structures >>>> >>>> Marcel, Luiz, are you still picking up generic 6lowpan patches or only >>>> the ones for bluetooth? >>>> >>>> These three have been around for over a month and acked by me and Jukka, >>>> but I can't find them anywhere in bluetooth-next or Linus tree. >>>> >>>> If 6lowpan is of less concern for you I can route them through my >>>> ieee80254 tree as well. >>> >>> Up to you, I was not aware they normally were merged thru >>> bluetooth-next but I would be fine merging those as well. >> >> If you and Marcel don't mind I would like to switch this over to being >> merged through ieee802154. Mostly because 6lowpan is vital for the 15.4 >> work we have. >> >> With Jukka stepping down from co-maintaining this part (thanks a lot for >> your work!) this will most likely be reviewed by Alex and me anyway. >> >> We still need to ensure that patches are hitting wpan as well as >> bluetooth mailing list, but the MAINTAINERS file handles this already. >> >> Let me know if you are unhappy with the switch. If not I will start with >> merging these three as well as the MAINTAINERS update from Jukka. > > I have no problem with that. go for it. Lets just keep the mailing list in MAINTAINERS file so we are aware of patches in this area. Regards Marcel
Hello Marcel On 02.06.22 17:27, Marcel Holtmann wrote: > Hi Stefan, > >>>>>> this patch series removes the rb data structure for looking up a nhc by >>>>>> nhc id. Instead we using the existing nexthdr lookup array by iterating >>>>>> over it and find the right nhc by nhc id. It's simply not worth it to >>>>>> use such complex handling for such small amount of nhc. As we only >>>>>> support nhc ids which fits into 1 byte and there are not two byte nhc >>>>>> ids values specified yet, we let the nhc layer only handle 1 byte values. >>>>>> If there is the need for 2 byte nhc values we can add support for it. >>>>>> >>>>>> - Alex >>>>>> >>>>>> Alexander Aring (3): >>>>>> net: 6lowpan: remove const from scalars >>>>>> net: 6lowpan: use array for find nhc id >>>>>> net: 6lowpan: constify lowpan_nhc structures >>>>> >>>>> Marcel, Luiz, are you still picking up generic 6lowpan patches or only >>>>> the ones for bluetooth? >>>>> >>>>> These three have been around for over a month and acked by me and Jukka, >>>>> but I can't find them anywhere in bluetooth-next or Linus tree. >>>>> >>>>> If 6lowpan is of less concern for you I can route them through my >>>>> ieee80254 tree as well. >>>> >>>> Up to you, I was not aware they normally were merged thru >>>> bluetooth-next but I would be fine merging those as well. >>> >>> If you and Marcel don't mind I would like to switch this over to being >>> merged through ieee802154. Mostly because 6lowpan is vital for the 15.4 >>> work we have. >>> >>> With Jukka stepping down from co-maintaining this part (thanks a lot for >>> your work!) this will most likely be reviewed by Alex and me anyway. >>> >>> We still need to ensure that patches are hitting wpan as well as >>> bluetooth mailing list, but the MAINTAINERS file handles this already. >>> >>> Let me know if you are unhappy with the switch. If not I will start with >>> merging these three as well as the MAINTAINERS update from Jukka. >> >> I have no problem with that. > > go for it. Lets just keep the mailing list in MAINTAINERS file so we are aware of patches in this area. Yup, that's the plan. Taking the pending patch in now. regards Stefan Schmidt
Hello. On 28.04.22 05:05, Alexander Aring wrote: > Hi, > > this patch series removes the rb data structure for looking up a nhc by > nhc id. Instead we using the existing nexthdr lookup array by iterating > over it and find the right nhc by nhc id. It's simply not worth it to > use such complex handling for such small amount of nhc. As we only > support nhc ids which fits into 1 byte and there are not two byte nhc > ids values specified yet, we let the nhc layer only handle 1 byte values. > If there is the need for 2 byte nhc values we can add support for it. > > - Alex > > Alexander Aring (3): > net: 6lowpan: remove const from scalars > net: 6lowpan: use array for find nhc id > net: 6lowpan: constify lowpan_nhc structures These patches have been applied to the wpan-next tree and will be part of the next pull request to net-next. Thanks! regards Stefan Schmidt