On 11/27/2019 4:07 PM, Marcelo Ricardo Leitner wrote: > On Wed, Nov 27, 2019 at 02:55:09PM +0200, Roi Dayan wrote: >> From: Paul > Blakey <[email protected]><mailto:[email protected]> >> >> Move all that is > needed to identify a tc filter to a new structure, >> tc_id. This removes a > lot of duplication in accessing/creating tc >> filters. > > Ok, gotta say, > 'tc_id' is a bit confusing here. Every time I read > it, I try to find a > correlating id in the kernel land but it doesn't > exist, because 'tc' itself > refers to a much bigger thing and not > just filters. > > That said, I was > thinking, what about 'tcf_id', or even a longer > one, 'tc_filter_id'? But > before answering, please read below. :-) I don't mind either way, but from this I'd rater have the short one tcf_id.
> >> >> --- >> >> Changelog: V1->V2: In tc_del_matchall_policer - reverse xmas > >> >> param >> order Added and used helper is_tc_id_eq(id1, id2) in find_ufid > >> >> In >> netdev_tc_flow_dump_next - use make_tc_id() instead of manualy >> > >> >> filling id > ^^^^^^^^^^ > >> In netdev_tc_flow_put - use if > >> >> (get_ufid_tc_mapping(ufid, &id) == >> 0) to be mor explict we found the > >> >> mapping not failed to get In >> make_tc_id - fill id explictily and > >> >> removed memset. Moved >> tc_make_id to be static inline in tc.h > > >> >> ^^^^^^^^^^ > > The patch is currently using make_tc_id. I see other > >> >> functions > already using the latter one, tc_make_*, like > >> >> tc_make_handle and > tc_make_request. Though it also already has > >> >> make_tc_id_chain. Which > then, with this last one, it gets easier to > >> >> understand what a 'tc_id' > means. > > I don't have a strong opinion > >> >> here, so I'm just highlighting the > topic. Not sure what you meant here. Would you rather we have tc_make_tcf_id() and tc_make_tcf_id_chain() (in later patch) to be more consistent? _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
