Message ID | 1456917631-18447-1-git-send-email-phil@nwl.cc |
---|---|
State | Superseded, archived |
Delegated to: | stephen hemminger |
Headers | show |
On Wed, 2 Mar 2016 11:20:31 +0000 Phil Sutter <phil@nwl.cc> wrote: > + res = parse_cmd(&argc, &argv, 1, TU32,0x0f,sel,tkey); > goto done; Please add whitespace after ,
On 16-03-02 12:54 PM, Stephen Hemminger wrote: > On Wed, 2 Mar 2016 11:20:31 +0000 > Phil Sutter <phil@nwl.cc> wrote: > >> + res = parse_cmd(&argc, &argv, 1, TU32,0x0f,sel,tkey); >> goto done; > Please add whitespace after , > There are a few whitespace issues in that code that would be nice to fix given the cleanup opportunity. The patches look good to me. Phil, maybe get rid of that comment at the top which was worrying about endianness. I think you fixed it. Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Your tests in patch 0 are nice and could go in tests/ directory. I can send you some of the basic tests i run via the kernel; they look something of the form: # #RFC #dst MAC starts at -14 #src MAC at -8 #ethertype at -2 # # tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ match ip src 192.168.1.10/32 flowid 1:2 \ action pedit munge offset -14 u16 set 0x0000 \ munge offset -12 u32 set 0x00010100 \ munge offset -8 u32 set 0x0aaf0100 \ munge offset -4 u32 set 0x0008ec06 pipe \ action mirred egress redirect dev eth1 # # These would of course require more of a larger setup to vet and running tcpdump to check the correct bytes are being modified. cheers, jamal
Phil, there is one thing i noticed in your patch - dont think it is a big deal but you are doing htons on an int (instead of u16). cheers, jamal On 16-03-03 09:21 AM, Jamal Hadi Salim wrote: > On 16-03-02 12:54 PM, Stephen Hemminger wrote: >> On Wed, 2 Mar 2016 11:20:31 +0000 >> Phil Sutter <phil@nwl.cc> wrote: >> >>> + res = parse_cmd(&argc, &argv, 1, TU32,0x0f,sel,tkey); >>> goto done; >> Please add whitespace after , >> > > There are a few whitespace issues in that code that would be nice to fix > given the cleanup opportunity. > The patches look good to me. Phil, maybe get rid of that comment at the > top which was worrying about endianness. I think you fixed it. > > Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> > > Your tests in patch 0 are nice and could go in tests/ directory. > I can send you some of the basic tests i run via the kernel; they look > something of the form: > > # > #RFC > #dst MAC starts at -14 > #src MAC at -8 > #ethertype at -2 > # > # > tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ > match ip src 192.168.1.10/32 flowid 1:2 \ > action pedit munge offset -14 u16 set 0x0000 \ > munge offset -12 u32 set 0x00010100 \ > munge offset -8 u32 set 0x0aaf0100 \ > munge offset -4 u32 set 0x0008ec06 pipe \ > action mirred egress redirect dev eth1 > # > # > > These would of course require more of a larger setup to vet > and running tcpdump to check the correct bytes are being > modified. > > cheers, > jamal
Hi, On Thu, Mar 03, 2016 at 09:21:23AM -0500, Jamal Hadi Salim wrote: > On 16-03-02 12:54 PM, Stephen Hemminger wrote: > > On Wed, 2 Mar 2016 11:20:31 +0000 > > Phil Sutter <phil@nwl.cc> wrote: > > > >> + res = parse_cmd(&argc, &argv, 1, TU32,0x0f,sel,tkey); > >> goto done; > > Please add whitespace after , > > > > There are a few whitespace issues in that code that would be nice to fix > given the cleanup opportunity. In v2, I added a separate patch which makes that file conform to checkpatch.pl (used the --fix-inplace option and tweaked the output a bit). So that should be fine already. > The patches look good to me. Phil, maybe get rid of that comment at the > top which was worrying about endianness. I think you fixed it. I'm not so sure. The kernel explicitly takes care to get the bit ordering right: | struct iphdr | { | #if __BYTE_ORDER == __LITTLE_ENDIAN | unsigned int ihl:4; | unsigned int version:4; | #elif __BYTE_ORDER == __BIG_ENDIAN | unsigned int version:4; | unsigned int ihl:4; | #else | # error "Please fix <bits/endian.h>" | #endif act_pedit though just mangles the whole byte as-is, and if that was correct, we would not have to go that extra mile in struct iphdr, or do we? > Your tests in patch 0 are nice and could go in tests/ directory. > I can send you some of the basic tests i run via the kernel; they look > something of the form: > > # > #RFC > #dst MAC starts at -14 > #src MAC at -8 > #ethertype at -2 > # > # > tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ > match ip src 192.168.1.10/32 flowid 1:2 \ > action pedit munge offset -14 u16 set 0x0000 \ > munge offset -12 u32 set 0x00010100 \ > munge offset -8 u32 set 0x0aaf0100 \ > munge offset -4 u32 set 0x0008ec06 pipe \ > action mirred egress redirect dev eth1 > # > # > > These would of course require more of a larger setup to vet > and running tcpdump to check the correct bytes are being > modified. Since I am lazy, I wanted to have as much automation as possible while testing. Therefore I just assumed that act_pedit does the right thing all the time, and iproute just has to feed it correct values. Given the scope of this patch, this is also completely sufficient. Of course, the tests/ directory would benefit more from a full test. But since automation then becomes tricky, I'm not sure it makes much sense to deliberately write code for that. Thanks for the review, Phil
On Thu, Mar 03, 2016 at 09:28:27AM -0500, Jamal Hadi Salim wrote: > Phil, there is one thing i noticed in your patch - dont think > it is a big deal but you are doing htons on an int > (instead of u16). Indeed, I totally overlooked that. Does not look like there's an easy fix though, as all tc_pedit_key fields are u32. OTOH htons() will cast to u16 first, therefore cutting off any higher bits. Looks like the code does the right thing anyway, and the test results fortify that. Do you see a cleaner way to implement this? Otherwise I would vote for leaving it as a little surprise to future readers. ;) Cheers, Phil
On 16-03-03 09:32 AM, Phil Sutter wrote: > Hi, > > >> The patches look good to me. Phil, maybe get rid of that comment at the >> top which was worrying about endianness. I think you fixed it. > > I'm not so sure. The kernel explicitly takes care to get the bit > ordering right: > [..] > act_pedit though just mangles the whole byte as-is, and if that was > correct, we would not have to go that extra mile in struct iphdr, or do > we? > I meant in general - the note to say that there are endianes issues should go. >> These would of course require more of a larger setup to vet >> and running tcpdump to check the correct bytes are being >> modified. > Indeed - That is how i normally would test. It is more complex. Your scheme is good - but will not catch a kernel bug. > Since I am lazy, I wanted to have as much automation as possible while > testing. Therefore I just assumed that act_pedit does the right thing > all the time, famous last words ;-> > and iproute just has to feed it correct values. Given the > scope of this patch, this is also completely sufficient. Of course, the > tests/ directory would benefit more from a full test. But since > automation then becomes tricky, I'm not sure it makes much sense to > deliberately write code for that. > Your test is still useful and i think should go into the tests dir. cheers, jamal > Thanks for the review, > > Phil >
Hi, On Mon, Mar 07, 2016 at 06:21:17AM -0500, Jamal Hadi Salim wrote: > On 16-03-03 09:32 AM, Phil Sutter wrote: > >> The patches look good to me. Phil, maybe get rid of that comment at the > >> top which was worrying about endianness. I think you fixed it. > > > > I'm not so sure. The kernel explicitly takes care to get the bit > > ordering right: > > > [..] > > act_pedit though just mangles the whole byte as-is, and if that was > > correct, we would not have to go that extra mile in struct iphdr, or do > > we? > > > > I meant in general - the note to say that there are endianes issues > should go. Sorry, I didn't get that yet: To me it looks as if on a big-endian system, the code will actually change the Version field instead of IHL. Probably the proof of the pudding is in the eating, so I'll try to get access to a big-endian system for testing. > >> These would of course require more of a larger setup to vet > >> and running tcpdump to check the correct bytes are being > >> modified. > > > > Indeed - That is how i normally would test. It is more complex. > Your scheme is good - but will not catch a kernel bug. Sure. OTOH the algorithm in act_pedit is not overly complex. Plus, fixing one side only prevents accidental workarounds of other side's bugs. > > Since I am lazy, I wanted to have as much automation as possible while > > testing. Therefore I just assumed that act_pedit does the right thing > > all the time, > > famous last words ;-> :) > > and iproute just has to feed it correct values. Given the > > scope of this patch, this is also completely sufficient. Of course, the > > tests/ directory would benefit more from a full test. But since > > automation then becomes tricky, I'm not sure it makes much sense to > > deliberately write code for that. > > > > Your test is still useful and i think should go into the tests dir. OK, I'll give it a thought. Thanks, Phil
--- a/tc/m_pedit.c +++ b/tc/m_pedit.c @@ -513,6 +513,12 @@ parse_pedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id, stru } } + fprintf(stderr, "mask=0x%x\n", sel.keys[0].mask); + fprintf(stderr, "val=0x%x\n", sel.keys[0].val); + fprintf(stderr, "off=0x%x\n", sel.keys[0].off); + fprintf(stderr, "at=0x%x\n", sel.keys[0].at); + fprintf(stderr, "offmask=0x%x\n", sel.keys[0].offmask); + fprintf(stderr, "shift=0x%x\n", sel.keys[0].shift); tail = NLMSG_TAIL(n); addattr_l(n, MAX_MSG, tca_id, NULL, 0); addattr_l(n, MAX_MSG, TCA_PEDIT_PARMS,&sel, sizeof(sel.sel)+sel.sel.nkeys*sizeof(struct tc_pedit_key));